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-server/src/main/java/com/xpn/xwiki/wysiwyg/server/filter/XWikiContextInitializationFilter.java
>  
> 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
> 
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to