I'm not sure it's really any better, but another option might be to
fork(fix) commons-logging. This version could just directly use
log4j(or whatever) instead of relying on the classloader to work it
out. You might then have to replace all instances of the
commons-logging jar in the app server.
Mike
On Aug 27, 2004, at 7:27 PM, Oleg Kalnichevski wrote:
Hi Eric
Personally up to now I have not had too much of a hard time using
commons-logging with Websphere 5.0 and 5.1. Maybe I was just lucky
You may want to fork off the HttpClient 2.0 branch and host it on the
SourceForge, for instance. HttpClient 2.0 is stable and will not be
actively developed in the future. So you should not have too much
trouble keeping the forked version in sync with the official one. The
drawback of this approach is that once HttpClient 3.0 is out you may
have to repeat the whole exercise again. So, probably a better solution
would be to develop a simple converter, which would walk through the
source code and replace all the references to commons-logging with
log4j
or jdk14. Such a converter could be used against any other
commons-logging dependent library or application, so it might be a
worthwhile investment.
We'd happily include this utility into the contrib package
Just a bunch of random thoughts
Oleg
On Sat, 2004-08-28 at 00:39, Eric Bloch wrote:
Hey Folks,
I've experienced a few problems with httpclient not instantiating in a
web application under some containers (websphere 5.1 is the latest,
but
I've seen problems in tomcat and ATG as well). This turns out to
*always* be a problem with class-loading and commons-logging. It's
hard
to precisely describe the problems, but it always seems like it has
something to do with different class-loaders loading the
commons-logging
api or implementation jar.
I'm wondering what the current advice is on common-logging. See
http://www.qos.ch/logging/thinkAgain.html for details on links to the
numerous problems and problem reports with commons-logging. I
imagine I
could be walking into a religious debate here, bu, as far as I can
tell,
commons-logging is basically broken wrt to its class-loader and the
servlet-container spec for class-loading. (It always chooses the Java
spec rather than the servlet container spec).
I really only care about httpclient, but unfortunately, it seems I'm
stuck with commons-logging because httpclient uses it. The only plan
I
can think of now is to remove commons-logging from httpclient.
1) Is there anyone else interested in a copy of httpclient modified to
use either jdk1.4 logging or log4j logging directly? Any preferences
(me I prefer log4j mostly because it's what I'm accustomed to).
2) Anyone have any advice on how to maintain a copy of httpclient that
avoided commons-logging?
3) Anyone know any commons-logging folks I can email/talk to?
FWIW, I'm not a class-loader expert. I've tried to explain the
problems
to commons-logging folks in a bug I filed (and in other bugs I've
read),
but I don't see this getting resolved in a timely fashion.
-Eric
--------------------
A few details btw:
To get things working in ATG, I had to:
- unjar DAS/lib/classes.jar
- remove org/apache/common/*
- jar it back up into classes.jar
I also removed the common_logging.jar file (it looks like there are
some
additional org.apache.common.logging classes in there too)
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
