Remove ClassLoader from FilterManager interface

[cziegeler]

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@...

[Ate Douma]

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

[David Sean Taylor]

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