yank log4j jar from dist?

[Davanum Srinivas <da...@gmail.com>]

Since we don't really need it? Should we yank it from dist?
see http://blogs.msdn.com/dotnetinterop/archive/2005/03/31/404087.aspx

thanks,
dims

-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: yank log4j jar from dist?

[Steve Loughran <st...@apache.org>]

Davanum Srinivas wrote:
> Since we don't really need it? Should we yank it from dist?
> see http://blogs.msdn.com/dotnetinterop/archive/2005/03/31/404087.aspx
> 
> 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 
launcher)


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

log4j-4f32acb4def.jar

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.

-steve