[
https://issues.apache.org/jira/browse/PLUTO-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved PLUTO-539.
-----------------------------
Resolution: Fixed
I've implemented this on portal-driver by simply returning a new
FilterManagerImpl from the new service.
No optimization done yet, but at least its now integrated with the new
container api again.
Further optimization is (for the portal-driver) not a critical requirement
right now.
> New FilterManagerService implementation
> ---------------------------------------
>
> Key: PLUTO-539
> URL: https://issues.apache.org/jira/browse/PLUTO-539
> Project: Pluto
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 2.0.0
>
>
> Below copied (in part) from email discussion on the Pluto dev list, see also:
> http://www.nabble.com/More-required-Pluto-2.0-SPI-and-implementation-refactoring-issues-td21973310.html
> *** FilterManager implementation and usage
> The current implementation and usage of the FilterManager is very
> inefficient: a new FilterManagerImpl and FilterChainImpl is created on the
> fly for each container invocation, while the behavior and context of a
> PortletFilter really is deployment descriptor based.
> This implementation needs to be refactoring to a much more performant
> solution.
> =====
> I've added a new (required) FilterManagerService which will allow to cache a
> FilterChain per portlet application per FilterManager
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
