cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@localbar.com>
Subject Re: JDK 1.2 vs 1.1: my final proposal
Date Wed, 29 Mar 2000 06:35:52 GMT
rubys@us.ibm.com wrote:

> Niclas Hedhman wrote:
> >Also;  I suggest that 1.2 is required for recompilation of the package,
> >since then certain sections can have conditionals of how to handle the
> >situation. Especially classloading.
>
> Can you explain a little more?  As a developer on Tomcat, I can say that we
> have yet to run into that situation.

Class.forName() is a poor solution for dynamic classloading in
multi-classloader environments, such as servlet engines.
( Please read the document
http://envision.asiaconnect.com.my/docs/guides/classloaders.pdf if you don't
fully understand 1.2 classloading  mechanics. )
I am not absolutely clear about this topic myself, but I had major problems
Now, you can deploy Cocoon in many ways, and perhaps manage to get a workable
solution by putting Cocoon in each zone.
But assuming that Cocoon will be a "real" web publishing system for mulitple
zones, it will definately not be possible to have Cocoon as an extension, and
each "zone owner" deploying their own Generators and stuff. I would also
expect some hazzle in the XSP arena in combination with classloading.

The solution is the Context Classloader, introduce to overcome this problems.
And that is 1.2 specific.
But what you could do is write the code, such as

if( System.getProperty("java.lang.specification").equals( "1.2") )
    clazz =
Thread.currentThread().getContextClassLoader().loadClass(classname);
else
    clazz = Class.forName( classname );

(Or whatever the system property is for checking versions.)
That will execute propertly on 1.1 systems, but not compile properly unless
1.2.

Or better yet, extract these things out in two different classes, and have
Cocoon load them accordingly at startup for better performance.

Niclas



Mime
View raw message