You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Carsten Ziegeler <cz...@apache.org> on 2009/04/09 21:26:56 UTC
Remove ClassLoader from FilterManager interface
Currently all methods of the FilterManager require a class loader
instance for actually loading the filters.
However this is an implementation detail and a portal might decide to
already create the filters when the portlet webapp is started (and cache
the filters). If the filter manager requires a class loader this should
be handled like it is done in other services, the class loader should be
passed into the implementation. The interface should not required a
classloader.
Therefore I would like to remove the classloader from the interface.
WDYT?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Remove ClassLoader from FilterManager interface
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Apr 9, 2009, at 12:39 PM, Ate Douma wrote:
> Carsten Ziegeler wrote:
>> Currently all methods of the FilterManager require a class loader
>> instance for actually loading the filters.
>> However this is an implementation detail and a portal might decide to
>> already create the filters when the portlet webapp is started (and
>> cache
>> the filters). If the filter manager requires a class loader this
>> should
>> be handled like it is done in other services, the class loader
>> should be
>> passed into the implementation. The interface should not required a
>> classloader.
>> Therefore I would like to remove the classloader from the interface.
>> WDYT?
> +1
> Like you said, Jetspeed is creating and caching the filters upfront
> and doesn't use this classloader parameter at all.
>
+1, i haven't really reviewed it in pluto but did review the jetspeed
version Woonsan is working on and it makes sense
Re: Remove ClassLoader from FilterManager interface
Posted by Ate Douma <at...@douma.nu>.
Carsten Ziegeler wrote:
> Currently all methods of the FilterManager require a class loader
> instance for actually loading the filters.
> However this is an implementation detail and a portal might decide to
> already create the filters when the portlet webapp is started (and cache
> the filters). If the filter manager requires a class loader this should
> be handled like it is done in other services, the class loader should be
> passed into the implementation. The interface should not required a
> classloader.
>
> Therefore I would like to remove the classloader from the interface.
>
> WDYT?
+1
Like you said, Jetspeed is creating and caching the filters upfront and doesn't use this classloader parameter at all.
>
> Carsten