cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Crossley (JIRA)" <j...@apache.org>
Subject [jira] Updated: (COCOON-1329) [PATCH] Fix for cocoon.jar bundled in ear common for portal.war and portlet.war
Date Wed, 01 Mar 2006 07:33:19 GMT
     [ http://issues.apache.org/jira/browse/COCOON-1329?page=all ]

David Crossley updated COCOON-1329:
-----------------------------------

    Bugzilla Id:   (was: 32156)
     Other Info: [Patch available]

> [PATCH] Fix for cocoon.jar bundled in ear common for portal.war and portlet.war
> -------------------------------------------------------------------------------
>
>          Key: COCOON-1329
>          URL: http://issues.apache.org/jira/browse/COCOON-1329
>      Project: Cocoon
>         Type: Bug
>   Components: Blocks: Portal
>     Versions: 2.1.5
>  Environment: Operating System: All
> Platform: Other
>     Reporter: Michal Durdina
>     Assignee: Ralph Goers
>  Attachments: RELEASE_2_1_5_1.patch_2.txt, RELEASE_2_1_6.patch_2.diff
>
> Removal of checkEnvironment() in Cocoon.process() method. Needed for cocoon 
> portal-to-portlet communication via RequestDispatcher.include() when portal.war 
> and portlet.war are bundled into ear. Cocoon.jar is pulled from wars'/WEB-
> INF/lib to top ear level - as a result common ear classloader is used for its 
> classes. Static class fields in cocoon.jar are influenced. Critical: static 
> field 'environmentStack'.
> Two use cases:
> A.) WORKING: portal.war and portlet.war use TWO classloaders for cocoon.jar
>  - every war has its own cocoon.jar in WEB-INF/lib
>  - static class fields are instantiated in each classloader
>  - every war sees its own instance of static field
> B.) NOT WORKING: portal.war and portlet.war use ONE classloader for cocoon.jar
>  - every war uses cocoon.jar from ear
>  - static class fields are instantiated only ONCE in ear classloader
>  - all war sees same instance of static field
> This patch fixes getting/setting PortalServiceInfo from/to session. When 
> portlet constructs its url's, it calls portal service DefaultLinkService. 
> DefaultLinkService tries to get PortalServiceInfo from session and session is 
> retrieved from Environment object that is currently at the top of 
> environmentStack.
> Case A: Calling sequence of portal processing:
> portal.war#Cocoon.process() -> 
>   portletInfo -> portal.session
>   // cl1, cl2 stands for classloader1, classloader2
>   cl1.envStack.top:=portal.session 
> portlet.war#Cocoon.process() -> 
>   cl2.envStack.top:=portlet.session 
> portal.war#DefaultLinkService.getInfo() -> 
>   session := cl1.envStack.top
>   portletInfo <- session(portal.session) // portletInfo != NULL
> portal.war#DefaultLinkService.getInfo() <-
> portlet.war#Cocoon.process() <-
> portal.war#Cocoon.process() <-
> Case B: Calling sequence of portal processing:
> portal.war#Cocoon.process() -> 
>   portletInfo -> portal.session
>   // cl1 stands for common classloader
>   cl1.envStack.top:=portal.session
> portlet.war#Cocoon.process() -> 
>   cl1.envStack.top:=portlet.session 
> portal.war#DefaultLinkService.getInfo() -> 
>   session := cl1.envStack.top
>   portletInfo <- session(portlet.session) // NPE: portletInfo == NULL
> portal.war#DefaultLinkService.getInfo() <-
> portlet.war#Cocoon.process() <-
> portal.war#Cocoon.process() <-

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message