cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 32156] New: - [PATCH] Fix for cocoon.jar bundled in ear common for portal.war and portlet.war
Date Wed, 10 Nov 2004 16:24:04 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32156>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32156

[PATCH] Fix for cocoon.jar bundled in ear common for portal.war and portlet.war

           Summary: [PATCH] Fix for cocoon.jar bundled in ear common for
                    portal.war and portlet.war
           Product: Cocoon 2
           Version: 2.1.5
          Platform: Other
               URL: http://http://http://
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: blocks
        AssignedTo: dev@cocoon.apache.org
        ReportedBy: durdina@asset.sk


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() <-

Mime
View raw message