RE: Sharing cocoon.jar between multiple web aplications

2004-09-09 Thread ĎURDINA Michal 
I am using cocoon-2.1.5 release.

I will try to replece Cocoon.java from CVS HEAD. Thanks for pointing me there.

Michal


> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 09, 2004 12:21 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Sharing cocoon.jar between multiple web aplications
> 
> 
> Ä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.
> 
> IIRC, this particular problem you are describing are resolved in CVS. 
> When last time you had updated your snapshot?
> 
> Vadim
> 
>

RE: Sharing cocoon.jar between multiple web aplications

2004-09-09 Thread ĎURDINA Michal 

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

Re: Sharing cocoon.jar between multiple web aplications

2004-09-08 Thread Vadim Gritsenko 
Ä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.
IIRC, this particular problem you are describing are resolved in CVS. 
When last time you had updated your snapshot?

Vadim

Re: Sharing cocoon.jar between multiple web aplications

2004-09-08 Thread Leo Sutic 
On Wed, 8 Sep 2004 14:32:01 -0400, peter royal <[EMAIL PROTECTED]> wrote:
> 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? :)

Because the other deps may include cocoon components (generators etc).
The cocoon jar will suck all the other libs with it.

The problem seems to be that the stack is assumed to be empty at start
of processing, otherwise it doesn't matter. Would it be possible to
instead put some kind of "barrier" on the stack at startProcessing,
and remove it at endProcessing? It would be empty to the thread
handling the request, because it can't see beyond the barrier.

/LS

Re: Sharing cocoon.jar between multiple web aplications

2004-09-08 Thread peter royal 
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

RE: Sharing cocoon.jar between multiple web aplications

2004-09-08 Thread ĎURDINA Michal 
> -Original Message-
> From: peter royal [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 08, 2004 4:03 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Sharing cocoon.jar between multiple web aplications
> 
> 
> On Sep 8, 2004, at 9:44 AM, URDINA Michal wrote:
> > I created ear file with about 6 war files. All war files are cocoon 
> > web applications and thus have same WEB-INF/lib 
> directories. The ear 
> > file has apx. 100MB due to duplicity of libraries in 
> WEB-INF/lib's. It 
> > seems reasonable to me to pull up those duplicit libraries at ear 
> > level and share them among web applications.
> >
> > But I'm stuck with the use of static ThreadLocal class 
> fields in some 
> > cocoon classes.
> 
> I do this without any ill effects..
> 
> If the static's weren't ThreadLocals, there would be a problem.. But 
> since they are ThreadLocals, each webapp is still isolated, because 
> you'll only have one thread-per-request at a time.
> -pete
> 

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.

The processing goes like this (all on the same thread):

webapp#1:
set value
call webapp#2
webapp#2:
set value
doSomething
get value
return
webapp#1:
doSomething
get value
return

webapp#1 gets the value saved by webapp#2 and that's not ok:)

Michal

Re: Sharing cocoon.jar between multiple web aplications

2004-09-08 Thread peter royal 
On Sep 8, 2004, at 9:44 AM, ÄURDINA Michal wrote:
I created ear file with about 6 war files. All war files are cocoon 
web applications and thus have same WEB-INF/lib directories. The ear 
file has apx. 100MB due to duplicity of libraries in WEB-INF/lib's. It 
seems reasonable to me to pull up those duplicit libraries at ear 
level and share them among web applications.

But I'm stuck with the use of static ThreadLocal class fields in some 
cocoon classes.
I do this without any ill effects..
If the static's weren't ThreadLocals, there would be a problem.. But 
since they are ThreadLocals, each webapp is still isolated, because 
you'll only have one thread-per-request at a time.
-pete

smime.p7s
Description: S/MIME cryptographic signature

Sharing cocoon.jar between multiple web aplications

2004-09-08 Thread ĎURDINA Michal 
Hi,

I created ear file with about 6 war files. All war files are cocoon web applications 
and thus have same WEB-INF/lib directories. The ear file has apx. 100MB due to 
duplicity of libraries in WEB-INF/lib's. It seems reasonable to me to pull up those 
duplicit libraries at ear level and share them among web applications.

But I'm stuck with the use of static ThreadLocal class fields in some cocoon classes. 

Good example is CocoonComponentManager.environmentStack:

this static field is used in methods 
- enterEnvironment()
- leaveEnvironment() 
which are call on every request process by Cocoon.process() method:

process(Environment environment) {
try {
CocoonComponentManager.startProcessing(environment);
CocoonComponentManager.enterEnvironment(environment, 
this.componentManager, this);  // <- environmentStack.push
...
finally {
CocoonComponentManager.leaveEnvironment(); 
 // -> environmentStack.pop
CocoonComponentManager.endProcessing(environment, key);
}
CocoonComponentManager.checkEnvironment(getLogger());

Providing that CocoonComponentManager class is located in WEB-INF/lib, we have no 
problem, because every webapp gets its own class loader that creates its local 
instance of static field. This field is then used only by proper webapplication and in 
the threadsafe manner. But if we move CocoonComponentManager to ear level and share 
this class among more than one web application, we break the contract, because only 
one instance of this static field will be created for all web applications. When we 
consider that one application can call other one, then we can see this not working, 
because multiple web aplications will be writing the same instance of the static 
field. The example is CocoonComponentManager.checkEnvironment() which throws exception 
when environmentStack is not empty.

The problem can be even more visible in portlet environmnet (our environment in use), 
when portlet container - webapp #1 is allowed to call portlets - webapp #2-#n) 
parallelly in separate threads.

That's why the use of static ThredLocal class fields should be prohibited in all 
cocoon component classes. There must be some alternative for it.

WDYT?

Call of CocoonComponentManager.checkEnvironment in Cocoon.process() is marked as 
// TODO (CZ): This is only for testing - remove it later on
CocoonComponentManager.checkEnvironment(getLogger());

Isn't this the proper time to remove it? Or at least to have a possibility to disable 
this check?
Thank you,

Michal

Attch: classes using the ThreadLocal static field:

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