You are viewing a plain text version of this content. The canonical link for it is here.

Posted to pluto-dev@portals.apache.org by "Ate Douma (JIRA)" <ji...@apache.org> on 2009/04/07 04:16:13 UTC

[jira] Resolved: (PLUTO-441) Redeploy of a portlet doesn't effect filter implementation

     [ https://issues.apache.org/jira/browse/PLUTO-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma resolved PLUTO-441.
-----------------------------

       Resolution: Incomplete
    Fix Version/s:     (was: 2.0.0)

I cannot reproduce nor determine the exact conditions and goals of this issue anymore.
The codebase has been completely changed anyway.
As no input was provided on this in a long time and the described goal seems to be beyond the scope of the portal driver (hot-deployments etc.) I'm closing this now as incomplete.

> Redeploy of a portlet doesn't effect filter implementation
> ----------------------------------------------------------
>
>                 Key: PLUTO-441
>                 URL: https://issues.apache.org/jira/browse/PLUTO-441
>             Project: Pluto
>          Issue Type: Sub-task
>          Components: portal driver
>    Affects Versions: 1.1-286-COMPATIBILITY
>            Reporter: Christian Raschka
>            Priority: Minor
>             Fix For: 1.1-286-COMPATIBILITY
>
>
> Portlet Filter are registered at the SupportedModesServiceImpl.loadPortletModes() which runs only once. Therefore changes at the portletDD are not recognized.
> Maybe we could use a similiar method as we did with the eventprovider? Make the FilterManager request dependant and look for the filter at every request. Then there is no need for a global (static) map of filters.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.