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
