Ate Douma wrote: > Hmm, we might need to review the spec on this again. > I'm not sure but it could be that even if a portlet doesn't implement > EventPortlet, the filter(s) might be expected to be invoked nonetheless. > Pluto PortletServlet "injects" no-op EventPortlet/ResourceServingPortlet > instances for that purpose, while in Jetspeed we always wrap a portlet > in a PortletInstance class implementing all interfaces. I scanned the section about the filters in the spec and it says that the last component in the chain is the receiving portlet. Now, if an event is sent and a portlet is not implementing the EventPortlet interface, the portlet never gets the event; therefore filters can never be applied. At least this is how I read the spec :)
> Looking a bit deeper into the FilterManagerImpl, the invoked FilterChain > expects strongly typed request/response instances (e.g. 4 methods) too, > and that is a spec API. > Therefore I would prefer aligning with the spec in this regard, so using > 4 methods instead of 1. Yes, ok, so if noone objects, I'll change the interface to have four methods. Carsten -- Carsten Ziegeler [email protected]
