Sharing cocoon.jar between multiple web aplications

[ĎURDINA Michal <Mi...@assetsoft.sk>]

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

Re: Sharing cocoon.jar between multiple web aplications

[peter royal <pr...@pace2020.com>]

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