Le mar 17/06/2003 � 08:25, Craig R. McClanahan a �crit : > On Mon, 16 Jun 2003, Nicolas Mailhot wrote: > > > Date: 16 Jun 2003 20:50:45 +0200 > > From: Nicolas Mailhot <[EMAIL PROTECTED]> > > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > > Subject: Logging packaging questions > > > > [ This message is crossposted between commons-dev and jpackage-discuss. > > Please keep the crosspost while replying - most interested parties won't > > be subscribed to more than one of the lists ] > > > > Hi, > > > > The jpackage project (http://www.jpackage.org/) is a volunteer project > > devoted to providing clean linux rpm packages of java stuff. Since Linux > > core processes permit very fine control of what's actually installed on > > the system, one of our main goals is to enable component sharing instead > > of the usual java practise of having a copy of every single needed jar > > in every single app. Since every library is only installed once on the > > system, it must be installed right to please every user app. (OTOH this > > allows ugrading a component in every app at once instead of having to > > rebuild all the users). Applications use a common script framework to > > build classpathes out of available jars and/or create symlinks when they > > need directories of jars to run. > > > > One of the subtle problems you'll run into with Java classes, however, is > that the library you are trying to include this way ***must*** know that > it is being used in this manner -- class a.b.c.Foo loaded from class > loader A is *not* the same class as class a.b.c.Foo loaded from class > loader B, even though the bytecodes are identical. Furthermore, the > classes that are visible to that class are different as well. > > It is ENTIRELY too simplistic to assume that any given JAR can actually be > shared in the manner you are describing. The most common scenario is in a > servlet container, where a class Foo made available in a JAR file in the > "/WEB-INF/lib" directory will work, where the same class Foo made > available through a parent class loader (such as putting it in the > common/lib directory under Tomcat, perhaps via a symbolic link) will fail.
Sure. I didn't say we put everything in a single dir in tomcat. We have big_directory_with_all_jars and symlinks to it from the various tomcat & webapp dirs tomcat uses to build the classpathes. And the links are rebuild at tomcat startup time to match the jvm actually used (ie jdbc-stdext & friends) What happened is that since commons and log4j are always physically installed in big_directory_with_all_jars the classpath manifest would suck them in whether the user wanted it or not. > Bottom line -- your packaging approach is promising far more than it can > deliver unless you indivisually certify the JAR files in question to make > sure they will operate in such a mode. Just as one relevant example -- > trying to use struts.jar from a Struts 1.0 distribution is > ***guaranteed*** to fail. Using a struts.jar from a Struts 1.1 > distribution might work, but it is absolutely not guaranteed. > > > This is a rather unusual setup (even if our users love it) and as a > > result we tend to find problems other people miss. The most recent one > > involves tomcat4,commons-logging and log4j. I won't bore you with > > technicalities (the whole discussion is available at the > > http://lists.zarb.org/pipermail/jpackage-discuss/2003-June/002084.html > > url, and I think it even overflows in a few other threads) but we found > > we needed some changes in commons-logging jar structure and we'd rather > > have them into jakarta proper instead of branching stuff (we've been > > providing official linux rpms of jakarta stuff and we'd rather keep it > > that way). > > > > Anyway : > > > > 1. we absolutely need removal of the log4j classpath entries in the > > generated jar manifests (as a rule we consider classpathes in manifests > > evil since they result in subtle behaviours no human can really handle. > > They won't work most of the time and when they do it's not like the user > > intended). We do not want log4j stealth-drawn into the classpath if > > present like it is now and users want control of the actual logging > > backend used. > > > > The Log4J classpath entries were remnoved prior to the 1.0.3 release of > Commons Logging. What version are you working with? An older one it seems. Thanks. > > 2. we'd like the build-in backends split from the main jar so we can > > made them optional and allow people not to install them if they already > > have log4j or a 1.4 jvm. > > > > In the specific case of commons-logging and Log4J, that suggestion (which > led to the existence of commons-logging-api.jar) has been an absolute > disaster. Remember that the commons-logging library is supposed to (and > does, at least with 1.0.3) dynamically adapt to whether Log4J is present > or not. If Log4J is not available, the default behavior will operate > correctly, with NO need for separating the Log4J-specific implementation > classes. As I wrote we have means to ensure a correct backend is present - we do not need the jar to do autodetection for us. > > 3. people have asked for further splittage of the backend glue so they > > can only install the parts relevant to the backend they'll actually use > > (ie separate log4j, jdk 1.4, avalon... parts). > > > > In linux speak that would get us : > > > > commons-logging frontend requires commons-logging-backend > > commons-logging-log4 provides commons-logging-backend requires log4j > > commons-logging-jdk provides commons-logging-backend requires java >= > > 1.4.0 > > commons-logging-simple provides commons-logging-backend > > > > and so on, each package consisting of a single jar with no classpath in > > its manifest. > > > > I realise I've not been as terse as I wanted to so I'll stop now. Just > > ask if I wasn't clear enough. > > > > As a very-very-very long time Java developer, and a primary contributor to > many Apache projects (including Tomcat and Struts), I strongly suggest > that you push back on the users asking for this -- they're not > understanding the real issues involved. If we did what they want, it's > not really going to solve the problems they think they have. Please bear in mind we are *not* your usual java context. The requires I wrote about are not "things people must read in a doc and abide with"). They are hardwired in the system and *must* be satisfied at installation time, regardless of users sloppiness. What problems could this split cause if the previous conditions were satisfied ? Cheers, -- Nicolas Mailhot
signature.asc
Description: Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
