At 06:48 AM 1/20/2005, Jacob Kjome wrote:
I don't understand what you mean here? If the server provides only Java2
classloading behavior, no matter what you bundle with your app, you are at
the mercy of the server version. Backwards compatibility would certainly
be key in keeping apps running,
Hi,
>Does this mean that servers like Weblogic JBoss are not properly
>implementing
>the servlet spec? For instance, Weblogic comes with Log4j in the classpath
>because it uses Log4j for logging. Whether or not I add log4j.jar to
>WEB-INF/lib, the one from the server is used. I believe there is
Quoting Yoav Shapira <[EMAIL PROTECTED]>:
> Hi,
>
> >> I don;t know the internals of Tomcat now, but once upon a time, the whole
> >> point of Catalina was exactly the above, and not a "Child First
> >>Behavior". If
> >> CFB is in place in Tomcat, it is because of this bad entropy, and Tomcat
> >>
On Thursday 20 January 2005 16:24, Jacob Kjome wrote:
> > Whether Log4J has added its share to the current state, I will leave
> > unsaid... :o)
>
> If you are going to imply it, please say it (even with a happy face). I'm
> not sure what you mean here, but maybe the UGLI stuff eases this issue.
Hi,
>> I don;t know the internals of Tomcat now, but once upon a time, the whole
>> point of Catalina was exactly the above, and not a "Child First
>>Behavior". If
>> CFB is in place in Tomcat, it is because of this bad entropy, and Tomcat
>>is
>> then indirectly adding to it.
>No, it is because
Quoting Niclas Hedhman <[EMAIL PROTECTED]>:
> On Thursday 20 January 2005 05:48, Jacob Kjome wrote:
> > Only server implementing
> > child-first classloading behavior could allow you to bundle log4j.jar with
> > the webapp and count on that version being used rather than the server
> > version.
>
Endre,
Thanks to a recent contribution by Yoav Shapira, log4j can pick up any
env-entry value specified in web.xml
and perform variable substitution.
In web.xml
==
BASE
/some/path/
java.lang.String
In your config file
===
...
..
If you are using
On Thursday 20 January 2005 05:48, Jacob Kjome wrote:
> Only server implementing
> child-first classloading behavior could allow you to bundle log4j.jar with
> the webapp and count on that version being used rather than the server
> version.
Not necessarily true.
IMHO, A container should NOT prov
At 06:02 PM 1/19/2005 +0100, you wrote:
>At 12:49 AM 1/19/2005, Jacob Kjome wrote:
>
>>of course if you have the authority to add log4j.jar to the server's
>>classpath,
>>why wouldn't you have the authority to add other jars there as well?
>
>That's an extremely interesting point. Although you coul
At 12:49 AM 1/19/2005, Jacob Kjome wrote:
of course if you have the authority to add log4j.jar to the server's
classpath,
why wouldn't you have the authority to add other jars there as well?
That's an extremely interesting point. Although you could place other
jar files along with log4j-(core).jar
multitude of api specific jars? Does this get in
the way of what you
are trying to accomplish?
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 13, 2005 9:09 AM
To: log4j-dev@logging.apache.org
Subject: [POLL] Splitting log4j.jar by dependency
Quoting Ceki Gülcü <[EMAIL PROTECTED]>:
> At 03:09 PM 1/17/2005, Endre Stølsvik wrote:
> >On Thu, 13 Jan 2005, Ceki Gülcü wrote:
> >|
> >| One of the important features in 1.3 is that you no longer have to
> >| ship log4j.jar in WARs.
> >
> >What if the servlet container does not provide log4j? It
2005 9:09 AM
> To: log4j-dev@logging.apache.org
> Subject: [POLL] Splitting log4j.jar by dependency
>
>
> Hello all,
>
> While performing some tests with Tomcat, I noticed that if log4j.jar
> is placed in ./common/lib/, then for example an instance of
> SMTAppend
At 03:09 PM 1/17/2005, Endre Stølsvik wrote:
On Thu, 13 Jan 2005, Ceki Gülcü wrote:
|
| One of the important features in 1.3 is that you no longer have to
| ship log4j.jar in WARs.
What if the servlet container does not provide log4j? It isn't exactly
mandated by the spec.
No log4j is not mandated
On Thu, 13 Jan 2005, Ceki Gülcü wrote:
| At 06:21 PM 1/13/2005, Ionel GARDAIS wrote:
| >+1
| >
| >Its also make log4j lighter when shipped into WARs.
|
| One of the important features in 1.3 is that you no longer have to
| ship log4j.jar in WARs.
What if the servlet container does not provide log
At 10:24 PM 1/14/2005, Gary Gregory wrote:
Hello All:
In the XP spirit of "release early, release often", what about releasing
1.3 and saving this large scale change for a 1.4?
Knowingly releasing code which will consistently blow up in people's faces
will not serve the sprit of XP.
Gary
--
Ceki
ubject: Re: [POLL] Splitting log4j.jar by dependency
Quoting Ceki Gülcü <[EMAIL PROTECTED]>:
> At 05:41 PM 1/14/2005, Jacob Kjome wrote:
>
> >I'm speaking of "endorsed" in a slightly different sense. Not physically
> >endorsed as having been added to the endorsed
Quoting Ceki Gülcü <[EMAIL PROTECTED]>:
> At 05:41 PM 1/14/2005, Jacob Kjome wrote:
>
> >I'm speaking of "endorsed" in a slightly different sense. Not physically
> >endorsed as having been added to the endorsed classloader repository. The
> >mere
> >fact that they are meant to be core Java or J2E
At 05:41 PM 1/14/2005, Jacob Kjome wrote:
I'm speaking of "endorsed" in a slightly different sense. Not physically
endorsed as having been added to the endorsed classloader repository. The
mere
fact that they are meant to be core Java or J2EE libraries qualifies them, in
my interpretation, as "en
Quoting Yoav Shapira <[EMAIL PROTECTED]>:
> Hi,
>
> > Placing endorsed libraries in WEB-INF/lib is *not* recommended. In fact,
> > Tomcat actively avoids loading at least some endorsed libraries from
> > WEB-INF/lib (Not sure about all maybe Yoav can clarify?). By
> > "endorsed", I mean stu
At 07:49 PM 1/13/2005, Yoav Shapira wrote:
Hi,
> One of the important features in 1.3 is that you no longer have to
> ship log4j.jar in WARs. The idea is to place log4j.jar in your
> server's common/lib or equivalent.
Some servers don't have a common/lib directory or equivalent. It's not
part of
Hi,
> Placing endorsed libraries in WEB-INF/lib is *not* recommended. In fact,
> Tomcat actively avoids loading at least some endorsed libraries from
> WEB-INF/lib (Not sure about all maybe Yoav can clarify?). By
> "endorsed", I mean stuff like javax.*, org.xml.*, org.w3c.dom.*, etc
+1
But wouldn't it be nice to have a log4j-core.jar also?
- Johan
[EMAIL PROTECTED]
http://dev.kanngard.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+0
Whatever you guys think.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+0
Whatever you guys think.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
At 06:08 PM 1/13/2005 +0100, you wrote:
>
>This way, the user wishing to use SMTPAppender in her application can
>place log4j-smtp.jar and mail.jar in her application's WEB-INF/lib
>directory without the need to add any new jar files in ./common/lib.
>
>What do you think?
>
Placing endorsed librari
Quoting Elias Ross <[EMAIL PROTECTED]>:
>
> I would keep log4j.jar as-is (except maybe chainsaw) for easy
> compatibility, then create a log4j-core.jar that has no appenders that
> depend on third party software and then package these remaining
> appenders in log4j-ext.jar (or log4j-smtp, jms, etc
I would keep log4j.jar as-is (except maybe chainsaw) for easy
compatibility, then create a log4j-core.jar that has no appenders that
depend on third party software and then package these remaining
appenders in log4j-ext.jar (or log4j-smtp, jms, etc.) as you describe
below.
> On Thu, 13 Jan 2005 1
Putting my Chainsaw hat on, +1. This would mean that I would actually
need the Plugin classloader inside Chainsaw. *-jms.jar and *-db.jar
could then be placed in the plugin lib area with the drivers/impl
classes and it will work from Webstart.
I too don't buy the "size is too big" argument un
+1
On Thu, 13 Jan 2005 18:08:43 +0100, Ceki Gülcü <[EMAIL PROTECTED]> wrote:
>
> Hello all,
>
> While performing some tests with Tomcat, I noticed that if log4j.jar
> is placed in ./common/lib/, then for example an instance of
> SMTAppender cannot be created without placing 'mail.jar' also in
>
Hi,
> One of the important features in 1.3 is that you no longer have to
> ship log4j.jar in WARs. The idea is to place log4j.jar in your
> server's common/lib or equivalent.
Some servers don't have a common/lib directory or equivalent. It's not part of
the J2EE or Servlet Specifications, and as
On Thursday 13 January 2005 09:08, Ceki Gülcü wrote:
> I propose to split log4j.jar by
> dependency. For example,
> What do you think?
I like that a lot, since we can do all kind of funky dependency declarations
and get exactly what is required loaded correctly.
Cheers
Niclas
At 06:21 PM 1/13/2005, Ionel GARDAIS wrote:
+1
Its also make log4j lighter when shipped into WARs.
One of the important features in 1.3 is that you no longer have to
ship log4j.jar in WARs. The idea is to place log4j.jar in your
server's common/lib or equivalent. Log4j will still be able to treat
t
+1
Its also make log4j lighter when shipped into WARs.
ionel
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails !
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/
--
Hello all,
While performing some tests with Tomcat, I noticed that if log4j.jar
is placed in ./common/lib/, then for example an instance of
SMTAppender cannot be created without placing 'mail.jar' also in
./common/lib/, placing 'mail.jar' in WEB-INF/lib is not enough.
To circumvent this problem, I
35 matches
Mail list logo
