You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <sk...@apache.org> on 2005/05/07 15:06:10 UTC
[logging] a candidate explanation for "Log4JLogger does not
implement Log"
Hi All,
I've been working for quite a while now to try to figure out why users
of JCL have been getting the "Log4JLogger does not implement Log"
message.
I think I've finally really understood the cause. If this is really
obvious to everyone, please let me down gently :-)
The problem is not the *presence* of JCL in the parent or child
classloader paths. The problem is the presence of code that *calls*
LogFactory.getLog in classes in the parent classpath. When webapp code
calls into such a class with the context classloader set, that triggers
the problem.
The problem only ever occurs when child-first classloading is selected
(ironic, considering my recent arguments in favour of this feature).
1.
A class in the webapp has a symbolic reference to a method on a class
that is present only in the parent classpath. That class is therefore
located by the parent classloader. Java's resolution mechanism then
requires that the classes referenced by it (LogFactory, LogFactoryImpl,
Log) are loaded via the same classloader.
2.
The webapp code then actually calls the above method. Context
classloader is set to the webapp classloader. Control flows through the
called method to LogFactory, to LogFactoryImpl. LogFactoryImpl then
dynamically loads Log4JLogger from the context classpath, ending up
with an implementation from the child classloader.
However Log4JLogger has a symbolic reference to the Log class (because
it implements it). And the java rules specify that such references are
resolved via the classloader that loaded the referencing classes. So the
Log class that Log4JLogger references is loaded via the child
classloader.
3.
The LogFactoryImpl class then tries to cast Log4JLogger to its version
of Log and fails, because the Log class was loaded via different
classloaders.
===
A minor variant is where the object in the parent classloader that calls
LogFactory.getLog is created by the container and passed as a parameter
to the webapp (eg an implementation of ServletContext). The basic
behaviour is the same, though.
===
Ok, so what is the solution?
(1)
Well, ensuring that the logging adapters are deployed via the parent
classloader *only* is one. That fixes the problem, as Log4JLogger et.
al. always bind to the same Log interface that LogFactory binds to.
The downside is:
* It means that the logging library must also be deployed via the
parent classloader, even when there *are* no other classes in the
parent classloader that trigger this problem (ie ones that use JCL
and that the webapp is going to call into).
Having the logging library loaded via the parent classloader means
that dumb logging libraries may not be able to find their config
files.
Some logging libs may be smart enough to look for their
resource files via the context classloader. And in some cases the
logging *adapter* class might be able to tell the logging lib
where the config file is. Assuming we can rely on (or trick) the
logging lib to correctly handle per-context-classloader location
of their config files, all should be well.
(2)
I think we could simply change the distribution bundles. The root
problem appears to be to me that the adapters (Log4JLogger et al) are
bundled with a Log implementation. If we produced a jar that included
Log4JLogger et al. but *without* the Log class, the problem should be
solved. The rule would then be:
* if the parent loader has commons-logging.jar or
commons-logging-api.jar, then deploy
commons-logging-adapters.jar in the child, together with the
actual logging library.
* otherwise, deploy commons-logging.jar in the child
(or commons-logging-api.jar + commons-logging-adapters.jar)
(3)
Maybe we should just do away with LogFactoryImpl's attemp to load a log
adapter via the context classloader. It does enable the setup of having
commons-logging-api.jar in the parent and commons-logging.jar in the
child, but it fails badly if any other class in the parent classloader
uses JCL and is called by the webapp. Is this benefit worth the pain?
However doing away with the context.loadClass("Log") essentially leaves
us with the same issues as (1) when commons-logging.jar is deployed in
the parent. When deployed in the child, it would work as expected
though.
===
Notes:
*
Having LogFactory in both the parent and child classloaders is
problematic anyway. They can potentially bind to different log adapters
which then bind to different log libraries, resulting in logging going
to different destinations for classes in the parent vs the child
classloaders.
*
classes in the parent classloader that use JCL are borked anyway if
they ever use static fields to cache the result of LogFactory.getLog,
as that will bind to the logging setup of the first webapp to call them.
BTW, Brian proposed a splitting-up of the JCL jars a few months ago, as
experiments showed it resolved some issues. I can't find the emails just
now. Is it related to the solution (2) proposed above?
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] a candidate explanation for "Log4JLogger does not implement Log"
Posted by Brian Stansberry <be...@yahoo.com>.
--- Simon Kitching <sk...@apache.org> wrote:
> On Sun, 2005-05-08 at 01:06 +1200, Simon Kitching
> wrote:
> > Ok, so what is the solution?
> >
>
> > (2)
> > I think we could simply change the distribution
> bundles. The root
> > problem appears to be to me that the adapters
> (Log4JLogger et al) are
> > bundled with a Log implementation. If we produced
> a jar that included
> > Log4JLogger et al. but *without* the Log class,
> the problem should be
> > solved. The rule would then be:
> > * if the parent loader has commons-logging.jar
> or
> > commons-logging-api.jar, then deploy
> > commons-logging-adapters.jar in the child,
> together with the
> > actual logging library.
> > * otherwise, deploy commons-logging.jar in the
> child
> > (or commons-logging-api.jar +
> commons-logging-adapters.jar)
>
> Hmm..this approach might aggravate the "memory leak
> on webapp reload"
> issue.
>
> To recap, the LogFactoryImpl holds a map of
> (logger-name, log). If those
> log objects belong to a class loaded from the child
> classloader then
> they hold references to the child classloader. This
> prevents the
> LogFactory's (weak-ref-to-classloader,
> strong-ref-to-logFactoryImpl) map
> from freeing stuff related to a classloader, as
> there is a strong ref to
> the context-classloader via
>
LogFactory->LogFactoryImpl->Logger-class->classloader.
>
> Recommending that commons-logging-api.jar be in the
> parent, but
> commons-logging-adapters seems to be exactly the
> scenario to trigger the
> unfixable-via-weakrefs leak :-(.
>
> I haven't proved this, and it's complicated enough
> that I might be wrong
> here. But I thought I should mention it now.
>
Nope, sadly I'm quite sure you're right.
Bug 31286
(http://issues.apache.org/bugzilla/show_bug.cgi?id=31286)
has a unit test patch that simulates a "parent has
api, child has adapters" classloading scenario. It
fails with a memory leak.
Haven't had a chance to digest your recent postings,
so apologize for not giving more feedback.
Brian
>
> Cheers,
>
> Simon
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] a candidate explanation for "Log4JLogger does not
implement Log"
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2005-05-08 at 01:06 +1200, Simon Kitching wrote:
> Ok, so what is the solution?
>
> (2)
> I think we could simply change the distribution bundles. The root
> problem appears to be to me that the adapters (Log4JLogger et al) are
> bundled with a Log implementation. If we produced a jar that included
> Log4JLogger et al. but *without* the Log class, the problem should be
> solved. The rule would then be:
> * if the parent loader has commons-logging.jar or
> commons-logging-api.jar, then deploy
> commons-logging-adapters.jar in the child, together with the
> actual logging library.
> * otherwise, deploy commons-logging.jar in the child
> (or commons-logging-api.jar + commons-logging-adapters.jar)
Hmm..this approach might aggravate the "memory leak on webapp reload"
issue.
To recap, the LogFactoryImpl holds a map of (logger-name, log). If those
log objects belong to a class loaded from the child classloader then
they hold references to the child classloader. This prevents the
LogFactory's (weak-ref-to-classloader, strong-ref-to-logFactoryImpl) map
from freeing stuff related to a classloader, as there is a strong ref to
the context-classloader via
LogFactory->LogFactoryImpl->Logger-class->classloader.
Recommending that commons-logging-api.jar be in the parent, but
commons-logging-adapters seems to be exactly the scenario to trigger the
unfixable-via-weakrefs leak :-(.
I haven't proved this, and it's complicated enough that I might be wrong
here. But I thought I should mention it now.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Improvements to LogFactoryImpl
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2005-05-22 at 15:59 -0700, Brian Stansberry wrote:
> >
> >i believe (as indicated in the analysis document)
> that the correct
> >behaviour in these cases is for JCL to recognise that
> log4j is not
> >viable (for this configuration) and default to
> java.util logging. this
> >is a little unsatisfactory but i don't see a
> reasonable technical
> >solution for these configuration.
> >
>
> One unsatisfactory aspect is that instead of throwing
> an exception with a nice message and stack trace,
> logging would mysteriously be done using an unexpected
> logging library. But Simon's recent work on adding
> diagnostics should help mitigate this drawback.
I presume you're continuing the discussion:
http://issues.apache.org/bugzilla/show_bug.cgi?id=34661
The bit about trying to instantiate a logger object in order to test
whether that library is *really* available has my +1.
The bit about ignoring the situation where we can't cast the resulting
object to Log (and continuing with discovery) is something I've been
trying to make up my mind on.
When the user *has* put an implementation of the Log interface into the
child classloader, so that this problem occurs, we can:
a) report an error, or
b) use a logging lib that the parent can access
When the user doesn't actually have any interest in log output, (b) is
obviously superior. It's a shame that at the moment we prevent apps from
running even when no logging would ever be generated. Falling back to
another implementation (even SimpleLog or NoOpLog) is fine when no
output is generated or the user doesn't want the output!
And sometimes the user is happy with (b) anyway, ie they feel it's ok
that logging from code in the child goes to one destination while
logging from code in the parent (even when directly invoked by the
child) goes elsewhere.
But sometimes users will *really* expect all their logging to go to one
place regardless of whether the code is deployed in the child or parent.
And in this situation, silently "splitting" the output will really
confuse them.
In the past, I've had a slight lean towards (a), ie the current
solution. If the system *might* do unexpected things it seems safer to
report the error than not.
But now diagnostics are available, I could be persuaded towards
implementing the proposed patch. The situation where the app terminates
in the middle because child code called parent code that uses logging is
nasty. And with diagnostics, a user who wonders "why didn't my logging
output go where I expected it?" can find out.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] throwing exceptions on log configuration [was a
candidate explanation...]
Posted by Simon Kitching <sk...@apache.org>.
On Mon, 2005-05-23 at 20:58 +0100, robert burrell donkin wrote:
> On Sun, 2005-05-22 at 15:59 -0700, Brian Stansberry wrote:
> > One unsatisfactory aspect is that instead of throwing
> > an exception with a nice message and stack trace,
> > logging would mysteriously be done using an unexpected
> > logging library. But Simon's recent work on adding
> > diagnostics should help mitigate this drawback.
>
> i think that this comes down to a question of philosophy.
>
> the consequences of throwing an exception are usually pretty fatal for
> an application. personally, i think that we'd be doing most users (who
> just want to run their application) a favour by ensuring that discovery
> throws as few exceptions as possible. i hope that diagnostics and a good
> troubleshooting document would prove a good enough substitute for those
> who want to choose a particular logging system.
>
> then again, this opinion has traditionally been in the minority so i'd
> be happy to go with the consensus on this issue...
Given the availability of diagnostics, I would now be in favour of not
throwing exceptions, ie following log4j's "failsafe" approach as far as
possible. It's a difficult call, as different people will want different
things, but the logging output *will* go somewhere; on config error, it
just goes to a "higher level" logger than expected, eg the tomcat log
instead of the webapp log. That should be noticed fairly quickly if it
happens.
But I would like to see a separate patch for fallback-on-failure than
for the test-availability-by-instantiating-logger stuff.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] a candidate explanation for "Log4JLogger does not
implement Log"
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-05-22 at 15:59 -0700, Brian Stansberry wrote:
> --- robert burrell donkin
> <ro...@blueyonder.co.uk> wrote:
>
> > On Sun, 2005-05-08 at 01:06 +1200, Simon Kitching
> > wrote:
> > > Hi All,
> > >
> > > I've been working for quite a while now to try to
> > figure out why users
> > > of JCL have been getting the "Log4JLogger does not
> > implement Log"
> > > message.
> > >
> > > I think I've finally really understood the cause.
> > If this is really
> > > obvious to everyone, please let me down gently :-)
> >
> > one thing which i have learnt from working with JCL
> > over the years is
> > that nothing is ever obvious :)
> >
> > more than anything we need clear explanations of
> > what happens and why.
> >
>
> +1.
>
> I understood (and had since forgotten) from working
> with Ceki Gulcu's JCL analysis that the problems
> happened when code loaded a parent loaded tried to log
> with the TCCL in effect, but your discussion of why
> such a call would be made -- outside a test fixture :)
> -- makes the real world issue much clearer (and easier
> to remember).
>
> <snip>
> >> Ok, so what is the solution?
> >
> >
> >i would like to split this question into two.
> >
> >
> >i believe (as indicated in the analysis document)
> that the correct
> >behaviour in these cases is for JCL to recognise that
> log4j is not
> >viable (for this configuration) and default to
> java.util logging. this
> >is a little unsatisfactory but i don't see a
> reasonable technical
> >solution for these configuration.
> >
>
> One unsatisfactory aspect is that instead of throwing
> an exception with a nice message and stack trace,
> logging would mysteriously be done using an unexpected
> logging library. But Simon's recent work on adding
> diagnostics should help mitigate this drawback.
i think that this comes down to a question of philosophy.
the consequences of throwing an exception are usually pretty fatal for
an application. personally, i think that we'd be doing most users (who
just want to run their application) a favour by ensuring that discovery
throws as few exceptions as possible. i hope that diagnostics and a good
troubleshooting document would prove a good enough substitute for those
who want to choose a particular logging system.
then again, this opinion has traditionally been in the minority so i'd
be happy to go with the consensus on this issue...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] a candidate explanation for "Log4JLogger does not implement Log"
Posted by Brian Stansberry <be...@yahoo.com>.
--- robert burrell donkin
<ro...@blueyonder.co.uk> wrote:
> On Sun, 2005-05-08 at 01:06 +1200, Simon Kitching
> wrote:
> > Hi All,
> >
> > I've been working for quite a while now to try to
> figure out why users
> > of JCL have been getting the "Log4JLogger does not
> implement Log"
> > message.
> >
> > I think I've finally really understood the cause.
> If this is really
> > obvious to everyone, please let me down gently :-)
>
> one thing which i have learnt from working with JCL
> over the years is
> that nothing is ever obvious :)
>
> more than anything we need clear explanations of
> what happens and why.
>
+1.
I understood (and had since forgotten) from working
with Ceki Gulcu's JCL analysis that the problems
happened when code loaded a parent loaded tried to log
with the TCCL in effect, but your discussion of why
such a call would be made -- outside a test fixture :)
-- makes the real world issue much clearer (and easier
to remember).
<snip>
>> Ok, so what is the solution?
>
>
>i would like to split this question into two.
>
>
>i believe (as indicated in the analysis document)
that the correct
>behaviour in these cases is for JCL to recognise that
log4j is not
>viable (for this configuration) and default to
java.util logging. this
>is a little unsatisfactory but i don't see a
reasonable technical
>solution for these configuration.
>
One unsatisfactory aspect is that instead of throwing
an exception with a nice message and stack trace,
logging would mysteriously be done using an unexpected
logging library. But Simon's recent work on adding
diagnostics should help mitigate this drawback.
>
>the other question (which i think is what simon
addresses below) is how
>can JCL provide a solution for a user who needs a
similar configuration
>but who is willing to choose to deploy JCL slightly
differently.
>
>
>> (1)
>> Well, ensuring that the logging adapters are
deployed via the parent
>> classloader *only* is one. That fixes the problem,
as Log4JLogger et.
>> al. always bind to the same Log interface that
LogFactory binds to.
>>
>> The downside is:
>> * It means that the logging library must also be
deployed via the
>> parent classloader, even when there *are* no
other classes in the
>> parent classloader that trigger this problem (ie
ones that use JCL
>> and that the webapp is going to call into).
>>
>> Having the logging library loaded via the parent
classloader means
>> that dumb logging libraries may not be able to
find their config
>> files.
>>
>> Some logging libs may be smart enough to look
for their
>> resource files via the context classloader. And
in some cases the
>> logging *adapter* class might be able to tell
the logging lib
>> where the config file is. Assuming we can rely
on (or trick) the
>> logging lib to correctly handle
per-context-classloader location
>> of their config files, all should be well.
>
>
>-1
>
>seems like giving away too much for a corner case
>
>
>> (2)
> I think we could simply change the distribution
bundles. The root
>> problem appears to be to me that the adapters
(Log4JLogger et al) are
>> bundled with a Log implementation. If we produced a
jar that included
>> Log4JLogger et al. but *without* the Log class, the
problem should be
>> solved. The rule would then be:
>> * if the parent loader has commons-logging.jar or
>> commons-logging-api.jar, then deploy
>> commons-logging-adapters.jar in the child,
together with the
>> actual logging library.
>> * otherwise, deploy commons-logging.jar in the
child
>> (or commons-logging-api.jar +
commons-logging-adapters.jar)
>
>
>this approach to these kinds of configuration is the
one i was thinking
>of earlier when i suggested that we might need an
implementations only
>distribution. a reasonable user could then adjust the
deployment so that
>the implementations were in the child and the api in
the parent.
>
>
>> (3)
>> Maybe we should just do away with LogFactoryImpl's
attemp to load a log
>> adapter via the context classloader. It does enable
the setup of having
>> commons-logging-api.jar in the parent and
commons-logging.jar in the
>> child, but it fails badly if any other class in the
parent classloader
>> uses JCL and is called by the webapp. Is this
benefit worth the pain?
>
>
>no
>
>
>but there is a variation (that i have discussed with
richard
>previously). the particular problem situation can be
diagnosed (a log
>class loaded from the context should have an
incompatible classloader).
>when the implementation is not viable, rather than
throw an exception
>JCL could try to load the class with the same name
from it's
>classloader.
>
>
>i think that brian's patch does something which
though implemented
>differently has the same net result.
>
>
>however, i don't think that either of these
approaches would actually
>work in this case: log4j is not visible to the parent
classloader. i do
>think that something along these lines will be needed
for the exotic
>classloader configurations (which haven't been
analysed yet).
>
>
>> BTW, Brian proposed a splitting-up of the JCL jars
a few months ago, as
>> experiments showed it resolved some issues. I can't
find the emails just
>> now. Is it related to the solution (2) proposed
above?
>
>
>i think so. maybe brian could repost his link.
>
http://xnet.wanconcepts.com/jcl/furtherAnalysis.html
Yes, definitely related. Sorry, Simon. When I read
your original post I missed this question, or would
have replied long ago.
- Brian
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] a candidate explanation for "Log4JLogger does not
implement Log"
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-05-08 at 01:06 +1200, Simon Kitching wrote:
> Hi All,
>
> I've been working for quite a while now to try to figure out why users
> of JCL have been getting the "Log4JLogger does not implement Log"
> message.
>
> I think I've finally really understood the cause. If this is really
> obvious to everyone, please let me down gently :-)
one thing which i have learnt from working with JCL over the years is
that nothing is ever obvious :)
more than anything we need clear explanations of what happens and why.
> The problem is not the *presence* of JCL in the parent or child
> classloader paths. The problem is the presence of code that *calls*
> LogFactory.getLog in classes in the parent classpath. When webapp code
> calls into such a class with the context classloader set, that triggers
> the problem.
+1
now that the demonstration code has been fixed, it is clear that (for
conventional classloader setups anyway) there's only one substantive
case that is missing. that's a lot better than things appeared a while
ago.
> The problem only ever occurs when child-first classloading is selected
> (ironic, considering my recent arguments in favour of this feature).
>
> 1.
>
> A class in the webapp has a symbolic reference to a method on a class
> that is present only in the parent classpath. That class is therefore
> located by the parent classloader. Java's resolution mechanism then
> requires that the classes referenced by it (LogFactory, LogFactoryImpl,
> Log) are loaded via the same classloader.
+1
> 2.
>
> The webapp code then actually calls the above method. Context
> classloader is set to the webapp classloader. Control flows through the
> called method to LogFactory, to LogFactoryImpl. LogFactoryImpl then
> dynamically loads Log4JLogger from the context classpath, ending up
> with an implementation from the child classloader.
>
> However Log4JLogger has a symbolic reference to the Log class (because
> it implements it). And the java rules specify that such references are
> resolved via the classloader that loaded the referencing classes. So the
> Log class that Log4JLogger references is loaded via the child
> classloader.
+1
> 3.
>
> The LogFactoryImpl class then tries to cast Log4JLogger to its version
> of Log and fails, because the Log class was loaded via different
> classloaders.
+1
there is actually no reason why the cast actually needs to be performed
to diagnose this condition: all that's required is to check the
classloader used to load the implementation class.
> ===
> A minor variant is where the object in the parent classloader that calls
> LogFactory.getLog is created by the container and passed as a parameter
> to the webapp (eg an implementation of ServletContext). The basic
> behaviour is the same, though.
> ===
>
> Ok, so what is the solution?
i would like to split this question into two.
i believe (as indicated in the analysis document) that the correct
behaviour in these cases is for JCL to recognise that log4j is not
viable (for this configuration) and default to java.util logging. this
is a little unsatisfactory but i don't see a reasonable technical
solution for these configuration.
the other question (which i think is what simon addresses below) is how
can JCL provide a solution for a user who needs a similar configuration
but who is willing to choose to deploy JCL slightly differently.
> (1)
> Well, ensuring that the logging adapters are deployed via the parent
> classloader *only* is one. That fixes the problem, as Log4JLogger et.
> al. always bind to the same Log interface that LogFactory binds to.
>
> The downside is:
> * It means that the logging library must also be deployed via the
> parent classloader, even when there *are* no other classes in the
> parent classloader that trigger this problem (ie ones that use JCL
> and that the webapp is going to call into).
>
> Having the logging library loaded via the parent classloader means
> that dumb logging libraries may not be able to find their config
> files.
>
> Some logging libs may be smart enough to look for their
> resource files via the context classloader. And in some cases the
> logging *adapter* class might be able to tell the logging lib
> where the config file is. Assuming we can rely on (or trick) the
> logging lib to correctly handle per-context-classloader location
> of their config files, all should be well.
-1
seems like giving away too much for a corner case
> (2)
> I think we could simply change the distribution bundles. The root
> problem appears to be to me that the adapters (Log4JLogger et al) are
> bundled with a Log implementation. If we produced a jar that included
> Log4JLogger et al. but *without* the Log class, the problem should be
> solved. The rule would then be:
> * if the parent loader has commons-logging.jar or
> commons-logging-api.jar, then deploy
> commons-logging-adapters.jar in the child, together with the
> actual logging library.
> * otherwise, deploy commons-logging.jar in the child
> (or commons-logging-api.jar + commons-logging-adapters.jar)
this approach to these kinds of configuration is the one i was thinking
of earlier when i suggested that we might need an implementations only
distribution. a reasonable user could then adjust the deployment so that
the implementations were in the child and the api in the parent.
> (3)
> Maybe we should just do away with LogFactoryImpl's attemp to load a log
> adapter via the context classloader. It does enable the setup of having
> commons-logging-api.jar in the parent and commons-logging.jar in the
> child, but it fails badly if any other class in the parent classloader
> uses JCL and is called by the webapp. Is this benefit worth the pain?
no
but there is a variation (that i have discussed with richard
previously). the particular problem situation can be diagnosed (a log
class loaded from the context should have an incompatible classloader).
when the implementation is not viable, rather than throw an exception
JCL could try to load the class with the same name from it's
classloader.
i think that brian's patch does something which though implemented
differently has the same net result.
however, i don't think that either of these approaches would actually
work in this case: log4j is not visible to the parent classloader. i do
think that something along these lines will be needed for the exotic
classloader configurations (which haven't been analysed yet).
> BTW, Brian proposed a splitting-up of the JCL jars a few months ago, as
> experiments showed it resolved some issues. I can't find the emails just
> now. Is it related to the solution (2) proposed above?
i think so. maybe brian could repost his link.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org