You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Costin Manolache <cm...@yahoo.com> on 2003/04/24 16:29:06 UTC
Re: Why commons-logging-api.jar?
The reason is very simple - and you actually know it.
> Especially in light of numerous problems with unfound factories,
> incompatible classes, unimplemented methods, ... all of which are
> class loader related.
Most of those problems are traced to the fact that commons-logging is
forced to include adapters for log4j and logkit.
commons-logging-api contains only the logging API and things that don't
depend on external packages. If you want to use log4j - you must deploy
log4j and the adapter for log4j ( which currently means commons-logging.jar,
the full package, since there is no standalone adapter ).
Costin
>
> I am stumped.
>
> At 02:10 AM 4/24/2003 -0700, you wrote:
>>Actually, I believe that the 4.1 developers simply followed the pattern of
>>the 3.3 (the only Tomcat version that supports log4j as an installed
>>extension :) devlopers on this one. TC 3.3 has a delegating cl model, so
>>to work we needed the split.
>>
>>----- Original Message -----
>>From: "Ceki Gülcü" <ce...@qos.ch>
>>To: "Tomcat Developers List" <to...@jakarta.apache.org>
>>Sent: Thursday, April 24, 2003 1:39 AM
>>Subject: Re: Why commons-logging-api.jar?
>>
>>
>>
>>At 01:16 AM 4/24/2003 -0700, Bill Barker wrote:
>> >Urm, err, the right place for this is commons-dev@jakarta.apache.org.
>>
>>I was actually more interested in why Tomcat developers chose to
>>deploy these jar files the way they did. I can of course redirect the
>>question to commons-dev.
>>
>> >The reason is to not override the copy of commons-logging.jar in
>>WEB-INF/lib
>> >(and I can tell you that I've currently got Axis working great with this
>> >config :).
>>
>>I fail to understand. Isn't the class loading mechanism in 4.1.x such
>>that jar files in WEB-INF/lib get precedence? If so, why is
>>commons-logging-api.jar needed if the web-applicaiton class loader
>>will anyhow fist use the libraries that are in WEB-INF/lib?
>>
>>Does Axis have a tree-like class loader structure like Tomcat?
>>
>>In any case, thank you for having taken the time to answer my question.
>>
>>
>> >----- Original Message -----
>> >From: "Ceki Gülcü" <ce...@qos.ch>
>> >To: <to...@jakarta.apache.org>
>> >Sent: Wednesday, April 23, 2003 11:46 PM
>> >Subject: Why commons-logging-api.jar?
>> >
>> >
>> > >
>> > > Hello all,
>> > >
>> > > Could a kind soul try to explain why commons-logging-api is needed?
>> > >
>> > > Why commons-logging-api.jar put in commons/lib but
>> > > commons-logging.jar put in server/lib?
>> > >
>> > > Any input would be much appreciated. Thanking you in advance,
>> > >
>> > >
>> > > --
>> > > Ceki For log4j documentation consider "The complete log4j manual"
>> > > http://www.qos.ch/shop/products/clm_t.jsp
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>> > >
>> >
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> >For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>--
>>Ceki For log4j documentation consider "The complete log4j manual"
>> http://www.qos.ch/shop/products/clm_t.jsp
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> --
> Ceki For log4j documentation consider "The complete log4j manual"
> http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by Remy Maucherat <re...@apache.org>.
Ceki Gülcü wrote:
> At 08:29 PM 4/24/2003 +0200, Remy Maucherat wrote:
>
>> The non delegating CL in Tomcat 4 is nothing but a source of problems,
>> which cannot be implemented to actually work. You need to have an
>> endless supply of particular workarounds for various libraries to
>> avoid class conflicts.
>>
>> I think in the case of log4j + c-l, there are issues if you attempt to
>> override. Personally, I like JDK 1.4 logger better, because it's
>> hassle free, and I have yet to see it cause applications to fail. I
>> still have a really annoying bug report open, which seems to be caused
>> by log4j, and which would also indicate that log4j creates CL
>> problems: bug 3888. You seem to insist that it's Tomcat's fault, though.
>
>
> The bug report is available here:
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888
>
> As you can see and read, all I have done is correct the log4j bug
> reported by
> Jacob Kjome possibly related to 3888. As far as I can tell, that log4j
> bug as reported by Jacob has been solved in log4j 1.2.8.
>
> Jacob Kjome has gone to great lengths to make the bug reproducible. He
> also stated on 2002-11-01 01:53 that bug #3888 was not caused by log4j.
I should have logged a full trace for that error. That would have helped
fix and debug issues.
I'm open to experiment with log4j in 5.x (since we have time to back out
if there are issue).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 08:29 PM 4/24/2003 +0200, Remy Maucherat wrote:
>The non delegating CL in Tomcat 4 is nothing but a source of problems,
>which cannot be implemented to actually work. You need to have an endless
>supply of particular workarounds for various libraries to avoid class
>conflicts.
>
>I think in the case of log4j + c-l, there are issues if you attempt to
>override. Personally, I like JDK 1.4 logger better, because it's hassle
>free, and I have yet to see it cause applications to fail. I still have a
>really annoying bug report open, which seems to be caused by log4j, and
>which would also indicate that log4j creates CL problems: bug 3888. You
>seem to insist that it's Tomcat's fault, though.
The bug report is available here:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888
As you can see and read, all I have done is correct the log4j bug reported by
Jacob Kjome possibly related to 3888. As far as I can tell, that log4j
bug as reported by Jacob has been solved in log4j 1.2.8.
Jacob Kjome has gone to great lengths to make the bug reproducible. He
also stated on 2002-11-01 01:53 that bug #3888 was not caused by log4j.
He also wrote on 2003-02-24 04:14
I actually am not getting the "INFO: Lifecycle error : CL stopped"
error unless I do Log4j configuration. However, I've somewhat ruled
out Log4j as the culprit because, although I don't get said error
printed out when I don't explicitly configure Log4j, I get the same
behavior of the context not starting after the 4th step in either
case. Doing the configure must just trigger the code that actually
prints out that debugging where that same debugging code isn't
triggered otherwise.
Note that line 644 in DOMConfigurator where the error seems to occur
just creates a new XML DocumentBuilderFactory:
line 644: dbf = DocumentBuilderFactory.newInstance();
If people reporting the bug state that it is not log4j related, then
that is good enough for me. Nevertheless, if you or anyone else has a
specific log4j bug to report, I'd be glad to fix it (if I can).
>So since the current situation works (I didn't hear about CL problems with
>4.1.24 related to logging), I'm clearly in favor of keeping the status
>quo, and will veto any related proposals for 4.1.x.
How about 17323? It was a nightmare to identify. You might also want
to read https://www.qos.ch/logging/thinkAgain.html#pe on my personal
experience with this bug.
If the logging component is not 100% reliable, then important stack
traces can get lost making it unnecessarily difficult to identify
bugs. Good and clear stack traces are one of the great advantages of
Java over languages like C.
>Remy
--
Ceki For log4j documentation consider "The complete log4j manual"
http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by Costin Manolache <cm...@yahoo.com>.
> I think in the case of log4j + c-l, there are issues if you attempt to
> override. Personally, I like JDK 1.4 logger better, because it's hassle
> free, and I have yet to see it cause applications to fail. I still have
> a really annoying bug report open, which seems to be caused by log4j,
> and which would also indicate that log4j creates CL problems: bug 3888.
> You seem to insist that it's Tomcat's fault, though.
>
> So since the current situation works (I didn't hear about CL problems
> with 4.1.24 related to logging), I'm clearly in favor of keeping the
> status quo, and will veto any related proposals for 4.1.x.
What about 5.x ?
I would be +1 on including log4j with 5.x ( after porting the changes that
Bill did on 3.3 for hierarchical support ). The main benefit is that the
configuration is more flexible - and we can support app separation ( AFAIK
that isn't supported with JDK1.4 ).
I use c-l + log4j most of the time.
BTW - one reason for not having log4j in common/log is the config.
Apps expect their WEB-INF/classes/log4j.properties to be used, that
doesn't work if log4j is in common/log ( or will work for one app only ).
So without the app separation patches ( which Bill implemented in 3.3, but
are not in 4.1 or 5.0 ) - we can't do that.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by Remy Maucherat <re...@apache.org>.
Ceki Gülcü wrote:
> At 10:06 AM 4/24/2003 -0700, Costin Manolache wrote:
>
> What prevents you from putting log4j.jar in $TOMCAT_HOME/common/lib of
> Tomcat?
>
>> The problem is that having part of the implmentation in the same loader
>> with the API, and part in a child loader doesn't work.
>> For JDK1.4 - there are no problems.
>
>
>
> There is no problem with JDK 1.4 because it's in the system class
> loader. Placing log4j high in the hierarchy, in particular at or above
> the common loader would work. Hint: just place log4j.jar in
> $TOMCAT_HOME/common/lib/.
>
> As indicated above, I do not see why putting log4j +
> Log4J-common-logging together in one jar file, say log4j.jar, would be
> of any help. If commons-logging cannot access log4j.jar the problem
> remains, right? Consider the following scenario.
>
> Let us assume that the user set some property forcing the
> use of Log4jFactory by commons-logging and that loading log4j classes
> fails because inaccessibility to the class loader in question, then
> the same or similar failure will occur if Log4jFactory and log4j were
> in the same jar file because now both Log4jFactory and log4j would be
> inaccessible. Putting log4j+log4j-common-logging just displaces the
> point of failure but does not eliminate it. Wouldn't you agree?
>
> Is there a case where the default factory (LogFactoryImpl) is selected
> and where it erroneously decides to use log4j when log4j is not
> accessible?
The non delegating CL in Tomcat 4 is nothing but a source of problems,
which cannot be implemented to actually work. You need to have an
endless supply of particular workarounds for various libraries to avoid
class conflicts.
I think in the case of log4j + c-l, there are issues if you attempt to
override. Personally, I like JDK 1.4 logger better, because it's hassle
free, and I have yet to see it cause applications to fail. I still have
a really annoying bug report open, which seems to be caused by log4j,
and which would also indicate that log4j creates CL problems: bug 3888.
You seem to insist that it's Tomcat's fault, though.
So since the current situation works (I didn't hear about CL problems
with 4.1.24 related to logging), I'm clearly in favor of keeping the
status quo, and will veto any related proposals for 4.1.x.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by Costin Manolache <cm...@yahoo.com>.
Ceki Gülcü wrote:
>>What doesn't work is having log4j.jar in a child loader, and
>>log4j-commons-logging in a parent loader. That's because classes in
>>log4j-commons-logging are using log4j classes.
>
> That much is clear.
>
> Why would having commons-logging in a parent loader and
> log4j+log4j-commons-logging work? The answer is below.
This is the pattern used by most APIs - JDBC, JNDI, JAXP.
The interfaces and base classes can be in the parent loader, and
find the wrapper ( which implements classes from the base class and uses
a particular implementation ) using the thread loader or some other method.
The problem is that you can easily load one class ( Class.forName() ),
instantiate, cast to a class in the same loader.
But you have little control over how the classloader resolves the
class fields - in most cases the loader uses the "defining class loader"
to load the fields, interfaces, etc.
>>At that time we didn't even have the code to do app logging isolation.
>
> I have a lot to say on logging isolation problem but that's for a
> different thread.
My point is that placing log4j in common/lib without logging isolations
is not good.
If we have logging isolation - common/lib would be the right place for
log4j.
> I think I am (slowly) beginning to understand. While to load the
> appropriate log factory the code in o.a.c.l.LogFactory class uses the
> TCL, the code in o.a.c.l.impl.Log4jFactory class just uses "new" to
> load log4j loggers.
Not only that - the ClassLoader needs to resolve fields and other things,
and you can't control that. "new" would be easy to work around.
It is a very tricky business - even if we may be able to do it, you never
know when it'll break, that's how classloader works.
> Have you considered using the TCL to load log4j classes in
> Log4jFactory too?
See above. The code that resolve fields ( for example ) is outside of our
control.
And besides - there is a very simple and clean solution to this problem,
Just place Log4JFActory/Log4JLogger in the same loader with log4j and you
won't have any problems or workarounds.
>> > Why? (for the third time...)
>>
>>Because the adapter uses classes from log4j. If the adapter is in parent,
>>log4j in child - it won't work.
>>
>>Adapter and log4j must be in the same loader, or log4j in a parent - that
>>works.
>>
>>The API can be in a parent loader, and the logger+adapter in a child.
>
> This is just a repetition of the above, so I won't comment.
If you ask 3 times the same thing, you may get the same answer 3 times :-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:33 AM 4/24/2003 -0700, you wrote:
>Ceki Gülcü wrote:
>
> >>The "right" solution for commons-logging is to have a jar that has only
> >>the API, and have the implementation ( log4j + Log4J-common-logging ) in a
> >>separate package. It would be best if log4j jar would include the support
> >>for commons-logging - but since this doesn't happen, we need workarounds.
> >
> > Why do you think putting log4j + Log4J-common-logging in one jar file
> > would make any difference? It is far from obvious to me. See also below.
>
>What matters is having log4j and log4j-commons-logging loaded by the same
>loader. Or at least having log4j loaded by a parent class, and
>log4-commons-logging in a child ( that's why JDK1.4 logging works ).
>
>What doesn't work is having log4j.jar in a child loader, and
>log4j-commons-logging in a parent loader. That's because classes in
>log4j-commons-logging are using log4j classes.
That much is clear.
Why would having commons-logging in a parent loader and
log4j+log4j-commons-logging work? The answer is below.
> > What prevents you from putting log4j.jar in $TOMCAT_HOME/common/lib of
> > Tomcat?
>
>That would work too. The only concern is the fact that log4j would be then
>shared by all classes - and it may break the app isolation and allow apps to
>mess with the server logs.
>
>At that time we didn't even have the code to do app logging isolation.
I have a lot to say on logging isolation problem but that's for a different
thread.
[snip]
> > As indicated above, I do not see why putting log4j +
> > Log4J-common-logging together in one jar file, say log4j.jar, would be
> > of any help. If commons-logging cannot access log4j.jar the problem
> > remains, right? Consider the following scenario.
>
>The API will use the thread loader first to load the log4j adapter.
>The adapter implements commons-logging, so there is no problem
>making the calls and casts.
>
>
>
> > Let us assume that the user set some property forcing the
> > use of Log4jFactory by commons-logging and that loading log4j classes
> > fails because inaccessibility to the class loader in question, then
> > the same or similar failure will occur if Log4jFactory and log4j were
> > in the same jar file because now both Log4jFactory and log4j would be
> > inaccessible. Putting log4j+log4j-common-logging just displaces the
> > point of failure but does not eliminate it. Wouldn't you agree?
>
>No. Or at least I've seen no failure so far - as long as the adapter
>and log4j are in the same loader.
I think I am (slowly) beginning to understand. While to load the
appropriate log factory the code in o.a.c.l.LogFactory class uses the
TCL, the code in o.a.c.l.impl.Log4jFactory class just uses "new" to
load log4j loggers.
Have you considered using the TCL to load log4j classes in
Log4jFactory too?
> >>Log4j works with c-l in a hierarchical loader environment only if it is in
> >>the same loader with the c-l adapter.
> >
> > Why? (for the third time...)
>
>Because the adapter uses classes from log4j. If the adapter is in parent,
>log4j in child - it won't work.
>
>Adapter and log4j must be in the same loader, or log4j in a parent - that
>works.
>
>The API can be in a parent loader, and the logger+adapter in a child.
This is just a repetition of the above, so I won't comment.
>Costin
--
Ceki For log4j documentation consider "The complete log4j manual"
http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 12:26 PM 4/24/2003 -0700, Costin Manolache wrote:
>Craig R. McClanahan wrote:
> >
> > Won't this still work if the code in log4j-commons-logging uses the Thread
> > context class loader to load the Log4J classes? That will pick up the
> > Log4J classes from the webapp, if they are there.
>
>Tried that - doesn't work.
>
>The code in log4j-commons-logging uses log4j classes directly - there is
>a Category field, etc. We could use introspection instead of using the log4j
>API directly - but that would slow everything down.
Good point.
>Costin
--
Ceki For log4j documentation consider "The complete log4j manual"
http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 24 Apr 2003, Costin Manolache wrote:
> Date: Thu, 24 Apr 2003 12:26:04 -0700
> From: Costin Manolache <cm...@yahoo.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Why commons-logging-api.jar?
>
> Craig R. McClanahan wrote:
>
> >
> >
> > On Thu, 24 Apr 2003, Costin Manolache wrote:
> >
> >>
> >> What doesn't work is having log4j.jar in a child loader, and
> >> log4j-commons-logging in a parent loader. That's because classes in
> >> log4j-commons-logging are using log4j classes.
> >
> >
> > Won't this still work if the code in log4j-commons-logging uses the Thread
> > context class loader to load the Log4J classes? That will pick up the
> > Log4J classes from the webapp, if they are there.
>
> Tried that - doesn't work.
>
Even with the current c-l code (1.0.3)?
> The code in log4j-commons-logging uses log4j classes directly - there is
> a Category field, etc. We could use introspection instead of using the log4j
> API directly - but that would slow everything down.
>
>
>
> > I recently added a bunch of unit tests in commons-logging to explore the
> > various class loader scenarios, and it appears to me that the Log4J
> > adapter in commons-logging.jar should now work correctly in a multi class
> > loader environment, with Log4J in either the child class loader or the
> > same class loader.
>
> I'll try this.
>
> Have you run the tests with JDK1.3 too ? I never got it to work - when
> Log4JLogger is loaded, it is loaded from the parent loader, and it needs the
> fields - of type org.apache.log4j.Logger, which are not in the same loader.
>
Haven't tried it under 1.3 because it is not relevant to my needs, but
that is an important use case for Tomcat in general.
> At least at the time I tried this, the class loader that loads Log4jLogger
> couldn't figure out that it has to use the thread loader.
>
OK, I'm starting with an assumption that the "log4j-commons-logging" code
we are talking about is classes like
org.apache.commons.logging.impl.Log4JLogger, which has references to
classes in org.apache.log4j, right?
If so, it looks like the key issue is in the constructor, where we say:
public Log4JLogger(String name) {
this.logger = Logger.getLogger();
}
and the question is where does org.apache.log4j.Logger get loaded from.
I'll bet we can deal with that via specifically loading this ourselves,
and using reflection to call the static method -- I'll try experiments
later this afternoon.
This still depends on Log4J internally doing things in a fashion that is
sensitive to thread context class loaders (i.e. the o.a.l.Logger class has
to be careful where *it* loads other Log4J classes from), but that is not
something that c-l can do anything about.
> Costin
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by Costin Manolache <cm...@yahoo.com>.
Craig R. McClanahan wrote:
>
>
> On Thu, 24 Apr 2003, Costin Manolache wrote:
>
>>
>> What doesn't work is having log4j.jar in a child loader, and
>> log4j-commons-logging in a parent loader. That's because classes in
>> log4j-commons-logging are using log4j classes.
>
>
> Won't this still work if the code in log4j-commons-logging uses the Thread
> context class loader to load the Log4J classes? That will pick up the
> Log4J classes from the webapp, if they are there.
Tried that - doesn't work.
The code in log4j-commons-logging uses log4j classes directly - there is
a Category field, etc. We could use introspection instead of using the log4j
API directly - but that would slow everything down.
> I recently added a bunch of unit tests in commons-logging to explore the
> various class loader scenarios, and it appears to me that the Log4J
> adapter in commons-logging.jar should now work correctly in a multi class
> loader environment, with Log4J in either the child class loader or the
> same class loader.
I'll try this.
Have you run the tests with JDK1.3 too ? I never got it to work - when
Log4JLogger is loaded, it is loaded from the parent loader, and it needs the
fields - of type org.apache.log4j.Logger, which are not in the same loader.
At least at the time I tried this, the class loader that loads Log4jLogger
couldn't figure out that it has to use the thread loader.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 24 Apr 2003, Costin Manolache wrote:
>
> What doesn't work is having log4j.jar in a child loader, and
> log4j-commons-logging in a parent loader. That's because classes in
> log4j-commons-logging are using log4j classes.
Won't this still work if the code in log4j-commons-logging uses the Thread
context class loader to load the Log4J classes? That will pick up the
Log4J classes from the webapp, if they are there.
I recently added a bunch of unit tests in commons-logging to explore the
various class loader scenarios, and it appears to me that the Log4J
adapter in commons-logging.jar should now work correctly in a multi class
loader environment, with Log4J in either the child class loader or the
same class loader.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by Costin Manolache <cm...@yahoo.com>.
Ceki Gülcü wrote:
>>The "right" solution for commons-logging is to have a jar that has only
>>the API, and have the implementation ( log4j + Log4J-common-logging ) in a
>>separate package. It would be best if log4j jar would include the support
>>for commons-logging - but since this doesn't happen, we need workarounds.
>
> Why do you think putting log4j + Log4J-common-logging in one jar file
> would make any difference? It is far from obvious to me. See also below.
What matters is having log4j and log4j-commons-logging loaded by the same
loader. Or at least having log4j loaded by a parent class, and
log4-commons-logging in a child ( that's why JDK1.4 logging works ).
What doesn't work is having log4j.jar in a child loader, and
log4j-commons-logging in a parent loader. That's because classes in
log4j-commons-logging are using log4j classes.
> What prevents you from putting log4j.jar in $TOMCAT_HOME/common/lib of
> Tomcat?
That would work too. The only concern is the fact that log4j would be then
shared by all classes - and it may break the app isolation and allow apps to
mess with the server logs.
At that time we didn't even have the code to do app logging isolation.
> There is no problem with JDK 1.4 because it's in the system class
> loader. Placing log4j high in the hierarchy, in particular at or above
> the common loader would work. Hint: just place log4j.jar in
> $TOMCAT_HOME/common/lib/.
Yes.
> As indicated above, I do not see why putting log4j +
> Log4J-common-logging together in one jar file, say log4j.jar, would be
> of any help. If commons-logging cannot access log4j.jar the problem
> remains, right? Consider the following scenario.
The API will use the thread loader first to load the log4j adapter.
The adapter implements commons-logging, so there is no problem
making the calls and casts.
> Let us assume that the user set some property forcing the
> use of Log4jFactory by commons-logging and that loading log4j classes
> fails because inaccessibility to the class loader in question, then
> the same or similar failure will occur if Log4jFactory and log4j were
> in the same jar file because now both Log4jFactory and log4j would be
> inaccessible. Putting log4j+log4j-common-logging just displaces the
> point of failure but does not eliminate it. Wouldn't you agree?
No. Or at least I've seen no failure so far - as long as the adapter
and log4j are in the same loader.
>>Log4j works with c-l in a hierarchical loader environment only if it is in
>>the same loader with the c-l adapter.
>
> Why? (for the third time...)
Because the adapter uses classes from log4j. If the adapter is in parent,
log4j in child - it won't work.
Adapter and log4j must be in the same loader, or log4j in a parent - that
works.
The API can be in a parent loader, and the logger+adapter in a child.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 10:06 AM 4/24/2003 -0700, Costin Manolache wrote:
>The implementation of commons-logging for log4j creates a lot of problems if
>it is bundled with commons-logging, and log4j is in a different loader. Same
>thing would happen with any other API ( JDBC, JNDI, JAXP ) if you place the
> implementation ( which in our case consists of log4j + adapters ) in
>different loaders.
>
>The "right" solution for commons-logging is to have a jar that has only the
>API, and have the implementation ( log4j + Log4J-common-logging ) in a
>separate package. It would be best if log4j jar would include the support
>for commons-logging - but since this doesn't happen, we need workarounds.
Why do you think putting log4j + Log4J-common-logging in one jar file
would make any difference? It is far from obvious to me. See also below.
> >>commons-logging-api contains only the logging API and things that don't
> >>depend on external packages. If you want to use log4j - you must deploy
> >>log4j and the adapter for log4j ( which currently means
> >>commons-logging.jar, the full package, since there is no standalone
> >>adapter ).
> >
> > If I understand correctly, JDK 1.4 logging is considered as internal
> > as opposed to external. My goal is to understand your motivations and
> > technical reasoning in order to better answer user questions on
> > log4j-user@.
>
> >From a class loading perspective - JDK1.4 logging is allways in the parent
>loader.
What prevents you from putting log4j.jar in $TOMCAT_HOME/common/lib of Tomcat?
>The problem is that having part of the implmentation in the same loader
>with the API, and part in a child loader doesn't work.
>For JDK1.4 - there are no problems.
There is no problem with JDK 1.4 because it's in the system class
loader. Placing log4j high in the hierarchy, in particular at or above
the common loader would work. Hint: just place log4j.jar in
$TOMCAT_HOME/common/lib/.
As indicated above, I do not see why putting log4j +
Log4J-common-logging together in one jar file, say log4j.jar, would be
of any help. If commons-logging cannot access log4j.jar the problem
remains, right? Consider the following scenario.
Let us assume that the user set some property forcing the
use of Log4jFactory by commons-logging and that loading log4j classes
fails because inaccessibility to the class loader in question, then
the same or similar failure will occur if Log4jFactory and log4j were
in the same jar file because now both Log4jFactory and log4j would be
inaccessible. Putting log4j+log4j-common-logging just displaces the
point of failure but does not eliminate it. Wouldn't you agree?
Is there a case where the default factory (LogFactoryImpl) is selected
and where it erroneously decides to use log4j when log4j is not
accessible?
>Log4j works with c-l in a hierarchical loader environment only if it is in
>the same loader with the c-l adapter.
Why? (for the third time...)
>You can easily fix the problem by taking ownership of the c-l adapter for
>log4j and bundling it with log4j. The only way we can fix the problem is to
>force the users to place them in the same loader.
>
>Costin
--
Ceki For log4j documentation consider "The complete log4j manual"
http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by Costin Manolache <cm...@yahoo.com>.
Ceki Gülcü wrote:
> At 07:29 AM 4/24/2003 -0700, Costin Manolache wrote:
>>The reason is very simple - and you actually know it.
>
> If I knew the reason I would not be asking. What is the very simple
> reason?
>
>> > Especially in light of numerous problems with unfound factories,
>> > incompatible classes, unimplemented methods, ... all of which are
>> > class loader related.
>>
>>Most of those problems are traced to the fact that commons-logging is
>>forced to include adapters for log4j and logkit.
>
> What do you mean by commons-logging is forced to include adapters for
> log4j and logkit. What is the purpose of commons-logging if not to
> wrap logging APIs?
The purpose of commons-logging is to provide an API for logging ( that can
support multiple implementations, etc) .
Just like the purpose of SAX is to provide one API for parsing, and not to
wrap some parsers.
The implementation of commons-logging for log4j creates a lot of problems if
it is bundled with commons-logging, and log4j is in a different loader. Same
thing would happen with any other API ( JDBC, JNDI, JAXP ) if you place the
implementation ( which in our case consists of log4j + adapters ) in
different loaders.
The "right" solution for commons-logging is to have a jar that has only the
API, and have the implementation ( log4j + Log4J-common-logging ) in a
separate package. It would be best if log4j jar would include the support
for commons-logging - but since this doesn't happen, we need workarounds.
>>commons-logging-api contains only the logging API and things that don't
>>depend on external packages. If you want to use log4j - you must deploy
>>log4j and the adapter for log4j ( which currently means
>>commons-logging.jar, the full package, since there is no standalone
>>adapter ).
>
> If I understand correctly, JDK 1.4 logging is considered as internal
> as opposed to external. My goal is to understand your motivations and
> technical reasoning in order to better answer user questions on
> log4j-user@.
>From a class loading perspective - JDK1.4 logging is allways in the parent
loader.
The problem is that having part of the implmentation in the same loader
with the API, and part in a child loader doesn't work.
For JDK1.4 - there are no problems.
Log4j works with c-l in a hierarchical loader environment only if it is in
the same loader with the c-l adapter.
You can easily fix the problem by taking ownership of the c-l adapter for
log4j and bundling it with log4j. The only way we can fix the problem is to
force the users to place them in the same loader.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Why commons-logging-api.jar?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:29 AM 4/24/2003 -0700, Costin Manolache wrote:
>The reason is very simple - and you actually know it.
If I knew the reason I would not be asking. What is the very simple
reason?
> > Especially in light of numerous problems with unfound factories,
> > incompatible classes, unimplemented methods, ... all of which are
> > class loader related.
>
>Most of those problems are traced to the fact that commons-logging is
>forced to include adapters for log4j and logkit.
What do you mean by commons-logging is forced to include adapters for
log4j and logkit. What is the purpose of commons-logging if not to
wrap logging APIs?
>commons-logging-api contains only the logging API and things that don't
>depend on external packages. If you want to use log4j - you must deploy
>log4j and the adapter for log4j ( which currently means commons-logging.jar,
>the full package, since there is no standalone adapter ).
If I understand correctly, JDK 1.4 logging is considered as internal
as opposed to external. My goal is to understand your motivations and
technical reasoning in order to better answer user questions on
log4j-user@.
>Costin
>
> >
> > I am stumped.
> >
--
Ceki For log4j documentation consider "The complete log4j manual"
http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org