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 "David DeWolf (JIRA)" <ji...@apache.org> on 2007/03/03 15:12:52 UTC

[jira] Resolved: (PLUTO-163) Class ControllerObjectAccess should access FactoryManager on each request

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

David DeWolf resolved PLUTO-163.
--------------------------------

    Resolution: Won't Fix

> Class ControllerObjectAccess should access FactoryManager on each request
> -------------------------------------------------------------------------
>
>                 Key: PLUTO-163
>                 URL: https://issues.apache.org/jira/browse/PLUTO-163
>             Project: Pluto
>          Issue Type: Improvement
>          Components: portlet container
>    Affects Versions: 1.0.1
>         Environment: Tomcat v5.0.28, JDK v.14
>            Reporter: Nico Max
>             Fix For: 1.0.2
>
>         Attachments: diff.patch
>
>
> The class ControllerObjectAccess accesses the controller factory implementation class via a static variable. When the factory manager gets re-initialized during a portal reload, this variable still holds the reference to the old factory manager as the reload does not affect the ControllerObjectAccess class itself.
> This may lead to strange classloader-related behavior (like classcast-exceptions) when the following is true:
> 1. The portlet-api jar resides in a server location which will be served by a classloader which is a parent of each webapplication.
> 2. The portal re-initializes the factory manager during an portal-application reload.
> 3. The factory manager provides a controller factory implementation which utilizes classes from the portal application (and performs classloader-sensitive operations like instanceof-checks, casts, etc)
> I'm using the portal driver and have changed the FactoryManagerService.properties file to have my own controller factory being used by the portlet container.
> Due to the fact that this class resides in the distribution jar of the portlet container and this jar resides 

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