Dennis Lundberg wrote:
Hi
Diagnostics, that was introduced in Commons Logging 1.1, is a great way
to troubleshoot classloading issues:
http://jakarta.apache.org/commons/logging/troubleshooting.html#Using_JCL_Diagnostics
I'm not really in doubt what's going on, so I don't think
Hello,
I'm having trouble with commons-logging in a scenario where I am
embedding tomcat's jasper in another servlet container.
I keep getting the exception about commons-logging being available from
multiple classloaders.
This seeems to be caused by LogFactory using the ContextClassLoader
Hi
Diagnostics, that was introduced in Commons Logging 1.1, is a great way
to troubleshoot classloading issues:
http://jakarta.apache.org/commons/logging/troubleshooting.html#Using_JCL_Diagnostics
Dennis Thrysøe wrote:
Hello,
I'm having trouble with commons-logging in a scenario where I
On 19 Nov 2003, at 18:25, Richard Sitze wrote:
Regarding a pluggable LogFactory. It's already there.
Unfortunately,
it's behaviour isn't ideal... Log4J seems to have taken a pre-emenant
place in the scheme of things. [That's been discussed before, forgive
me
for not digging up the details
to Craig :)
- rami
-Original Message-
From: Norbert Klose [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: commons-logging classloading (continued)
Hello,
i currently use Tomcat 4.1.27 bundled with commons-logging
1.0.3
PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Tuesday, November 18, 2003 12:51 PM
Subject: RE: commons-logging classloading (continued)
So, I'm coming into this a bit late and all, and I know a few others have
been looking at this over the past few weeks... hope this does
hi richard
On 18 Nov 2003, at 19:51, Richard Sitze wrote:
So, I'm coming into this a bit late and all, and I know a few others
have
been looking at this over the past few weeks... hope this does more
than
just add fuel to the fire.
commons-discovery was created to address the classloader
Will Jaynes wrote:
robert burrell donkin wrote:
...
2, a more sophisticated implementation for the loading of the
LogFactory implementation that would try to load the class from the
LogFactory class classloader if the assignment fails. since (at the
moment) we throw an exception in this
Will Jaynes wrote:
Well, I submitted this as a bug and included a patch. But Remy
immediately marked it as RESOLVED/WONTFIX. He doesn't really address my
suggestion other than to say that c-l if used properly ... is well
thought out, and works perfectly well I would never suggest that c-l is
Hello,
i currently use Tomcat 4.1.27 bundled with commons-logging 1.0.3. My own webapp i'm
working on also uses commons-logging, so i include a copy of the jar file into the
WEB-INF/lib directory to be protable to other servlet containers that does not include
the commons-logging package. I
]
Sent: Thursday, October 30, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: commons-logging classloading (continued)
Hello,
i currently use Tomcat 4.1.27 bundled with commons-logging
1.0.3. My own webapp i'm working on also uses commons-logging,
so i include a copy of the jar file into the WEB-INF
classloader.
(Hint to Craig :)
- rami
-Original Message-
From: Norbert Klose [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: commons-logging classloading (continued)
Hello,
i currently use Tomcat 4.1.27 bundled with commons
be the default).
- rami
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 14, 2003 1:18 AM
To: Jakarta Commons Developers List
Subject: Re: commons-logging classloading
Will Jaynes wrote:
Yoav,
I, too, use log4j directly in my own classes. But we all
:[EMAIL PROTECTED]
Sent: Tuesday, October 14, 2003 1:18 AM
To: Jakarta Commons Developers List
Subject: Re: commons-logging classloading
Will Jaynes wrote:
Yoav,
I, too, use log4j directly in my own classes. But we all use
components that use commons-logging, so we have to deal with it.
No one
Craig R. McClanahan wrote:
Ojares Rami EINT wrote:
Craig,
Would it be difficult to somehow parametrize the classloading in
commons-logging.
I just commented out small portion that resorts to thread classloader.
To me it seems that it would be very trivial to give the user possibility
to
On Monday, October 13, 2003, at 12:42 PM, Will Jaynes wrote:
snip
No one has yet described for me a use case where the current
commons-logging classloading strategy is necessary or even correct.
Whereas I have described a use case where it clearly fails, and have
implemented a code change
, October 13, 2003 03:14 PM
To: 'Jakarta Commons Developers List'
Subject: Re: commons-logging classloading
Remy Maucherat wrote:
Will Jaynes wrote:
I was hoping some developers would weigh in on this issue. I expect
that this has been discussed before, but I can't find any
Todd,
With the jars configured as you describe, how do you configure different
logging properties for each web app?
Todd Jonker wrote:
Will, what I suggest is placing c-l.jar in your server-level
classpath, or in the JVM classpath... and **nowhere else**. If you
have any custom Logs or
what kind of properties?
if you want to change the logging implementation then the stuff with the
context classloader should mean that each web application should get it's
own instance of the factory and each factory should use the classloader to
load the commons-logging.properties file which
Will Jaynes wrote:
Yoav,
I, too, use log4j directly in my own classes. But we all use
components that use commons-logging, so we have to deal with it.
No one has yet described for me a use case where the current
commons-logging classloading strategy is necessary or even correct.
Whereas I
Why does LogFactoryImpl in commons-logging
try to load the Log implementation class first
from thread classloader and then loader that loaded this class?
Is there some kind of design pattern behind this?
One very common :-) use case for commons-logging is inside web
applications, where the
it to ignore
the thread-context classloader.
.T.
-Original Message-
From: Will Jaynes [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 9, 2003 03:02 PM
To: [EMAIL PROTECTED]
Subject: Re: commons-logging classloading
Why does LogFactoryImpl in commons-logging
try to load the Log
Why does LogFactoryImpl in commons-logging
try to load the Log implementation class first
from thread classloader and then loader that loaded this class?
Is there some kind of design pattern behind this?
One very common :-) use case for commons-logging is inside web
applications, where the
Why does LogFactoryImpl in commons-logging
try to load the Log implementation class first
from thread classloader and then loader that loaded this class?
Is there some kind of design pattern behind this?
- Rami Ojares / Elisa Internet
--
Man Plans, God Laughs
24 matches
Mail list logo
