[xwiki-devs] [proposal] Move servlet filters out of the core
Hi devs, I propose to move servlet filters out of the old core to xwiki-container-servlet. There are 3 filters, com.xpn.xwiki.web.SetCharacterEncodingFilter com.xpn.xwiki.web.SavedRequestRestorerFilter com.xpn.xwiki.web.ActionFilter They are almost self-contained (except for ActionFilter, see a note later) and are easy to move. Moreover, SavedRequestRestorerFilter offers functionality to save the request, that might also be useful in other places (like csrf-token). There is (currently) no need for portlet filters, so moving filters into a separate module doesn't seem to be worth it. Since the filters are not used directly, I'd move them into org.xwiki.container.servlet.filters.internal and public methods used elsewhere into org.xwiki.container.servlet.filters. Note that xwiki-core would become dependent on xwiki-container-servlet (it currently depends on container-api), but it shouldn't be a problem. In more detail, * SetCharacterEncodingFilter would be moved as is to filters.internal. * SavedRequestRestorerFilter would be split into the actual filter and SavedRequestManager that would contain the static methods String getOriginalUrl(HttpServletRequest) String saveRequest(HttpServletRequest) String getRequestIdentifier() SavedRequestManager could also be a component, but it would make it more complicated to use from the filter. * ActionFilter should be moved to filters.internal too, but it uses XWiki.stripSegmentFromPath(String, String) to parse the URL and replace the action part by the stored value. There are 2 other copies of the URL parsing code that uses stripSegmentFromPath(...), in XWiki.getDocumentReference(...) and XWiki.getXWiki(...), I can think of 3 alternatives: 1. Leave ActionFilter in the core 2. Move URL parsing code into xwiki-url, i.e. add/implement missing methods to create XWikiURL from string representation and extract host, action, document reference and parameters from it. 3. Move stripSegmentFromPath(...) to xwiki-container-servlet too I'm +1 for 2, since it's the cleanest option. WDYT? Thanks, Alex
One more thing, On 08/24/2010 01:17 AM, Alex Busenius wrote:
Hi devs,
I propose to move servlet filters out of the old core to xwiki-container-servlet.
There are 3 filters,
com.xpn.xwiki.web.SetCharacterEncodingFilter com.xpn.xwiki.web.SavedRequestRestorerFilter com.xpn.xwiki.web.ActionFilter
They are almost self-contained (except for ActionFilter, see a note later) and are easy to move. Moreover, SavedRequestRestorerFilter offers functionality to save the request, that might also be useful in other places (like csrf-token). There is (currently) no need for portlet filters, so moving filters into a separate module doesn't seem to be worth it.
Since the filters are not used directly, I'd move them into org.xwiki.container.servlet.filters.internal and public methods used elsewhere into org.xwiki.container.servlet.filters.
Note that xwiki-core would become dependent on xwiki-container-servlet (it currently depends on container-api), but it shouldn't be a problem.
In more detail,
* SetCharacterEncodingFilter would be moved as is to filters.internal.
* SavedRequestRestorerFilter would be split into the actual filter and SavedRequestManager that would contain the static methods String getOriginalUrl(HttpServletRequest) String saveRequest(HttpServletRequest) String getRequestIdentifier() SavedRequestManager could also be a component, but it would make it more complicated to use from the filter.
* ActionFilter should be moved to filters.internal too, but it uses XWiki.stripSegmentFromPath(String, String) to parse the URL and replace the action part by the stored value.
I've just noticed that ActionFilter also uses old xwiki configuration in the URL parsing code (xwiki.virtual.usepath and xwiki.virtual.usepath.servletpath). So moving this code to xwiki-url would also require moving those configuration keys to xwiki.properties. Alex
There are 2 other copies of the URL parsing code that uses stripSegmentFromPath(...), in XWiki.getDocumentReference(...) and XWiki.getXWiki(...), I can think of 3 alternatives: 1. Leave ActionFilter in the core 2. Move URL parsing code into xwiki-url, i.e. add/implement missing methods to create XWikiURL from string representation and extract host, action, document reference and parameters from it. 3. Move stripSegmentFromPath(...) to xwiki-container-servlet too
I'm +1 for 2, since it's the cleanest option.
WDYT?
Thanks, Alex _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 08/24/2010 01:17 AM, Alex Busenius wrote:
Hi devs,
I propose to move servlet filters out of the old core to xwiki-container-servlet.
There are 3 filters,
com.xpn.xwiki.web.SetCharacterEncodingFilter com.xpn.xwiki.web.SavedRequestRestorerFilter com.xpn.xwiki.web.ActionFilter
They are almost self-contained (except for ActionFilter, see a note later) and are easy to move. Moreover, SavedRequestRestorerFilter offers functionality to save the request, that might also be useful in other places (like csrf-token). There is (currently) no need for portlet filters, so moving filters into a separate module doesn't seem to be worth it.
Since the filters are not used directly, I'd move them into org.xwiki.container.servlet.filters.internal and public methods used elsewhere into org.xwiki.container.servlet.filters.
Note that xwiki-core would become dependent on xwiki-container-servlet (it currently depends on container-api), but it shouldn't be a problem.
+1 for moving SCEF and SRRF, but not AF.
In more detail,
* SetCharacterEncodingFilter would be moved as is to filters.internal.
* SavedRequestRestorerFilter would be split into the actual filter and SavedRequestManager that would contain the static methods String getOriginalUrl(HttpServletRequest) String saveRequest(HttpServletRequest) String getRequestIdentifier() SavedRequestManager could also be a component, but it would make it more complicated to use from the filter.
* ActionFilter should be moved to filters.internal too, but it uses XWiki.stripSegmentFromPath(String, String) to parse the URL and replace the action part by the stored value.
There are 2 other copies of the URL parsing code that uses stripSegmentFromPath(...), in XWiki.getDocumentReference(...) and XWiki.getXWiki(...), I can think of 3 alternatives: 1. Leave ActionFilter in the core 2. Move URL parsing code into xwiki-url, i.e. add/implement missing methods to create XWikiURL from string representation and extract host, action, document reference and parameters from it. 3. Move stripSegmentFromPath(...) to xwiki-container-servlet too
I'm +1 for 2, since it's the cleanest option.
+1 for 1, for the moment. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Moving ActionFilter turned out to be much harder than I thought. If nobody cries out, I'll move the other two today. Thanks, Alex On 08/25/2010 11:58 PM, Sergiu Dumitriu wrote:
On 08/24/2010 01:17 AM, Alex Busenius wrote:
Hi devs,
I propose to move servlet filters out of the old core to xwiki-container-servlet.
There are 3 filters,
com.xpn.xwiki.web.SetCharacterEncodingFilter com.xpn.xwiki.web.SavedRequestRestorerFilter com.xpn.xwiki.web.ActionFilter
They are almost self-contained (except for ActionFilter, see a note later) and are easy to move. Moreover, SavedRequestRestorerFilter offers functionality to save the request, that might also be useful in other places (like csrf-token). There is (currently) no need for portlet filters, so moving filters into a separate module doesn't seem to be worth it.
Since the filters are not used directly, I'd move them into org.xwiki.container.servlet.filters.internal and public methods used elsewhere into org.xwiki.container.servlet.filters.
Note that xwiki-core would become dependent on xwiki-container-servlet (it currently depends on container-api), but it shouldn't be a problem.
+1 for moving SCEF and SRRF, but not AF.
In more detail,
* SetCharacterEncodingFilter would be moved as is to filters.internal.
* SavedRequestRestorerFilter would be split into the actual filter and SavedRequestManager that would contain the static methods String getOriginalUrl(HttpServletRequest) String saveRequest(HttpServletRequest) String getRequestIdentifier() SavedRequestManager could also be a component, but it would make it more complicated to use from the filter.
* ActionFilter should be moved to filters.internal too, but it uses XWiki.stripSegmentFromPath(String, String) to parse the URL and replace the action part by the stored value.
There are 2 other copies of the URL parsing code that uses stripSegmentFromPath(...), in XWiki.getDocumentReference(...) and XWiki.getXWiki(...), I can think of 3 alternatives: 1. Leave ActionFilter in the core 2. Move URL parsing code into xwiki-url, i.e. add/implement missing methods to create XWikiURL from string representation and extract host, action, document reference and parameters from it. 3. Move stripSegmentFromPath(...) to xwiki-container-servlet too
I'm +1 for 2, since it's the cleanest option.
+1 for 1, for the moment.
Alex, do you think you can move http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-wysiwyg-serv... too? It is used by the WYSIWYG editor to initialize the XWiki context on GWTRPC requests and, AFAIK, by the XMLRPC module. It's pretty generic, but depends on xwiki-core. WDYT? Thanks, Marius On 08/30/2010 11:30 AM, Alex Busenius wrote:
Moving ActionFilter turned out to be much harder than I thought. If nobody cries out, I'll move the other two today.
Thanks, Alex
On 08/25/2010 11:58 PM, Sergiu Dumitriu wrote:
On 08/24/2010 01:17 AM, Alex Busenius wrote:
Hi devs,
I propose to move servlet filters out of the old core to xwiki-container-servlet.
There are 3 filters,
com.xpn.xwiki.web.SetCharacterEncodingFilter com.xpn.xwiki.web.SavedRequestRestorerFilter com.xpn.xwiki.web.ActionFilter
They are almost self-contained (except for ActionFilter, see a note later) and are easy to move. Moreover, SavedRequestRestorerFilter offers functionality to save the request, that might also be useful in other places (like csrf-token). There is (currently) no need for portlet filters, so moving filters into a separate module doesn't seem to be worth it.
Since the filters are not used directly, I'd move them into org.xwiki.container.servlet.filters.internal and public methods used elsewhere into org.xwiki.container.servlet.filters.
Note that xwiki-core would become dependent on xwiki-container-servlet (it currently depends on container-api), but it shouldn't be a problem.
+1 for moving SCEF and SRRF, but not AF.
In more detail,
* SetCharacterEncodingFilter would be moved as is to filters.internal.
* SavedRequestRestorerFilter would be split into the actual filter and SavedRequestManager that would contain the static methods String getOriginalUrl(HttpServletRequest) String saveRequest(HttpServletRequest) String getRequestIdentifier() SavedRequestManager could also be a component, but it would make it more complicated to use from the filter.
* ActionFilter should be moved to filters.internal too, but it uses XWiki.stripSegmentFromPath(String, String) to parse the URL and replace the action part by the stored value.
There are 2 other copies of the URL parsing code that uses stripSegmentFromPath(...), in XWiki.getDocumentReference(...) and XWiki.getXWiki(...), I can think of 3 alternatives: 1. Leave ActionFilter in the core 2. Move URL parsing code into xwiki-url, i.e. add/implement missing methods to create XWikiURL from string representation and extract host, action, document reference and parameters from it. 3. Move stripSegmentFromPath(...) to xwiki-container-servlet too
I'm +1 for 2, since it's the cleanest option.
+1 for 1, for the moment.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 08/30/2010 10:44 AM, Marius Dumitru Florea wrote:
Alex, do you think you can move http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-wysiwyg-serv... too? It is used by the WYSIWYG editor to initialize the XWiki context on GWTRPC requests and, AFAIK, by the XMLRPC module. It's pretty generic, but depends on xwiki-core. WDYT?
I don't think so, xwiki-container-servlet does not depend on xwiki-core and the purpose of this filter is to initialize XWiki context, this is hard to do without adding core dependency. Another filter in GWT is ConversionFilter, but it depends on GWT client and I'm not sure it is a good idea to introduce this dependency in servlets. There are also 2 totally undocumented filters that seem to initialize Hibernate, com.xpn.xwiki.user.impl.exo.ExoFilter and com.xpn.xwiki.util.ExoFilter, I'm not sure about them. Any other filters in question? Thanks, Alex
Thanks, Marius
On 08/30/2010 11:30 AM, Alex Busenius wrote:
Moving ActionFilter turned out to be much harder than I thought. If nobody cries out, I'll move the other two today.
Thanks, Alex
On 08/25/2010 11:58 PM, Sergiu Dumitriu wrote:
On 08/24/2010 01:17 AM, Alex Busenius wrote:
Hi devs,
I propose to move servlet filters out of the old core to xwiki-container-servlet.
There are 3 filters,
com.xpn.xwiki.web.SetCharacterEncodingFilter com.xpn.xwiki.web.SavedRequestRestorerFilter com.xpn.xwiki.web.ActionFilter
They are almost self-contained (except for ActionFilter, see a note later) and are easy to move. Moreover, SavedRequestRestorerFilter offers functionality to save the request, that might also be useful in other places (like csrf-token). There is (currently) no need for portlet filters, so moving filters into a separate module doesn't seem to be worth it.
Since the filters are not used directly, I'd move them into org.xwiki.container.servlet.filters.internal and public methods used elsewhere into org.xwiki.container.servlet.filters.
Note that xwiki-core would become dependent on xwiki-container-servlet (it currently depends on container-api), but it shouldn't be a problem.
+1 for moving SCEF and SRRF, but not AF.
In more detail,
* SetCharacterEncodingFilter would be moved as is to filters.internal.
* SavedRequestRestorerFilter would be split into the actual filter and SavedRequestManager that would contain the static methods String getOriginalUrl(HttpServletRequest) String saveRequest(HttpServletRequest) String getRequestIdentifier() SavedRequestManager could also be a component, but it would make it more complicated to use from the filter.
* ActionFilter should be moved to filters.internal too, but it uses XWiki.stripSegmentFromPath(String, String) to parse the URL and replace the action part by the stored value.
There are 2 other copies of the URL parsing code that uses stripSegmentFromPath(...), in XWiki.getDocumentReference(...) and XWiki.getXWiki(...), I can think of 3 alternatives: 1. Leave ActionFilter in the core 2. Move URL parsing code into xwiki-url, i.e. add/implement missing methods to create XWikiURL from string representation and extract host, action, document reference and parameters from it. 3. Move stripSegmentFromPath(...) to xwiki-container-servlet too
I'm +1 for 2, since it's the cleanest option.
+1 for 1, for the moment.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Aug 30, 2010 at 11:08, Alex Busenius <[email protected]> wrote:
On 08/30/2010 10:44 AM, Marius Dumitru Florea wrote:
Alex, do you think you can move http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-wysiwyg-serv... too? It is used by the WYSIWYG editor to initialize the XWiki context on GWTRPC requests and, AFAIK, by the XMLRPC module. It's pretty generic, but depends on xwiki-core. WDYT?
I don't think so, xwiki-container-servlet does not depend on xwiki-core and the purpose of this filter is to initialize XWiki context, this is hard to do without adding core dependency.
Another filter in GWT is ConversionFilter, but it depends on GWT client and I'm not sure it is a good idea to introduce this dependency in servlets.
There are also 2 totally undocumented filters that seem to initialize Hibernate, com.xpn.xwiki.user.impl.exo.ExoFilter and com.xpn.xwiki.util.ExoFilter, I'm not sure about them.
Theses one are probably some (very very old) tweaks for exoplatform that probably don't work anymore.
Any other filters in question?
Thanks, Alex
Thanks, Marius
On 08/30/2010 11:30 AM, Alex Busenius wrote:
Moving ActionFilter turned out to be much harder than I thought. If nobody cries out, I'll move the other two today.
Thanks, Alex
On 08/25/2010 11:58 PM, Sergiu Dumitriu wrote:
On 08/24/2010 01:17 AM, Alex Busenius wrote:
Hi devs,
I propose to move servlet filters out of the old core to xwiki-container-servlet.
There are 3 filters,
com.xpn.xwiki.web.SetCharacterEncodingFilter com.xpn.xwiki.web.SavedRequestRestorerFilter com.xpn.xwiki.web.ActionFilter
They are almost self-contained (except for ActionFilter, see a note later) and are easy to move. Moreover, SavedRequestRestorerFilter offers functionality to save the request, that might also be useful in other places (like csrf-token). There is (currently) no need for portlet filters, so moving filters into a separate module doesn't seem to be worth it.
Since the filters are not used directly, I'd move them into org.xwiki.container.servlet.filters.internal and public methods used elsewhere into org.xwiki.container.servlet.filters.
Note that xwiki-core would become dependent on xwiki-container-servlet (it currently depends on container-api), but it shouldn't be a problem.
+1 for moving SCEF and SRRF, but not AF.
In more detail,
* SetCharacterEncodingFilter would be moved as is to filters.internal.
* SavedRequestRestorerFilter would be split into the actual filter and SavedRequestManager that would contain the static methods String getOriginalUrl(HttpServletRequest) String saveRequest(HttpServletRequest) String getRequestIdentifier() SavedRequestManager could also be a component, but it would make it more complicated to use from the filter.
* ActionFilter should be moved to filters.internal too, but it uses XWiki.stripSegmentFromPath(String, String) to parse the URL and replace the action part by the stored value.
There are 2 other copies of the URL parsing code that uses stripSegmentFromPath(...), in XWiki.getDocumentReference(...) and XWiki.getXWiki(...), I can think of 3 alternatives: 1. Leave ActionFilter in the core 2. Move URL parsing code into xwiki-url, i.e. add/implement missing methods to create XWikiURL from string representation and extract host, action, document reference and parameters from it. 3. Move stripSegmentFromPath(...) to xwiki-container-servlet too
I'm +1 for 2, since it's the cleanest option.
+1 for 1, for the moment.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 08/30/2010 10:44 AM, Marius Dumitru Florea wrote:
Alex, do you think you can move http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-wysiwyg-serv... too? It is used by the WYSIWYG editor to initialize the XWiki context on GWTRPC requests and, AFAIK, by the XMLRPC module. It's pretty generic, but depends on xwiki-core. WDYT?
It is also used by the REST module. Thanks, Fabio
participants (5)
-
Alex Busenius -
Fabio Mancinelli -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne