aslom 2002/12/12 05:52:51
Added: java/lib/log4j README.txt
Log:
added README for lib/log4j
Revision ChangesPath
1.1 xml-axis-wsif/java/lib/log4j/README.txt
Index: README.txt
Thank you for your comments. I'm the one responsible for migrating AXIS to the commons-logging API. Let me first acknowledge that recent builds of the commons-logging API DO tend to (unnaturally) favor Log4j. However, the fundamental principle of being able to remove Log4j is still avai
William,
log4j is NOT NEEDED AT ALL in the latest cvs. Which version are you using?
Thanks,
dims
--- Alice Byrne <[EMAIL PROTECTED]> wrote:
> Hello,
>
>The AXIS toolkit is very impressive and we used it up until the java policies got
>in the way
> running stub
Hello,
The AXIS toolkit is very impressive
and we used it up until the java policies got in the way running stubs from
within applets. Apparently, it's not a trivial matter to suppress the property
reads being performed by log4j. Additionally, it's not practical to remove
no objections from me.
Thanks,
dims
--- [EMAIL PROTECTED] wrote:
> Any objections to grabbing the latest log4j?
> Just tested it and everything seems to work.
> -Dug
=
Davanum Srinivas - http://xml.apache.org/~dims/
__
Do You Yaho
Any objections to grabbing the latest log4j?
Just tested it and everything seems to work.
-Dug
Thomas,
Axis uses the commons-logging framework to log, by default, to log4j.
Glyn
Thomas Börkel
HI!
Someone mentioned that Axis switched from log4j to commons-logging. But why is there
still log4j-core.jar in Beta1?
Regards,
Thomas
I was on leave, but here's a somewhat belated +1 to your proposal.
Glyn
Hello,
The problem has been identified. It is basically a backward
compatibility problem of the worst kind: everything appears ok at
compile time only to blow up at your face at runtime.
The symptom
===
Source code will compile fine using either log4j-1.1.3.jar or
log4j-1.2alphaX.jar
Axis-dev -
I'm attempting to use the main branch log4j code to obtain
log4j.appender.SyslogAppender functionality (a file not in
log4j-core.jar), but I'm running into an interop issue with Axis.
Can the main branch versions of the two libraries to work together? If
not, is th
On JRun 3.1, we get this when invoking Axis:
org/apache/log4j/Logger
java.lang.NoClassDefFoundError: org/apache/log4j/Logger
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:237)
at
work, it has it as a part of it's design
> requirements to stay that way.
Yup, it did exist, at least in August:
http://marc.theaimsgroup.com/?l=axis-dev&m=99850196719458&w=2
However, that vote got a total of zero responses, and we went with the log4j-centric
solution. At the tim
To: [EMAIL PROTECTED]
@IBMUS cc:
Subject: RE: Interop with Log4j & AXIS
Logging in general
Hi Tom,
Nothing that would affect backward compatibility was added or removed in the
recent past. So I can't think of anything. Could you provide more detail
about the problem
please? Thank you, Ceki
At 11:36 08.02.2002 -0500, Tom Jordahl wrote:
>Tom Jordahl wrote:
> > The lat
Log4j 1.2alpha is perfectly backward compatible with 1.1.3. It's not
maybe or perhaps. Please provide exact details about the
nature of the problem. Thank you, Ceki
At 11:40 08.02.2002 -0500, Glen Daniels wrote:
>Hi all!
>
>I think this is a result of the change to make C
Richard Sitze wrote:
>
> The JCLI is an interface with thin-wrapper implementations of that
> interface for Log4J, Avalon Toolkit, J2EE 1.4 Logging API, a simple
> (System.out) logger, and a NoOp Logger. The "category" notion is handed
> straight through, so if you are u
The JCLI is an interface with thin-wrapper implementations of that
interface for Log4J, Avalon Toolkit, J2EE 1.4 Logging API, a simple
(System.out) logger, and a NoOp Logger. The "category" notion is handed
straight through, so if you are using Log4J you loose only the benefits of
Hi Richard:
We did discuss this a few times previously, but never got traction on actually doing
it. I for one would be fine with this, with the understanding that we lose a bit of
the dynamic configuration power in log4j once we hide it behind the Log
abstraction Your point #3 strikes
Given:
1. my earlier proposal to replace the direct Log4J dependency in AXIS with
the Jakarta Common Logging Interface (defaulting to Log4J),
2. The resounding silence (defaulting to a Yes vote), and
3. The current situation...
I'm moving forward as proposed. This should either co
Hi all!
I think this is a result of the change to make Category extend Logger. All of our
code uses Category, and so using code compiled with log4j 1.2 with log4j 1.1.3 causes
some problem with Logger not being found. Sorry I can't be more detailed myself. Are
you guys aware o
Tom Jordahl wrote:
> The latest log4j from CVS has made a incompatible change from the previous
> release version.
Sam Ruby wrote:
> Have you communicated this to the log4j development team? Such changes
> would eventually impact Axis users... I can tell you that the log4j
Tom Jordahl wrote:
>
> The latest log4j has made a incompatible change from the previous
> release version.
Have you communicated this to the log4j development team? Such changes
would eventually impact Axis users... I can tell you that the log4j team
takes backwards compatibi
The latest log4j has made a incompatible change from the previous release version.
There are certain people who believe Axis should build against the absolute bleeding
edge CVS code of our dependencies, which are currently log4j and wsdl4j, not against
the jar files checked in to our tree. I
Axis-dev -
I'm attempting to use the main branch log4j code to obtain
log4j.appender.SyslogAppender functionality (a file not in
log4j-core.jar), but I'm running into an interop issue with Axis.
Can the main branch versions of the two libraries to work together? If
not, is th
+1
--
Tom Jordahl
-Original Message-
From: Glen Daniels [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 01, 2002 9:44 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Log4J date in JAR file name
Personally, I'd like to see a "checkpoint" nightly build which is bui
Personally, I'd like to see a "checkpoint" nightly build which is built with exactly
the jars in lib/, and then a separate "bleeding-edge" build There have been
several occasions where we've wanted to switch to a nightly but had to rebuild
ourselves becau
Glen Daniels writes:
>
> Sam? Is this because we don't want to force people to move to an un-"official"
> log4j release like 1.2? (that rationale doesn't actually seem to work since the
> 1.2 classes will shadow the 1.1.3 ones if the new jar is
Title: Log4J date in JAR file name
Sam? Is this because we don't want to force people to move to an
un-"official" log4j release like 1.2? (that rationale doesn't actually
seem to work since the 1.2 classes will shadow the 1.1.3 ones if the new jar is
on the cl
Title: Log4J date in JAR file name
C'mon guys. I'm betting there's some good reason
why log4j.jar in the interim drops includes a date in the name. I'd just like to
hear what it is. Can someone please tell me?
If there is a good reason, why aren't other JARs
lik
Title: Log4J date in JAR file name
What's the rationale for including a date in the log4j.jar file name or the interim drops?
***
WARNING: All e-mail sent to and from this address will be receiv
31 matches
Mail list logo
