> -----Original Message----- > From: peter royal [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 08, 2004 8:32 PM > To: [EMAIL PROTECTED] > 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
