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