axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: yank log4j jar from dist?
Date Mon, 04 Apr 2005 10:50:28 GMT
Davanum Srinivas wrote:
> Since we don't really need it? Should we yank it from dist?
> see
> thanks,
> dims

He had the complete set of problems, with endorsed directories, etc, 
etc. At least happyaxis.jsp identified the existence of trouble. Maybe 
we should extend it with log4j enhancements.

I do agree there is a problem with JAR files and it is more fundamental 
than just what we include here. Expect lots of coverage of this in the 
second edition of Java Development with Ant :)

-Java1.4's endorsed directories was a mistake. Java1.5 rolls things back 
a bit, by renaming the apache packages.

-signing doesnt cut it. Once you sign jars the classloader starts to act 
different; you cant add new code into the same packages 'cept when they 
are signed too. Which is painful in OSS stuff.

-The maven repository stuff is more interesting. If you have a central 
cache of files stored as /project/artifact-version.jar, then you can 
declarative switch versions. This is essentially .NET's GAC, without the 
strong names. You could use it with maven, ant, or something a bit like 
ant that only launches programs; an XML app launcher (tomcat uses ant 
for this, but I am doing the repository stuff in smartfrog for a managed 

I've argued a bit on the apache repository mail list (centre of 
discourse about repository stuff on apache) for using strong names in 
versions. So instead of log4j-1.2.jar, you'd also have, via the wonder 
of symlinks


the advantage of this approach is (a) no confusion about versions, (b) 
explicit security in your downloads, when you go
<library project="log4j" version="4f32acb4def" /> then the downloader 
can verify the checksum after download, as it has the checksum already.


returning to log4j, its less essential in java1.5 as it used to be. and 
pulling it stops the ant tasks telling you off for not having a 
non-default log4j config (that message really irritates me, I dont see 
why I should be told off by log4j there). So pulling it would be 
tractable. This person's problems go much deeper than log4j; they go 
into WAR vs EAR vs JBoss classloader policies.


View raw message