You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by co...@covalent.net on 2002/06/06 20:08:10 UTC
Logging: more classloader problems.
The problem: it won't work if commons-logging.jar is installed in the
parent class loader, and log4j.jar ( or another logger ) is installed in
a child loader ( like WEB-INF/lib ).
What happens:
- the factory uses the thread class loader to check if the log4j (
or any other impl. ) exists ( and it does ).
- it creates an instance of the Logger adapter. This will be created
using parent loader ( the one that loads commons-logging ).
- the Logger instance makes references to Category or other classes
that are used in it's implementation. End of story, since the
class loader can't find the reference.
This works fine for JAXP because the adapter for a parser is part of the
parser jar. It doesn't work for c-l because the adapter is in the
root loader ( with the API), not with the logging impl.
That doesn't affect people who just use a single logger or can put
the logger impl. in the same place with common-logging. It only
affect containers like tomcat, when you want to let each webapp
use it's own logger impl. of choice.
I tried all kind of introspection games, it won't work. The only solution
I see is to make sure the adapters are in the same place with the logger.
Solution:
Split commons-logging.jar in commons-logging-api.jar ( only the API and
the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar.
Alternatively, leave commons-logging.jar as it is and create a second
commons-logging-api.jar.
The -api will be included in the common loader. Each webapp will have to
include commons-logging.jar ( or -impl ), and it's own logger.
Or course, the best would be to have the adapter included in the
logger impl.
What do you think ? Craig, Remy can we make another c-l dot release with
this change ? ( I'll do some more testing to see how it works )
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging: more classloader problems.
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 6/6/02 3:47 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
> On Thu, 6 Jun 2002, Geir Magnusson Jr. wrote:
>
>>> Actually the default logger ( used if no 'real' logger is found )
>>> and the JDK1.4 adapter will have to remain in the main jar ( unless
>>> we want to support an alternate impl. for JDK1.4 logging - is it
>>> even possible ? )
>>
>> Why would it have to remain?
>>
>> (I'll stop the xposting after this one and keep it on commons...)
>
> The 'simple' logger ? Because it's very possible ( even likley ) to
> not find any other logger, and it's important to get at least something
> on stderr to know that things don't work. It would be very bad to have
> major errors but see nothing because a logger was not found. Plus for
> simple apps you don't need a real logger.
Sorry - was thinking about the jdk1.4. Agreed with the default stdout
logger...
>
> For JDK1.4 ? I don't know, it seems it doesn't work otherwise,
> probably I'm doing something wrong.
>
> Costin
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging: more classloader problems.
Posted by co...@covalent.net.
On Thu, 6 Jun 2002, Geir Magnusson Jr. wrote:
> I wanted to split out the factory impl from the api jar for other reasons,
> feeling that the clean break between API and impl was good, but wondered
> about the classloader implications.
>
> Of course, I didn¹t realize it would break tomcat. I would have said
> something specific if I had.
It doesn't actually break tomcat, only if commons-logging is installed in
the common logger ( and then it'll just not allow loggers in WEB-INF,
tomcat will continue to work ).
> > Actually the default logger ( used if no 'real' logger is found )
> > and the JDK1.4 adapter will have to remain in the main jar ( unless
> > we want to support an alternate impl. for JDK1.4 logging - is it
> > even possible ? )
>
> Why would it have to remain?
>
> (I'll stop the xposting after this one and keep it on commons...)
The 'simple' logger ? Because it's very possible ( even likley ) to
not find any other logger, and it's important to get at least something
on stderr to know that things don't work. It would be very bad to have
major errors but see nothing because a logger was not found. Plus for
simple apps you don't need a real logger.
For JDK1.4 ? I don't know, it seems it doesn't work otherwise,
probably I'm doing something wrong.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging: more classloader problems.
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 6/6/02 3:18 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
> On Thu, 6 Jun 2002, Geir Magnusson Jr. wrote:
>
>> On 6/6/02 2:08 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
>>
>>>
>>> Solution:
>>> Split commons-logging.jar in commons-logging-api.jar ( only the API and
>>> the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar.
>>
>> :)
>
> If you knew that keeping the adapter in the same jar will brake
> tomcat, why didn't you say so ??? :-) I remember all kind of crazy
> arguments - but never saw this one.
I wanted to split out the factory impl from the api jar for other reasons,
feeling that the clean break between API and impl was good, but wondered
about the classloader implications.
Of course, I didn¹t realize it would break tomcat. I would have said
something specific if I had.
The ":)" is just because the idea makes me happy.
> Actually the default logger ( used if no 'real' logger is found )
> and the JDK1.4 adapter will have to remain in the main jar ( unless
> we want to support an alternate impl. for JDK1.4 logging - is it
> even possible ? )
Why would it have to remain?
(I'll stop the xposting after this one and keep it on commons...)
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging: more classloader problems.
Posted by co...@covalent.net.
On Thu, 6 Jun 2002, Geir Magnusson Jr. wrote:
> On 6/6/02 2:08 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
>
> >
> > Solution:
> > Split commons-logging.jar in commons-logging-api.jar ( only the API and
> > the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar.
>
> :)
If you knew that keeping the adapter in the same jar will brake
tomcat, why didn't you say so ??? :-) I remember all kind of crazy
arguments - but never saw this one.
Actually the default logger ( used if no 'real' logger is found )
and the JDK1.4 adapter will have to remain in the main jar ( unless
we want to support an alternate impl. for JDK1.4 logging - is it
even possible ? )
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging: more classloader problems.
Posted by co...@covalent.net.
On Thu, 6 Jun 2002, Geir Magnusson Jr. wrote:
> On 6/6/02 2:08 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
>
> >
> > Solution:
> > Split commons-logging.jar in commons-logging-api.jar ( only the API and
> > the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar.
>
> :)
If you knew that keeping the adapter in the same jar will brake
tomcat, why didn't you say so ??? :-) I remember all kind of crazy
arguments - but never saw this one.
Actually the default logger ( used if no 'real' logger is found )
and the JDK1.4 adapter will have to remain in the main jar ( unless
we want to support an alternate impl. for JDK1.4 logging - is it
even possible ? )
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging: more classloader problems.
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 6/6/02 2:08 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
>
> Solution:
> Split commons-logging.jar in commons-logging-api.jar ( only the API and
> the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar.
:)
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging: more classloader problems.
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 6 Jun 2002 costinm@covalent.net wrote:
> Date: Thu, 6 Jun 2002 11:08:10 -0700 (PDT)
> From: costinm@covalent.net
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Cc: List Tomcat-Dev <to...@jakarta.apache.org>
> Subject: Logging: more classloader problems.
>
>
> The problem: it won't work if commons-logging.jar is installed in the
> parent class loader, and log4j.jar ( or another logger ) is installed in
> a child loader ( like WEB-INF/lib ).
>
> What happens:
> - the factory uses the thread class loader to check if the log4j (
> or any other impl. ) exists ( and it does ).
>
> - it creates an instance of the Logger adapter. This will be created
> using parent loader ( the one that loads commons-logging ).
>
> - the Logger instance makes references to Category or other classes
> that are used in it's implementation. End of story, since the
> class loader can't find the reference.
>
> This works fine for JAXP because the adapter for a parser is part of the
> parser jar. It doesn't work for c-l because the adapter is in the
> root loader ( with the API), not with the logging impl.
>
> That doesn't affect people who just use a single logger or can put
> the logger impl. in the same place with common-logging. It only
> affect containers like tomcat, when you want to let each webapp
> use it's own logger impl. of choice.
>
> I tried all kind of introspection games, it won't work. The only solution
> I see is to make sure the adapters are in the same place with the logger.
>
> Solution:
> Split commons-logging.jar in commons-logging-api.jar ( only the API and
> the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar.
>
> Alternatively, leave commons-logging.jar as it is and create a second
> commons-logging-api.jar.
>
> The -api will be included in the common loader. Each webapp will have to
> include commons-logging.jar ( or -impl ), and it's own logger.
>
> Or course, the best would be to have the adapter included in the
> logger impl.
>
> What do you think ? Craig, Remy can we make another c-l dot release with
> this change ? ( I'll do some more testing to see how it works )
>
+1 for leaving commons-logging.jar with the same contents and adding
commons-logging-api.jar with just the API classes. That way, we won't
disrupt anyone who is successfully using the existing approach.
+1 for a dot release with both, once you're satisfied that it works for
the problem case described.
> Costin
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging: more classloader problems.
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 6 Jun 2002 costinm@covalent.net wrote:
> Date: Thu, 6 Jun 2002 11:08:10 -0700 (PDT)
> From: costinm@covalent.net
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Cc: List Tomcat-Dev <to...@jakarta.apache.org>
> Subject: Logging: more classloader problems.
>
>
> The problem: it won't work if commons-logging.jar is installed in the
> parent class loader, and log4j.jar ( or another logger ) is installed in
> a child loader ( like WEB-INF/lib ).
>
> What happens:
> - the factory uses the thread class loader to check if the log4j (
> or any other impl. ) exists ( and it does ).
>
> - it creates an instance of the Logger adapter. This will be created
> using parent loader ( the one that loads commons-logging ).
>
> - the Logger instance makes references to Category or other classes
> that are used in it's implementation. End of story, since the
> class loader can't find the reference.
>
> This works fine for JAXP because the adapter for a parser is part of the
> parser jar. It doesn't work for c-l because the adapter is in the
> root loader ( with the API), not with the logging impl.
>
> That doesn't affect people who just use a single logger or can put
> the logger impl. in the same place with common-logging. It only
> affect containers like tomcat, when you want to let each webapp
> use it's own logger impl. of choice.
>
> I tried all kind of introspection games, it won't work. The only solution
> I see is to make sure the adapters are in the same place with the logger.
>
> Solution:
> Split commons-logging.jar in commons-logging-api.jar ( only the API and
> the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar.
>
> Alternatively, leave commons-logging.jar as it is and create a second
> commons-logging-api.jar.
>
> The -api will be included in the common loader. Each webapp will have to
> include commons-logging.jar ( or -impl ), and it's own logger.
>
> Or course, the best would be to have the adapter included in the
> logger impl.
>
> What do you think ? Craig, Remy can we make another c-l dot release with
> this change ? ( I'll do some more testing to see how it works )
>
+1 for leaving commons-logging.jar with the same contents and adding
commons-logging-api.jar with just the API classes. That way, we won't
disrupt anyone who is successfully using the existing approach.
+1 for a dot release with both, once you're satisfied that it works for
the problem case described.
> Costin
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>