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
