cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ĎURDINA Michal <Michal.Durd...@assetsoft.sk>
Subject RE: Sharing cocoon.jar between multiple web aplications
Date Thu, 09 Sep 2004 12:23:13 GMT

> -----Original Message-----
> From: peter royal [mailto:proyal@apache.org]
> Sent: Wednesday, September 08, 2004 8:32 PM
> To: dev@cocoon.apache.org
> Subject: Re: Sharing cocoon.jar between multiple web aplications
> 
> 
> On Sep 8, 2004, at 11:17 AM, ĎURDINA Michal wrote:
> > The problem arise only when one web application calls other web 
> > application to generate its output (via 
> getRequestDispatcher.include() 
> > - crosscontext must be enabled). Then both webapps use the 
> same static 
> > field instance in the same thread. And if both are calling 
> method on 
> > the same class i.e. Cocoon.process(), then called web 
> application can 
> > rewrite the value saved by calling web application.
> 
> ah, gotcha.
> 
> why not just put cocoon.jar per-webapp then, and put the rest of the 
> deps at the ear level? :)
> -pete
> 

Yes, thats solves the problem partially.

Instead of duplicating 15MB of libraries, I will be duplicating only about 2,5MB of cocoon
libraries and libraries that are dependent on cocoon libraries. I.e. castor.jar must be moved
back from ear to WEB-INF/lib to see cocoon classes needed for xml unmarhsalling.

I tried to fix the static ThreadLocal fields on my own and it resulted to change only in Cocoon.java
to remove checkEnvironment() method. Static field in other classes did not affect me either
because they are in blocks that we do not use or I am sure that they won't be multicalled
in one request (i.e. portal-block classes).

Here is the list of them anyway (cocoon-2.1.5 release):
grep -d -l "ThreadLocal" *.java 

File blocks\batik\java\org\apache\cocoon\components\url\SourceProtocolHandler.java:
File blocks\portal\java\org\apache\cocoon\portal\impl\PortletPortalManager.java:
File blocks\portal\java\org\apache\cocoon\portal\serialization\IncludingHTMLSerializer.java:
File blocks\portal\java\org\apache\cocoon\portal\util\ReferenceFieldHandler.java:
File blocks\portal-fw\java\org\apache\cocoon\webapps\portal\context\SessionContextImpl.java:
File blocks\scratchpad\java\org\apache\cocoon\ant\AntBuildGenerator.java:
File java\org\apache\cocoon\components\CocoonComponentManager.java:
File java\org\apache\cocoon\components\treeprocessor\variables\VariableResolverFactory.java:

From those all these are not affected by multicall problem because:
PortletPortalManger - there is not read of the static ThreadLocal copletInstanceData;
VariableResolverFactory - detto - no read of static ThreadLocal disposableCollector;
CocoonComponentManager - immune because of the use of threadlocal stack of variables instead
of threadlocal variable
IncludingHTMLSerializer - no conflict because this class is called by only on webapp (or at
least it is very unlikely to be called more than one in one request)
ReferenceFieldHandler - detto - no conflict

So all I needed to change was Cocoon.java. I have not tested this thorougly so I cannot say
if it really works correctly yet.
But I still would be for using static fields only with special care and with handling against
webapp multicall (on webapp includes other) problem i.e. as CocoonComponentManager does with
threadlocal stack and proper cleaning before return.

Michal
Mime
View raw message