cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From H.vanderLin...@MI.unimaas.nl
Subject RE: build failed on JavaFlow in current CVS HEAD
Date Thu, 29 Apr 2004 13:17:12 GMT
Stefano and Bruno, 

thanks for the explanation. I'm probably more of a "hobby programmer" for
not knowing the details on class loaders. :-( More study to do then.

Reading your explanation I agree that it sounds obvious that there should be
another bcel version around, but it gets weirder: I have 1 Cocoon CVS
repository (which I had just updated), which I keep "clean" (i.e. no local
modifications), no default CLASSPATH setting (Windows XP) and I just ran the
default "build clean", "build" in the root of the CVS repository. So if
there's another BCEL around, it should be somewhere in the Cocoon CVS tree.
:-( I've searched high and low, but I could only find one
(jakarta-bcel*.jar).

Bye, Helma


> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org] 
> Sent: Thursday, 29 April 2004 14:54
> To: dev@cocoon.apache.org
> Subject: Re: build failed on JavaFlow in current CVS HEAD
> 
> 
> H.vanderLinden@MI.unimaas.nl wrote:
> 
> > Thanks, that solved the problem.
> > 
> > Why on earth does it make a difference where a jar is located? :-(
> > 
> > Bye, Helma
> 
> Because the way the JVM loads classes is different. 
> /lib/endorsed is the 
> first place the JVM looks for stuff, this was done to allow people to 
> have newer versions of the libraries that are shipped with 
> the JVM (like 
> Xerces, for example)
> 
> I agree it's a massive hack and a real problem.
> 
> BTW, this seems to show that you have another BCEL version in your 
> classpath and that the cocoon build system is picking up that one 
> instead of the one that cocoon itself ships. Moving it into 
> 'endorsed' 
> make the JVM load classes from this version rather than your own.
> 
> You might want to consider cleaning up your classpath: it is 
> a very bad 
> idea to fix your classpath in your environment (or to put 
> stuff in the 
> lib/ext or lib/endorsed path of your JVM) Much better to fix 
> the paths 
> in script files that invoke the JVM.
> 
> I'm always amazed by how elegant the classloading mechanism 
> in java is 
> and how poor its core implementation (using classpaths and stupid 
> locations like lib/ext and lib/endorsed), it's clear that different 
> people worked on it. The first was a group of smart people, the other 
> was a bunch of idiots that though that you only needed one 
> JVM on your 
> machine at any given time.
> 
> HTH
> 
> -- 
> Stefano.
> 
> 

Mime
View raw message