cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: JDK 1.2 vs 1.1: my final proposal
Date Wed, 29 Mar 2000 12:29:15 GMT
Niclas Hedhman wrote:
> 
> 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.

FYI, Cocoon 1.7.1-dev is _perfectly_ able to load classes from zone
repositories (so custom classloaders) on both JDK 1.2.2 and JDK 1.1.8.

The only problem is for "resources" that are inside jar archives (as for
XSP logicsheets) and accessed by JServ AdaptiveClassLoader. This is
because the code for jar extraction is based on the "jar://" URL which
is _NOT_ available on all JVMs.

So, this is -NOT- a 1.1 vs. 1.2 problem, but a problem with some JServ
code (and Tomcat since it's using the same exact code) and I'm trying to
find a good solution for it.

Help welcome.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message