You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Nicolas Mailhot <Ni...@laPoste.net> on 2003/06/16 20:50:45 UTC
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.
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.
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.
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.
Regards,
--
Nicolas Mailhot
Re: Logging packaging questions
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Nicolas!
NM> 3. people have asked for further splittage of the backend glue so they
NM> can only install the parts relevant to the backend they'll actually use
NM> (ie separate log4j, jdk 1.4, avalon... parts).
It seems 2 me I've got a solution for you :-)
1) Let's look at the way commons-logging initialization goes in
LogFactory. (I assume this is the access point for all the
loggers).
LogFactory (yes you need to look into its source) static
methods try to load a proper instance extending
LogFactory abstract class (it's static getFactory() method)
To do so they follow a specific sequence:
1) system-wide property, org.apache.commons.logging.LogFactory
2) META-INF/services/org.apache.commons.logging.LogFactory
resource obtained from the context class loader
3) commons-logging.properties
resource obtained from the context class loader
4) fall back to org.apache.commons.logging.impl.LogFactoryImpl
2) but the META-INF/services/... approach is _not_ really
used by commons-logging out of the box.
In fact only two classes extending LogFactory abstract
class are supplied: Log4jFactory and LogFactoryImpl.
But, LogFactoryImpl itself is a universal factory, it
uses the
org.apache.commons.logging.Log
system-wide property by itself to choose what loggers it
will create and if does not find one it tries
Log4J
JDK1.4
buit-in
in that order.
3) So, in fact your proposition, Nicolas, wouldn't work in its
most simplistic form. It is not enough to spread the
existing classes over several jars to make the machinery
work.
4) What can we do?
_If_ we had a dedicated factory for each type of logging
backend (which we don't, we have a universal one)
then we could package each dedicated factory into a separate jar
along with a proper
META-INF/services/org.apache.commons.logging.LogFactory
But then, _if_ we really had a dedicated factory for each type
of logging backend, we could still have all these factories
packed into one common jar, and make each of the following jars
commons-logging-log4j-glue.jar
commons-logging-jdk14-glue.jar
commons-logging-buitin-glue.jar
contain _only_ the
META-INF/services/org.apache.commons.logging.LogFactory
file pointing to the correct implementation (yes, I guess
it may be a bit out of line with jar spec, but why not?)
Naturally these jars are so simple, that you, Nicolas, can provide
them on your own.
5) Now, we do not have a didicated factory for JDK14 logging and for
builtin loggging. We do have one for Log4J, but everybody is probably
using the universal factory instead, so this dedicated factory is
probably ill tested.
What can we do?
One option IMO would be to subclass LogFactoryImpl (the universal
factory) three times each time overriding its
protected String getLogClassName()
method. This way we shall have three deicated factories, otherwise
identical to the universal factory and equally well tested as the
universal factory.
These classes are also so simplistic that you, Nicolas may provide
them yourselves and package along with corresponding
META-INF/services/org.apache.commons.logging.LogFactory
file into your glue jars.
Isn't this a complete solution for you? ;-)
6) This all being said I would actually also like to configure
commons-logging backend used by providing a proper glue
jar and not via a system property.
(This is probably why I have taken Nicolas's mail so close
to heart, our likings seem to match :-)
That's why I would also like to have these "glue" jars
that switch my backend at my disposal independently of
the http://www.jpackage.org/ project.
Developers (I'm only a lowely user in _this_ list :-),
what do you think of this wish?
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Logging packaging questions
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 30 Jun 2003, Anton Tagunov wrote:
> Date: Mon, 30 Jun 2003 14:39:46 +0400
> From: Anton Tagunov <at...@mail.cnt.ru>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> jpackage-discuss@zarb.org
> Subject: Re: Logging packaging questions
>
> Hello Nicolas!
>
> NM> 2. we'd like the build-in backends split from the main jar so we can
> NM> made them optional and allow people not to install them if they already
> NM> have log4j or a 1.4 jvm.
>
> Lurker's opinion :)
>
> I want to say I like your ideas very much.
>
> war-s are great too, but putting _all_ into the main server classpath,
> be it Tomcat or JBoss generally works too;
Boy are YOU in for some nasty surprises :-).
Doing this wil absolutely NOT work unless the library classes you are
doing them to are specifically designed to work in this manner.
Otherwise, you are very likely to get mysterious ClassNotFoundException
and ClassCastException problems.
> I used to work in this
> style.. And if it was a bit more manageable (what your project is
> struggling for) it would be just fine.
As a pointer to some of the problems you might encounter, please consider
the Struts User Guide's take on putting struts.jar (and friends) in a
server classpath or shared code repository:
http://jakarta.apache.org/struts/userGuide/configuration.html#config_add
>
> I guess problems will come if part of the jars are in WEB-INF/lib
> and part on the main classpath, but if you put all on the classpath
> it will generally work, I believe.
Not necessarily. Duplicate classes is only one of the potential problems.
>
> And yes, I've heard that you simlink to WEB-INF-s too.
>
> Now, did I get it right that _despite_ jakarta-logging will be shipped
> as a single jar all your stuff _will_ work okay since jakarta-logging
> will detect what is available on the classpath and what is not?
>
> -Anton
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re[6]: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Nicolas!
AT> Just hold on a minute, and if the user wanted to use Jdk14 logging
AT> where would the common-loggin-backend point to?
NM> To the in-jvm jar that provides logging - that works for jdbc, jsse,
NM> jndi , etc.
Uggghhmmm... I thought it was the case with 1.3 -- al this was
added via additional jars. As for 1.4 all is in rt.jar, isn't it?
Then you would probably need some very simplistic (empty)
dummy.jar to wire your dangling links too, I think.
See my mail on the other thread, probably the clue to your
problem is there!
Good luck! :-)
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Re[4]: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Nicolas Mailhot <Ni...@laposte.net>.
Le mar 01/07/2003 à 12:07, Anton Tagunov a écrit :
> Hi!
>
> NM> A symlink points to whatever logging-commons-backend jar is installed
> NM> (more complex than that but lets just say the symlink *will* exist and
> NM> point to the jar with the highest priority)
> AT>
> AT> Would this symlink point to commons-logging-log4j.jar or to log4j.jar?
>
> NM> If we do the full split we'd have
> NM> - common-loggin main jar
> NM> - common-loggin-glue symlink
> NM> - common-loggin-backend symlink
>
> NM> with common-loggin-glue & common-loggin-backend synchronized so if
> NM> common-loggin-backend points to log4j common-loggin-glue points to the
> NM> log4j glue in common-loggin
>
> NM> One or two symlinks - that's peanuts.
> NM> What we can not handle is one jar present in some cases (log4j) and not
> NM> in others. We need the symlinks to always point to something - dangling
> NM> symlinks make tomcat crash
>
> Just hold on a minute, and if the user wanted to use Jdk14 logging
> where would the common-loggin-backend point to?
To the in-jvm jar that provides logging - that works for jdbc, jsse,
jndi , etc.
Cheers,
--
Nicolas Mailhot
Re[4]: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hi!
NM> A symlink points to whatever logging-commons-backend jar is installed
NM> (more complex than that but lets just say the symlink *will* exist and
NM> point to the jar with the highest priority)
AT>
AT> Would this symlink point to commons-logging-log4j.jar or to log4j.jar?
NM> If we do the full split we'd have
NM> - common-loggin main jar
NM> - common-loggin-glue symlink
NM> - common-loggin-backend symlink
NM> with common-loggin-glue & common-loggin-backend synchronized so if
NM> common-loggin-backend points to log4j common-loggin-glue points to the
NM> log4j glue in common-loggin
NM> One or two symlinks - that's peanuts.
NM> What we can not handle is one jar present in some cases (log4j) and not
NM> in others. We need the symlinks to always point to something - dangling
NM> symlinks make tomcat crash
Just hold on a minute, and if the user wanted to use Jdk14 logging
where would the common-loggin-backend point to?
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Re[2]: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Nicolas Mailhot <Ni...@laposte.net>.
Le mar 01/07/2003 à 11:37, Anton Tagunov a écrit :
> Hello Nicolas!
>
> NM> A symlink points to whatever logging-commons-backend jar is installed
> NM> (more complex than that but lets just say the symlink *will* exist and
> NM> point to the jar with the highest priority)
>
> Would this symlink point to commons-logging-log4j.jar or to log4j.jar?
> (Just thinking your worlds over)
If we do the full split we'd have
- common-loggin main jar
- common-loggin-glue symlink
- common-loggin-backend symlink
with common-loggin-glue & common-loggin-backend synchronized so if
common-loggin-backend points to log4j common-loggin-glue points to the
log4j glue in common-loggin
One or two symlinks - that's peanuts.
What we can not handle is one jar present in some cases (log4j) and not
in others. We need the symlinks to always point to something - dangling
symlinks make tomcat crash
Regards,
--
Nicolas Mailhot
Re[2]: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Nicolas!
NM> A symlink points to whatever logging-commons-backend jar is installed
NM> (more complex than that but lets just say the symlink *will* exist and
NM> point to the jar with the highest priority)
Would this symlink point to commons-logging-log4j.jar or to log4j.jar?
(Just thinking your worlds over)
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Nicolas Mailhot <Ni...@laposte.net>.
Le mar 01/07/2003 à 10:08, Anton Tagunov a écrit :
> Hello Nicolas!
>
> AT> Now, did I get it right that _despite_ jakarta-logging will be shipped
> AT> as a single jar all your stuff _will_ work okay since jakarta-logging
> AT> will detect what is available on the classpath and what is not?
>
> NM> Basically if/when we had split the backends we'd had provided a backends
> NM> symlinks pointing either to log4j, jvm or build-in (with automated
> NM> priorities). This symlink would have been added to all the logging users
> NM> classpaths/jer directories
>
> NM> So we would have insured there was always a backend on the system,
> NM> without duplicating classes.
>
> NM> The current solution will be the death of log4j since no one will take
> NM> the pain to put it manually in the classpath (as it would have, if the
> NM> split had proceeded)
>
> I'm sorry, Nicolas, I do not get you.
> What is the difference between putting
> jakarta-logging-log4j.jar
> into the classpath that automatically pulls in log4j.jar
> and putting there
> log4j
> jar directly?
>
> What has changed? Why one is more difficult for users of your
> framework then the other?
With a properly modularized setup we can do :
package logging-commons requires logging-commons-backend
split build-in, log4j, jvm, provide logging-commons-backend
A symlink points to whatever logging-commons-backend jar is installed
(more complex than that but lets just say the symlink *will* exist and
point to the jar with the highest priority)
All apps are packaged so they have the symlink in their classpath or
their jar repository.
log4j have > priority than other backends for the symlink.
So if log4j is installed, it'll be used by every app.
Now since we do not have this symlink people have to add log4j manually
if they absolutely want it, and since they are as lazy as the next guy
they won't.
Goodbye log4j. RIP
Regards,
--
Nicolas Mailhot
Re: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Nicolas Mailhot <Ni...@laposte.net>.
Le mar 01/07/2003 à 10:08, Anton Tagunov a écrit :
> Hello Nicolas!
>
> AT> Now, did I get it right that _despite_ jakarta-logging will be shipped
> AT> as a single jar all your stuff _will_ work okay since jakarta-logging
> AT> will detect what is available on the classpath and what is not?
>
> NM> Basically if/when we had split the backends we'd had provided a backends
> NM> symlinks pointing either to log4j, jvm or build-in (with automated
> NM> priorities). This symlink would have been added to all the logging users
> NM> classpaths/jer directories
>
> NM> So we would have insured there was always a backend on the system,
> NM> without duplicating classes.
>
> NM> The current solution will be the death of log4j since no one will take
> NM> the pain to put it manually in the classpath (as it would have, if the
> NM> split had proceeded)
>
> I'm sorry, Nicolas, I do not get you.
> What is the difference between putting
> jakarta-logging-log4j.jar
> into the classpath that automatically pulls in log4j.jar
> and putting there
> log4j
> jar directly?
>
> What has changed? Why one is more difficult for users of your
> framework then the other?
With a properly modularized setup we can do :
package logging-commons requires logging-commons-backend
split build-in, log4j, jvm, provide logging-commons-backend
A symlink points to whatever logging-commons-backend jar is installed
(more complex than that but lets just say the symlink *will* exist and
point to the jar with the highest priority)
All apps are packaged so they have the symlink in their classpath or
their jar repository.
log4j have > priority than other backends for the symlink.
So if log4j is installed, it'll be used by every app.
Now since we do not have this symlink people have to add log4j manually
if they absolutely want it, and since they are as lazy as the next guy
they won't.
Goodbye log4j. RIP
Regards,
--
Nicolas Mailhot
Re[2]: Logging packaging questions
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Nicolas!
AT> Now, did I get it right that _despite_ jakarta-logging will be shipped
AT> as a single jar all your stuff _will_ work okay since jakarta-logging
AT> will detect what is available on the classpath and what is not?
NM> Basically if/when we had split the backends we'd had provided a backends
NM> symlinks pointing either to log4j, jvm or build-in (with automated
NM> priorities). This symlink would have been added to all the logging users
NM> classpaths/jer directories
NM> So we would have insured there was always a backend on the system,
NM> without duplicating classes.
NM> The current solution will be the death of log4j since no one will take
NM> the pain to put it manually in the classpath (as it would have, if the
NM> split had proceeded)
I'm sorry, Nicolas, I do not get you.
What is the difference between putting
jakarta-logging-log4j.jar
into the classpath that automatically pulls in log4j.jar
and putting there
log4j
jar directly?
What has changed? Why one is more difficult for users of your
framework then the other?
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Logging packaging questions
Posted by Nicolas Mailhot <Ni...@laPoste.net>.
Le lun 30/06/2003 à 12:39, Anton Tagunov a écrit :
> Hello Nicolas!
>
> NM> 2. we'd like the build-in backends split from the main jar so we can
> NM> made them optional and allow people not to install them if they already
> NM> have log4j or a 1.4 jvm.
>
> Lurker's opinion :)
>
> I want to say I like your ideas very much.
>
> war-s are great too, but putting _all_ into the main server classpath,
> be it Tomcat or JBoss generally works too; I used to work in this
> style.. And if it was a bit more manageable (what your project is
> struggling for) it would be just fine.
>
> I guess problems will come if part of the jars are in WEB-INF/lib
> and part on the main classpath, but if you put all on the classpath
> it will generally work, I believe.
>
> And yes, I've heard that you simlink to WEB-INF-s too.
>
> Now, did I get it right that _despite_ jakarta-logging will be shipped
> as a single jar all your stuff _will_ work okay since jakarta-logging
> will detect what is available on the classpath and what is not?
Basically if/when we had split the backends we'd had provided a backends
symlinks pointing either to log4j, jvm or build-in (with automated
priorities). This symlink would have been added to all the logging users
classpaths/jer directories
So we would have insured there was always a backend on the system,
without duplicating classes.
The current solution will be the death of log4j since no one will take
the pain to put it manually in the classpath (as it would have, if the
split had proceeded)
Cheers,
--
Nicolas Mailhot
Re: Logging packaging questions
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Nicolas!
NM> 2. we'd like the build-in backends split from the main jar so we can
NM> made them optional and allow people not to install them if they already
NM> have log4j or a 1.4 jvm.
Lurker's opinion :)
I want to say I like your ideas very much.
war-s are great too, but putting _all_ into the main server classpath,
be it Tomcat or JBoss generally works too; I used to work in this
style.. And if it was a bit more manageable (what your project is
struggling for) it would be just fine.
I guess problems will come if part of the jars are in WEB-INF/lib
and part on the main classpath, but if you put all on the classpath
it will generally work, I believe.
And yes, I've heard that you simlink to WEB-INF-s too.
Now, did I get it right that _despite_ jakarta-logging will be shipped
as a single jar all your stuff _will_ work okay since jakarta-logging
will detect what is available on the classpath and what is not?
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Logging packaging questions
Posted by Leonid Dubinsky <du...@podval.org>.
Craig R. McClanahan wrote:
>> 1. we absolutely need removal of the log4j classpath entries
>
>
> The Log4J classpath entries were remnoved prior to the 1.0.3 release of
> Commons Logging. What version are you working with?
Looks like we are working with 1.0.3, which was released on April the 7th;
classpath entries were removed on April the 17th, so we still have them...
We just discovered that you already removed them, so by removing them in
JPackage we'll be moving closer to the original, not further :)
>> 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.
It is that default behavior - SimpleLog - that is the target of this separation from
the rest of the commons-logging. I think that such a separation will cause
even bigger disaster, because unconfigured log4j will be used by default,
and all logging will cease...
About commons-logging-api.jar/commons-logging.jar: it seems that one
is a superset of the other, and not a complement. I wonder why...
Also: will this separation be eliminated?
>> 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
>
>
> 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.
Craig, I am the people in question :)
I did not suggest that to solve any problems I am having, but as a separation
more meaningful, IMHO, than the separation of SimpleLog from the
commons-logging APIs...
I gather you are strongly against separating glue from the interface :)
Can you please hint at what *are* the real issues involved, so that I can learn
from your experience?
Wasn't the split c-l-api/c-l such a separation (albeit not as fine-grained)?
And in general, if I have provider-based architecture where each provider
is actually a proxy/adaptor to an existing service, why must all available
adaptors be bundled with the generic interface classes, and not with the
corresponding services/adaptees - or completely unbundled?
Respectfully,
Leonid Dubinsky.
P.S. Thanks for everything, including JSF!
D.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Logging packaging questions
Posted by Henri Gomez <hg...@users.sourceforge.net>.
> 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.
+1, we should recognize someone who spent hours on tomcat-users list and
who know that a 10 minutes developper fix, could produce days and days
of question on user lists.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Logging packaging questions
Posted by Nicolas Mailhot <Ni...@laPoste.net>.
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 <Ni...@laPoste.net>
> > Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> > jpackage-discuss@zarb.org
> > To: commons-dev@jakarta.apache.org
> > Cc: jpackage-discuss@zarb.org, hgomez@users.sourceforge.net
> > 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
Re: Logging packaging questions
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 16 Jun 2003, Nicolas Mailhot wrote:
> Date: 16 Jun 2003 20:50:45 +0200
> From: Nicolas Mailhot <Ni...@laPoste.net>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> jpackage-discuss@zarb.org
> To: commons-dev@jakarta.apache.org
> Cc: jpackage-discuss@zarb.org, hgomez@users.sourceforge.net
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Logging packaging questions
Posted by Richard Sitze <rs...@us.ibm.com>.
Hence the need to maintain commons-logging.jar AS-IS.
We already HAVE commons-logging-api.jar, we simply need to add new jar
files for each implementation 'flavor'. Consideration could be given to
including a commons-logging.properties file that configures the logger,
though there are pro/cons with that.
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
Nicolas Mailhot wrote:
>>If the split goes through,
>>the situation is likely to arise where log4j is used as a
commons-logging
>>backend, but since log4j is not configured by default, all the
commons-logging
>>logging will be automatically brocken. Come to think of it, this is
exactly
>>what we have now, without the split, and looks like we are not happy :)
>
> Since this is exactly what we have now the split would not make it
> worse.
It will. Much worse.
What we have now can be fixed by removing the 'Class-Path:' entries.
After that, only those who put log4j on classpath *manually* and do
not configure it will have their logging brocken.
If the split happens, any naive user who believes that he can use
log4j as a backend for commons-logging and does not install
SimpleLog - or installs it, but does not override the alternatives so
that log4j is *not* used - will have his logging brocken.
> So there is no reason not to go for the split because we know the
> other benefits we'll get.
I think that working setup is preferrable to better modularization :)
I'd like to have both, but it looks that we can't.
Unless you persuade log4j developers to make it self-configured.
> It is commons-logging responsibility IMHO to do initial log4j
> configuration if its used - commons is supposed to hide the backend so
> why should we know something about it ?
This question is best answered by the bug 13201 description
(http://issues.apache.org/bugzilla/show_bug.cgi?id=13201):
I am requesting that the code added to Log4JCategory in
commons-logging-1.0.1 that sets up a default initialization in log4j be
removed.
Why? When I put 1.0.1 in place of 1.0, I started getting extraneous
messages logged to the console. Subsequent research led me to the new
initialization code in Log4JCategory. The problem is in the way the
initialization code tries to decide if log4j has been configured. It
assumes that the root category has been configured with an appender. I
happen to have a log4j properties configuration that doesn't configure
an appender, so the initialization code couldn't tell that log4j had
been configured, it created the default root appender, and I started
getting the extraneous messages.
I realize there are easy workarounds for my particular problem, but I
believe this presents a more philosophical issue. Quoting from the
commons-logging api org.apache.commons.logging package description:
"The basic principle is that the user is totally responsible for the
configuration of the underlying logging system. Commons-logging should
not change the existing configuration."
The code in question directly violates this expressly stated principal
and is inappropriate. Allowing this code to remain opens a Pandora's
box
of attempts to configure the underlying logger, which should be
resisted
based on the above principal.
> [ and this part is related to the crossposted message so please add
> these remarks to the common thread ]
Done!
Regards,
Leonid Dubinskly.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Logging packaging questions
Posted by Leonid Dubinsky <du...@podval.org>.
Nicolas Mailhot wrote:
>>If the split goes through,
>>the situation is likely to arise where log4j is used as a commons-logging
>>backend, but since log4j is not configured by default, all the commons-logging
>>logging will be automatically brocken. Come to think of it, this is exactly
>>what we have now, without the split, and looks like we are not happy :)
>
> Since this is exactly what we have now the split would not make it
> worse.
It will. Much worse.
What we have now can be fixed by removing the 'Class-Path:' entries.
After that, only those who put log4j on classpath *manually* and do
not configure it will have their logging brocken.
If the split happens, any naive user who believes that he can use
log4j as a backend for commons-logging and does not install
SimpleLog - or installs it, but does not override the alternatives so
that log4j is *not* used - will have his logging brocken.
> So there is no reason not to go for the split because we know the
> other benefits we'll get.
I think that working setup is preferrable to better modularization :)
I'd like to have both, but it looks that we can't.
Unless you persuade log4j developers to make it self-configured.
> It is commons-logging responsibility IMHO to do initial log4j
> configuration if its used - commons is supposed to hide the backend so
> why should we know something about it ?
This question is best answered by the bug 13201 description
(http://issues.apache.org/bugzilla/show_bug.cgi?id=13201):
I am requesting that the code added to Log4JCategory in
commons-logging-1.0.1 that sets up a default initialization in log4j be
removed.
Why? When I put 1.0.1 in place of 1.0, I started getting extraneous
messages logged to the console. Subsequent research led me to the new
initialization code in Log4JCategory. The problem is in the way the
initialization code tries to decide if log4j has been configured. It
assumes that the root category has been configured with an appender. I
happen to have a log4j properties configuration that doesn't configure
an appender, so the initialization code couldn't tell that log4j had
been configured, it created the default root appender, and I started
getting the extraneous messages.
I realize there are easy workarounds for my particular problem, but I
believe this presents a more philosophical issue. Quoting from the
commons-logging api org.apache.commons.logging package description:
"The basic principle is that the user is totally responsible for the
configuration of the underlying logging system. Commons-logging should
not change the existing configuration."
The code in question directly violates this expressly stated principal
and is inappropriate. Allowing this code to remain opens a Pandora's box
of attempts to configure the underlying logger, which should be resisted
based on the above principal.
> [ and this part is related to the crossposted message so please add
> these remarks to the common thread ]
Done!
Regards,
Leonid Dubinskly.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Logging packaging questions
Posted by Richard Sitze <rs...@us.ibm.com>.
1. Log4j was eliminated from classpath (4/17). Last release (1.0.3) is
dated 4/7. You need to push for a new release.
2/3. We do have a 'core' package: commons-logging-api.jar.
+1 to individual sub-jars for each logger implementation.
I believe the fundamental idea has been suggested before, we simply need
someone with time on their hands. Any of your users is welcome to submit
a new build.xml. We will want to maintain the existing
commons-logging.jar (everything) for those who have become addicted to
code they don't need in their runtime :-)
Separating the API's from the implemenations begs for separate versioning
(API's ought to stay relatively stable, implementations should be
versioned independently). Without proper separation, this could get
uglier than it needs to be.
<b>Is there a jakarta/apache process for versioning subcomponents
independently?</b>
<ras>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
[ 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.
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.
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.
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.
Regards,
--
Nicolas Mailhot