Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42511BF4.1080309@apache.org>
Date: Mon, 04 Apr 2005 11:50:28 +0100
From: Steve Loughran <stevel@apache.org>
User-Agent: Mozilla Thunderbird 0.7 (X11/20040615)
MIME-Version: 1.0
To: axis-dev@ws.apache.org
Subject: Re: yank log4j jar from dist?
References: <19e0530f05040315381d29bc8b@mail.gmail.com>
In-Reply-To: <19e0530f05040315381d29bc8b@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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