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. 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? > 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. > 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. > Regards, > > -- > Nicolas Mailhot > Craig McClanahan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
