You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mladen Turk <mt...@apache.org> on 2005/03/15 12:34:29 UTC
Tagging JK 1.2.9 on 3/17/2005
Hi all,
My plan is to tag the JK_1_2_9_BETA on March 17th.
The beta release will be available for testing from that date.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by Henri Gomez <he...@gmail.com>.
Ok, I'll do the usual specific iSeries build to ensure everything is ok.
I rebuild the current HEAD on Linux and it seems to works as expected :)
On Tue, 15 Mar 2005 12:34:29 +0100, Mladen Turk <mt...@apache.org> wrote:
> Hi all,
>
> My plan is to tag the JK_1_2_9_BETA on March 17th.
> The beta release will be available for testing from that date.
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by Rainer Jung <to...@kippdata.de>.
Hi,
socket_timeout on Solaris: does very well during connect.
Also no more erors/warning during build.
I tested by adding microsecond timestamps to jk_log, adding some trace log
messages to nb_connect and changing socket_timeout in nb_connect to
millisecond resolution.
Then I stressed to tomcat system and could see that:
- the connect call comes back immediately (non blocking) with EINPROGRESS
- the select call comes back immediately after connect or very close to
the timeout given.
- if I put the timeout very small (e.g. 5 milliseconds) connect fails and
indeed a packet sniff shows, that the handshake was not fast enough.
- with 15 milliseconds one of the three attempts succeed (motly the second
one)
- with a higher timeout the first attempt succeeds and the timestamp of
the return of the select call nicely fits with the end of the three way
tcp handshake (syn/sysn_ack/ack) from the packet sniff.
- without any stress on the target system the connect alredy comes back
with rc/errno=0 (success) and no select is done.
Regards,
Rainer
> Rainer Jung wrote:
>> I could help with Solaris info. If you tell me, what you are interested
>> in, I can do some tests.
>>
> Build, socket_timeout and JkShmFile.
>
> Regards,
> Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by Rainer Jung <to...@kippdata.de>.
>> 2) The test in configure about functionality of the timeouts is broken.
>> The test program does not compile under Solaris, because it needs
>> "-lsocket".
>
> Can you provide a patch for that?
How about:
*** configure.in.orig Thu Mar 17 17:00:36 2005
--- configure.in Thu Mar 17 21:28:29 2005
***************
*** 56,63 ****
dnl check for flock function.
AC_CHECK_FUNC(flock, AC_DEFINE(HAVE_FLOCK,1,[Have flock()]))
! AC_DEFUN(JK_CHECK_SETSOCKOPT, [
AC_MSG_CHECKING(whether to use $1 with setsockopt())
AC_TRY_RUN([
#include <sys/types.h>
#include <sys/socket.h>
--- 56,65 ----
dnl check for flock function.
AC_CHECK_FUNC(flock, AC_DEFINE(HAVE_FLOCK,1,[Have flock()]))
! AC_DEFUN([JK_CHECK_SETSOCKOPT], [
AC_MSG_CHECKING(whether to use $1 with setsockopt())
+ saved_LIBS="$LIBS"
+ LIBS="$saved_LIBS -lsocket"
AC_TRY_RUN([
#include <sys/types.h>
#include <sys/socket.h>
***************
*** 88,93 ****
--- 90,96 ----
, [ AC_MSG_RESULT([yes]) AC_DEFINE(USE_$1, 1, [Define to use $1 with
setsockopt()]) ]
, [ AC_MSG_RESULT([no]) ]
)
+ LIBS="$saved_LIBS"
])dnl
dnl check for SO_RCVTIMEO and SO_SNDTIMEO
Since it's only changed line and three added I did not use local CVS to
make diff -u and I hope this context diff suffices.
That way the test runs smoothly, of course with the same negative but
clean result:
configure:19433: checking whether to use SO_RCVTIMEO with setsockopt()
configure:19480: gcc -specs=/usr/local/apautobuild/specs -o conftest -O2
conftest.c -lsocket >&5
configure:19483: $? = 0
configure:19485: ./conftest
configure:19488: $? = 1
configure: program exited with status 1
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by NormW <no...@bocnet.com.au>.
Greetings All,
Still get a clean build for NetWare against Apache 2.1 and 2.0.53.
The XML pages work fine, although the HTML status pages might put the
numbers under headings better if 'border=1' was enabled.
AFAIK builds for Apache 1.1.3 for NetWare still has issues, since I've
not seen mention of updates for that version. Perhaps JJC can comment?
Regards,
Norm
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> jk 1.2.9-dev build on iSeries without problem.
>
> Wit my admins to redeploy and test it
>
Cool!
I'll probably tag that tomorrow.
Its getting late here :)
Since Apache infrastructure will be unavailable over the
weekend I hope the beta will be mirrored by that time.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
I have been trying to get really serious about log4j in web apps.
I note that Tomcat (thanks to commons-logging) uses java.util.logging
*except* for loggers created while my web app's classloader is the
current contextual classloader -- at which point it suddenly uses log4j
(since my web app does) without giving my web app a chance to initialize
it in any way as best I can tell.
My web app has a ServletContextListener which initializes log4j by
setting up its own LoggerRepository, configuration file and watcher
(since log4j's won't shutdown), etc. Of course, every Tomcat logger
created within my web app up until this point is now using log4j from my
web app (!) and using the basic log4j.properties [if present] from my
web app -- for loggers that apply to all web apps!
How is one supposed to work this? I am currently using a static
LoggerRepository reference within my web app so that a log4j loaded
higher in the classloader tree won't cause LoggerRepository sharing. I
was using a JNDI-based LoggerRepositorySelector as per log4j author
recommendations, but this goes a step further than above -- it puts all
the Tomcat loggers that are errantly using my log4j into my
LoggerRepository -- which would be fine if these loggers were not shared
with other web apps.
What's the solution here? Do I have to put log4j into Tomcat's lib
directories to force it to use its own centralized log4j? Is that the
best solution?
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Bill Barker wrote:
>You just need to provide the methods (if you wanted to code against
>Catalina, you'd just create a LifecycleListener :). This is a hook into
>commons-modeler, so you technically could use a plain old JavaBean.
>Otherwise, DynamicMBeans probably work best (or, at least give you the most
>control).
>
>
I have gotten used to using my own subclasses to StandardMBean. This
allows me to lay out the "static" portion of my MBean with an interface
and extend it as necessary -- adding dynamic and open MBean behaviors as
necessary in my own classes.
Java 1.5's APT turns out to make automated generation of MBean
descriptions, operation parameter names, impacts, etc, from MBean
interface Javadoc, formal parmeter names, annotations, etc, quite
simple. A little more elbow grease and the descriptions are localized
(based on the server's locale).
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Jess Holle" <je...@ptc.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, March 17, 2005 3:12 PM
Subject: Re: Web apps vs. Logging vs. Tomcat
> Bill Barker wrote:
>
> >----- Original Message -----
> >From: "Jess Holle" <je...@ptc.com>
> >To: "Tomcat Developers List" <to...@jakarta.apache.org>
> >Sent: Thursday, March 17, 2005 2:25 PM
> >Subject: Re: Web apps vs. Logging vs. Tomcat
> >
> >
> >>Just one more stupid question:
> >>
> >> How/where would I register/deregister (start/stop) MBeans at the
> >> Tomcat level for the Tomcat-level log4j LoggerRepository -- rather
> >> than in my ServletContextListener?
> >>
> >>
> >
> >Sounds like a good use for conf/tomcat5-mbeans.xml. It invokes the
standard
> >Lifecycle methods (e.g. 'init', 'start', 'stop', 'destroy') of your
MBeans
> >at the corresponding points of the Engine's Lifecycle, as well as
handling
> >JMX registration and un-registration.
> >
> >
> Cool! Thanks!
>
> Do I have to actually implement Lifecycle or just provide these
> methods? Will a standard/dynamic MBean do or does it have to be a model
> MBean? [Mine extend StandardMBean and implement MBeanRegistration at
> the moment.]
>
You just need to provide the methods (if you wanted to code against
Catalina, you'd just create a LifecycleListener :). This is a hook into
commons-modeler, so you technically could use a plain old JavaBean.
Otherwise, DynamicMBeans probably work best (or, at least give you the most
control).
> --
> Jess Holle
>
>
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Bill Barker wrote:
>----- Original Message -----
>From: "Jess Holle" <je...@ptc.com>
>To: "Tomcat Developers List" <to...@jakarta.apache.org>
>Sent: Thursday, March 17, 2005 2:25 PM
>Subject: Re: Web apps vs. Logging vs. Tomcat
>
>
>>Just one more stupid question:
>>
>> How/where would I register/deregister (start/stop) MBeans at the
>> Tomcat level for the Tomcat-level log4j LoggerRepository -- rather
>> than in my ServletContextListener?
>>
>>
>
>Sounds like a good use for conf/tomcat5-mbeans.xml. It invokes the standard
>Lifecycle methods (e.g. 'init', 'start', 'stop', 'destroy') of your MBeans
>at the corresponding points of the Engine's Lifecycle, as well as handling
>JMX registration and un-registration.
>
>
Cool! Thanks!
Do I have to actually implement Lifecycle or just provide these
methods? Will a standard/dynamic MBean do or does it have to be a model
MBean? [Mine extend StandardMBean and implement MBeanRegistration at
the moment.]
--
Jess Holle
Re: Web apps vs. Logging vs. Tomcat
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Jess Holle" <je...@ptc.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, March 17, 2005 2:25 PM
Subject: Re: Web apps vs. Logging vs. Tomcat
> Just one more stupid question:
>
> How/where would I register/deregister (start/stop) MBeans at the
> Tomcat level for the Tomcat-level log4j LoggerRepository -- rather
> than in my ServletContextListener?
>
Sounds like a good use for conf/tomcat5-mbeans.xml. It invokes the standard
Lifecycle methods (e.g. 'init', 'start', 'stop', 'destroy') of your MBeans
at the corresponding points of the Engine's Lifecycle, as well as handling
JMX registration and un-registration.
> For per-web-app MBeans, I can use ServletContextListener, of course,
> but given that log4j loggers are not JMX-exposed, I'd like to put
> some MBeans to do this up at the Tomcat application level. I do
> this in my web app, but I'd like to have the Tomcat-level MBeans
> installed even without any of my web apps installed.
>
> --
> Jess Holle
>
> Yoav Shapira wrote:
>
> >Hola,
> >Your approach is right and should work. You basically have to move
> >everything up the classloader hierarchy into Tomcat's section, and have a
> >copy of the MBean stuff in each webapp classloader repository that you
want
> >to manage.
> >
> >And I agree that it sucks...
> >
> >Yoav
> >
> >
> >
> >>-----Original Message-----
> >>From: Jess Holle [mailto:jessh@ptc.com]
> >>Sent: Thursday, March 17, 2005 4:30 PM
> >>To: Tomcat Developers List
> >>Subject: Re: Web apps vs. Logging vs. Tomcat
> >>
> >>Thanks. That answers that part of the question quite succinctly.
> >>
> >>Now what remains is how can I work with log4j and commons logging --
> >>commons logging's behavior vis-a-vis the contextual classloader seems
> >>onerous if not just plain wrong.
> >>
> >>The only way I can see to "fix" this is to deploy log4j in Tomcat's own
> >>lib directories -- and deploy my log4j controller MBeans there for the
> >>default LoggeRepository and again in each web app for each web app's
> >>LoggerRepository.
> >>
> >>If that's what I need to do, I'll get on with doing it, but I'd like to
> >>know I'm not just overlooking the obvious...
> >>
> >>--
> >>Jess Holle
> >>
> >>Yoav Shapira wrote:
> >>
> >>
> >>
> >>>UGLI is far from mature enough to be used by Tomcat at this point.
When
> >>>log4j 1.3 is out, we'll see.
> >>>
> >>>Yoav
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Jess Holle [mailto:jessh@ptc.com]
> >>>>Sent: Thursday, March 17, 2005 4:17 PM
> >>>>To: Tomcat Developers List
> >>>>Subject: Re: Web apps vs. Logging vs. Tomcat
> >>>>
> >>>>P.S. Why does Tomcat use Commons Logging rather than UGLI?
> >>>>
> >>>>Jess Holle wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>I had e-mailed this to users mailing list, but I have what I believe
> >>>>>is a more "dev" follow-on question:
> >>>>>
> >>>>> Is there a good way to get my own start/stop action called at a
> >>>>> per-VM level?
> >>>>>
> >>>>> This is assuming I end up having to move log4j up into Tomcat's
> >>>>> classloaders -- at which point I'll want to install my
> >>>>> LoggerRepository controlling MBeans up at this level as well -- as
> >>>>> log4j's MBeans have issues and using log4j loggers means you don't
> >>>>> get the (admittedly sparse) java.util.logging MBean coverage.
> >>>>>
> >>>>>--
> >>>>>Jess Holle
> >>>>>
> >>>>>Jess Holle wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>I have been trying to get really serious about log4j in web apps.
> >>>>>>
> >>>>>>I note that Tomcat (thanks to commons-logging) uses
java.util.logging
> >>>>>>*except* for loggers created while my web app's classloader is the
> >>>>>>current contextual classloader -- at which point it suddenly uses
> >>>>>>log4j (since my web app does) without giving my web app a chance to
> >>>>>>initialize it in any way as best I can tell.
> >>>>>>
> >>>>>>My web app has a ServletContextListener which initializes log4j by
> >>>>>>setting up its own LoggerRepository, configuration file and watcher
> >>>>>>(since log4j's won't shutdown), etc. Of course, every Tomcat logger
> >>>>>>created within my web app up until this point is now using log4j
from
> >>>>>>my web app (!) and using the basic log4j.properties [if present]
from
> >>>>>>my web app -- for loggers that apply to all web apps!
> >>>>>>
> >>>>>>How is one supposed to work this? I am currently using a static
> >>>>>>LoggerRepository reference within my web app so that a log4j loaded
> >>>>>>higher in the classloader tree won't cause LoggerRepository sharing.
> >>>>>>I was using a JNDI-based LoggerRepositorySelector as per log4j
author
> >>>>>>recommendations, but this goes a step further than above -- it puts
> >>>>>>all the Tomcat loggers that are errantly using my log4j into my
> >>>>>>LoggerRepository -- which would be fine if these loggers were not
> >>>>>>shared with other web apps.
> >>>>>>
> >>>>>>What's the solution here? Do I have to put log4j into Tomcat's lib
> >>>>>>directories to force it to use its own centralized log4j? Is that
> >>>>>>the best solution?
> >>>>>>
> >>>>>>--
> >>>>>>Jess Holle
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
> >
>
>
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Just one more stupid question:
How/where would I register/deregister (start/stop) MBeans at the
Tomcat level for the Tomcat-level log4j LoggerRepository -- rather
than in my ServletContextListener?
For per-web-app MBeans, I can use ServletContextListener, of course,
but given that log4j loggers are not JMX-exposed, I'd like to put
some MBeans to do this up at the Tomcat application level. I do
this in my web app, but I'd like to have the Tomcat-level MBeans
installed even without any of my web apps installed.
--
Jess Holle
Yoav Shapira wrote:
>Hola,
>Your approach is right and should work. You basically have to move
>everything up the classloader hierarchy into Tomcat's section, and have a
>copy of the MBean stuff in each webapp classloader repository that you want
>to manage.
>
>And I agree that it sucks...
>
>Yoav
>
>
>
>>-----Original Message-----
>>From: Jess Holle [mailto:jessh@ptc.com]
>>Sent: Thursday, March 17, 2005 4:30 PM
>>To: Tomcat Developers List
>>Subject: Re: Web apps vs. Logging vs. Tomcat
>>
>>Thanks. That answers that part of the question quite succinctly.
>>
>>Now what remains is how can I work with log4j and commons logging --
>>commons logging's behavior vis-a-vis the contextual classloader seems
>>onerous if not just plain wrong.
>>
>>The only way I can see to "fix" this is to deploy log4j in Tomcat's own
>>lib directories -- and deploy my log4j controller MBeans there for the
>>default LoggeRepository and again in each web app for each web app's
>>LoggerRepository.
>>
>>If that's what I need to do, I'll get on with doing it, but I'd like to
>>know I'm not just overlooking the obvious...
>>
>>--
>>Jess Holle
>>
>>Yoav Shapira wrote:
>>
>>
>>
>>>UGLI is far from mature enough to be used by Tomcat at this point. When
>>>log4j 1.3 is out, we'll see.
>>>
>>>Yoav
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Jess Holle [mailto:jessh@ptc.com]
>>>>Sent: Thursday, March 17, 2005 4:17 PM
>>>>To: Tomcat Developers List
>>>>Subject: Re: Web apps vs. Logging vs. Tomcat
>>>>
>>>>P.S. Why does Tomcat use Commons Logging rather than UGLI?
>>>>
>>>>Jess Holle wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I had e-mailed this to users mailing list, but I have what I believe
>>>>>is a more "dev" follow-on question:
>>>>>
>>>>> Is there a good way to get my own start/stop action called at a
>>>>> per-VM level?
>>>>>
>>>>> This is assuming I end up having to move log4j up into Tomcat's
>>>>> classloaders -- at which point I'll want to install my
>>>>> LoggerRepository controlling MBeans up at this level as well -- as
>>>>> log4j's MBeans have issues and using log4j loggers means you don't
>>>>> get the (admittedly sparse) java.util.logging MBean coverage.
>>>>>
>>>>>--
>>>>>Jess Holle
>>>>>
>>>>>Jess Holle wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I have been trying to get really serious about log4j in web apps.
>>>>>>
>>>>>>I note that Tomcat (thanks to commons-logging) uses java.util.logging
>>>>>>*except* for loggers created while my web app's classloader is the
>>>>>>current contextual classloader -- at which point it suddenly uses
>>>>>>log4j (since my web app does) without giving my web app a chance to
>>>>>>initialize it in any way as best I can tell.
>>>>>>
>>>>>>My web app has a ServletContextListener which initializes log4j by
>>>>>>setting up its own LoggerRepository, configuration file and watcher
>>>>>>(since log4j's won't shutdown), etc. Of course, every Tomcat logger
>>>>>>created within my web app up until this point is now using log4j from
>>>>>>my web app (!) and using the basic log4j.properties [if present] from
>>>>>>my web app -- for loggers that apply to all web apps!
>>>>>>
>>>>>>How is one supposed to work this? I am currently using a static
>>>>>>LoggerRepository reference within my web app so that a log4j loaded
>>>>>>higher in the classloader tree won't cause LoggerRepository sharing.
>>>>>>I was using a JNDI-based LoggerRepositorySelector as per log4j author
>>>>>>recommendations, but this goes a step further than above -- it puts
>>>>>>all the Tomcat loggers that are errantly using my log4j into my
>>>>>>LoggerRepository -- which would be fine if these loggers were not
>>>>>>shared with other web apps.
>>>>>>
>>>>>>What's the solution here? Do I have to put log4j into Tomcat's lib
>>>>>>directories to force it to use its own centralized log4j? Is that
>>>>>>the best solution?
>>>>>>
>>>>>>--
>>>>>>Jess Holle
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
RE: Web apps vs. Logging vs. Tomcat
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hola,
Your approach is right and should work. You basically have to move
everything up the classloader hierarchy into Tomcat's section, and have a
copy of the MBean stuff in each webapp classloader repository that you want
to manage.
And I agree that it sucks...
Yoav
> -----Original Message-----
> From: Jess Holle [mailto:jessh@ptc.com]
> Sent: Thursday, March 17, 2005 4:30 PM
> To: Tomcat Developers List
> Subject: Re: Web apps vs. Logging vs. Tomcat
>
> Thanks. That answers that part of the question quite succinctly.
>
> Now what remains is how can I work with log4j and commons logging --
> commons logging's behavior vis-a-vis the contextual classloader seems
> onerous if not just plain wrong.
>
> The only way I can see to "fix" this is to deploy log4j in Tomcat's own
> lib directories -- and deploy my log4j controller MBeans there for the
> default LoggeRepository and again in each web app for each web app's
> LoggerRepository.
>
> If that's what I need to do, I'll get on with doing it, but I'd like to
> know I'm not just overlooking the obvious...
>
> --
> Jess Holle
>
> Yoav Shapira wrote:
>
> >UGLI is far from mature enough to be used by Tomcat at this point. When
> >log4j 1.3 is out, we'll see.
> >
> >Yoav
> >
> >
> >>-----Original Message-----
> >>From: Jess Holle [mailto:jessh@ptc.com]
> >>Sent: Thursday, March 17, 2005 4:17 PM
> >>To: Tomcat Developers List
> >>Subject: Re: Web apps vs. Logging vs. Tomcat
> >>
> >>P.S. Why does Tomcat use Commons Logging rather than UGLI?
> >>
> >>Jess Holle wrote:
> >>
> >>
> >>
> >>>I had e-mailed this to users mailing list, but I have what I believe
> >>>is a more "dev" follow-on question:
> >>>
> >>> Is there a good way to get my own start/stop action called at a
> >>> per-VM level?
> >>>
> >>> This is assuming I end up having to move log4j up into Tomcat's
> >>> classloaders -- at which point I'll want to install my
> >>> LoggerRepository controlling MBeans up at this level as well -- as
> >>> log4j's MBeans have issues and using log4j loggers means you don't
> >>> get the (admittedly sparse) java.util.logging MBean coverage.
> >>>
> >>>--
> >>>Jess Holle
> >>>
> >>>Jess Holle wrote:
> >>>
> >>>
> >>>
> >>>>I have been trying to get really serious about log4j in web apps.
> >>>>
> >>>>I note that Tomcat (thanks to commons-logging) uses java.util.logging
> >>>>*except* for loggers created while my web app's classloader is the
> >>>>current contextual classloader -- at which point it suddenly uses
> >>>>log4j (since my web app does) without giving my web app a chance to
> >>>>initialize it in any way as best I can tell.
> >>>>
> >>>>My web app has a ServletContextListener which initializes log4j by
> >>>>setting up its own LoggerRepository, configuration file and watcher
> >>>>(since log4j's won't shutdown), etc. Of course, every Tomcat logger
> >>>>created within my web app up until this point is now using log4j from
> >>>>my web app (!) and using the basic log4j.properties [if present] from
> >>>>my web app -- for loggers that apply to all web apps!
> >>>>
> >>>>How is one supposed to work this? I am currently using a static
> >>>>LoggerRepository reference within my web app so that a log4j loaded
> >>>>higher in the classloader tree won't cause LoggerRepository sharing.
> >>>>I was using a JNDI-based LoggerRepositorySelector as per log4j author
> >>>>recommendations, but this goes a step further than above -- it puts
> >>>>all the Tomcat loggers that are errantly using my log4j into my
> >>>>LoggerRepository -- which would be fine if these loggers were not
> >>>>shared with other web apps.
> >>>>
> >>>>What's the solution here? Do I have to put log4j into Tomcat's lib
> >>>>directories to force it to use its own centralized log4j? Is that
> >>>>the best solution?
> >>>>
> >>>>--
> >>>>Jess Holle
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Thanks. That answers that part of the question quite succinctly.
Now what remains is how can I work with log4j and commons logging --
commons logging's behavior vis-a-vis the contextual classloader seems
onerous if not just plain wrong.
The only way I can see to "fix" this is to deploy log4j in Tomcat's own
lib directories -- and deploy my log4j controller MBeans there for the
default LoggeRepository and again in each web app for each web app's
LoggerRepository.
If that's what I need to do, I'll get on with doing it, but I'd like to
know I'm not just overlooking the obvious...
--
Jess Holle
Yoav Shapira wrote:
>UGLI is far from mature enough to be used by Tomcat at this point. When
>log4j 1.3 is out, we'll see.
>
>Yoav
>
>
>>-----Original Message-----
>>From: Jess Holle [mailto:jessh@ptc.com]
>>Sent: Thursday, March 17, 2005 4:17 PM
>>To: Tomcat Developers List
>>Subject: Re: Web apps vs. Logging vs. Tomcat
>>
>>P.S. Why does Tomcat use Commons Logging rather than UGLI?
>>
>>Jess Holle wrote:
>>
>>
>>
>>>I had e-mailed this to users mailing list, but I have what I believe
>>>is a more "dev" follow-on question:
>>>
>>> Is there a good way to get my own start/stop action called at a
>>> per-VM level?
>>>
>>> This is assuming I end up having to move log4j up into Tomcat's
>>> classloaders -- at which point I'll want to install my
>>> LoggerRepository controlling MBeans up at this level as well -- as
>>> log4j's MBeans have issues and using log4j loggers means you don't
>>> get the (admittedly sparse) java.util.logging MBean coverage.
>>>
>>>--
>>>Jess Holle
>>>
>>>Jess Holle wrote:
>>>
>>>
>>>
>>>>I have been trying to get really serious about log4j in web apps.
>>>>
>>>>I note that Tomcat (thanks to commons-logging) uses java.util.logging
>>>>*except* for loggers created while my web app's classloader is the
>>>>current contextual classloader -- at which point it suddenly uses
>>>>log4j (since my web app does) without giving my web app a chance to
>>>>initialize it in any way as best I can tell.
>>>>
>>>>My web app has a ServletContextListener which initializes log4j by
>>>>setting up its own LoggerRepository, configuration file and watcher
>>>>(since log4j's won't shutdown), etc. Of course, every Tomcat logger
>>>>created within my web app up until this point is now using log4j from
>>>>my web app (!) and using the basic log4j.properties [if present] from
>>>>my web app -- for loggers that apply to all web apps!
>>>>
>>>>How is one supposed to work this? I am currently using a static
>>>>LoggerRepository reference within my web app so that a log4j loaded
>>>>higher in the classloader tree won't cause LoggerRepository sharing.
>>>>I was using a JNDI-based LoggerRepositorySelector as per log4j author
>>>>recommendations, but this goes a step further than above -- it puts
>>>>all the Tomcat loggers that are errantly using my log4j into my
>>>>LoggerRepository -- which would be fine if these loggers were not
>>>>shared with other web apps.
>>>>
>>>>What's the solution here? Do I have to put log4j into Tomcat's lib
>>>>directories to force it to use its own centralized log4j? Is that
>>>>the best solution?
>>>>
>>>>--
>>>>Jess Holle
>>>>
>>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> I also added fixes recently so that loggers are not accessed too
> early, which was a similar issue (some loggers would be have be
> improperly associated with the container classloader). There's lots of
> tweaking needed with logging overall, it's sort of to be expected.
I'll have to check out the latest 5.5 as that's basically the other
problem I was seeing. Tomcat using my log4j and my log4j.properties,
but was doing so before my first ServletContextListener was called, so I
had not had a chance to install my LoggerRepositorySelector. Thus these
loggers were in my web app but not using the LoggerRepository I
designated for my web app...
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Here, I suppose modifying all the loggers to be like this:
> private Log log = LogFactory.getLog(JspServlet.class);
> would fix the issue without further problems.
Hmm... Any chance of such a fix in the next few months. I can search
out such and suggest patches, but I'm quite sure you have a far greater
degree of familiarity with the details -- I just saw the "configuration
nightmare" as you aptly put it.
> It's not the official J2EE way (there's no official J2EE way, as the
> default java.util.logging implementation is one global namespace
> unsuitable for containers), but it's similar to JNDI handling.
Understood. I've already got reasonable JNDI-based approach -- assuming
the static loggers are to be cleaned up any time in the near future.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> Remy Maucherat wrote:
> What's unexpected here is as you say that these loggers are static -- or
> in any event not per-web-app. Otherwise, this behavior would be fine
> and good!
Yes, I forgot about Jasper when I added the container loggers in 5.5 :(
At first when we added commons-logging support, we added static loggers
everywhere, since it was very easy this way.
Example from the main JSP servlet class:
private static Log log = LogFactory.getLog(JspServlet.class);
So since Jasper is in the common classloader, the class definition will
be loaded only once, and the loggers used by Jasper will be associated
with the first webapp which is loaded. It's a bit random, since some
classes (ex: the compiler) may be loaded a bit later by other webapps.
-> configuration nightmare
I also added fixes recently so that loggers are not accessed too early,
which was a similar issue (some loggers would be have be improperly
associated with the container classloader). There's lots of tweaking
needed with logging overall, it's sort of to be expected.
Here, I suppose modifying all the loggers to be like this:
private Log log = LogFactory.getLog(JspServlet.class);
would fix the issue without further problems.
>> Another completely different strategy for acquiring loggers is to use
>> the CL which loaded the class (ie, to use straight delegation).
>> There's the problem that it could cause classcast exceptions, however,
>> and it's more annoying to configure.
>>
>> Both solutions behave differently, but they have their own merits. I
>> happen to prefer the context classloader oriented one in a J2EE
>> environment (so it was used for the java.util.logging implementation I
>> added recently based on some user submitted code that I heavily
>> modfied - see http://issues.apache.org/bugzilla/show_bug.cgi?id=33143).
>
> Yes, I now have both approaches coded and as you say both have their
> merits. If the instances wherein Tomcat loggers configured/obtained
> from one web app are used across web apps are eliminated in Tomcat
> 5.5.x, then I could happily use the JNDI/J2EE approach and all Tomcat's
> own loggers for each web app would use that web app's configuration.
> Otherwise I really have to go with the straight delegation approach to
> prevent cross-web-app logger effects.
It's not the official J2EE way (there's no official J2EE way, as the
default java.util.logging implementation is one global namespace
unsuitable for containers), but it's similar to JNDI handling.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Jess Holle wrote:
>
>> Jess Holle wrote:
>>
>> Okay, I did a bit more digging.
>>
>> *If*:
>>
>> * Your web app contains log4j.jar *and* commons-logging.jar.
>> * You do not have log4j installed in any of Tomcat's own lib
>> directories.
>> * You use a JNDI or other contextual classloader based
>> LogRepositorySelector.
>>
>> *Then*:
>>
>> * The first Tomcat web application will "steal" loggers from the
>> Tomcat base, i.e. any that happen to be obtained while the first
>> web app's contextual classloader is active.
>> o In a brief, simple test, whichever web app receives the
>> first JSP page request will "steal" the following Tomcat
>> loggers:
>> + org.apache.jasper.compiler.Compiler
>> + org.apache.jasper.compiler.JspReader
>> + org.apache.jasper.runtime.PageContextImpl
>> + org.apache.jasper.servlet.JspServletWrapper
>> + org.apache.jasper.xmlparser.ParserUtils
>> * By "steal", I mean that these loggers end up in the
>> LoggerRepository of the given web app. Their configuration is thus
>> controlled by it. Also, they use the log4j library from the given
>> web app.
>
> There's nothing unexpected here: Jasper is a regular servlet, and thus
> all of its classes will be loaded with the webapp's classloader. It's
> basically like if you had the Jasper JARs inside /WEB-INF/lib. The
> problem then is that Jasper uses static logger instances, while it
> should either log to the servlet context or have per instance loggers,
> as it resides in a classloader shared across webapps. Regardless of
> what happens, we will need to cleanup Jasper's logging behavior.
What's unexpected here is as you say that these loggers are static -- or
in any event not per-web-app. Otherwise, this behavior would be fine
and good!
> Another completely different strategy for acquiring loggers is to use
> the CL which loaded the class (ie, to use straight delegation).
> There's the problem that it could cause classcast exceptions, however,
> and it's more annoying to configure.
>
> Both solutions behave differently, but they have their own merits. I
> happen to prefer the context classloader oriented one in a J2EE
> environment (so it was used for the java.util.logging implementation I
> added recently based on some user submitted code that I heavily
> modfied - see http://issues.apache.org/bugzilla/show_bug.cgi?id=33143).
Yes, I now have both approaches coded and as you say both have their
merits. If the instances wherein Tomcat loggers configured/obtained
from one web app are used across web apps are eliminated in Tomcat
5.5.x, then I could happily use the JNDI/J2EE approach and all Tomcat's
own loggers for each web app would use that web app's configuration.
Otherwise I really have to go with the straight delegation approach to
prevent cross-web-app logger effects.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> Jess Holle wrote:
>
> Okay, I did a bit more digging.
>
> *If*:
>
> * Your web app contains log4j.jar *and* commons-logging.jar.
> * You do not have log4j installed in any of Tomcat's own lib
> directories.
> * You use a JNDI or other contextual classloader based
> LogRepositorySelector.
>
> *Then*:
>
> * The first Tomcat web application will "steal" loggers from the
> Tomcat base, i.e. any that happen to be obtained while the first
> web app's contextual classloader is active.
> o In a brief, simple test, whichever web app receives the
> first JSP page request will "steal" the following Tomcat
> loggers:
> + org.apache.jasper.compiler.Compiler
> + org.apache.jasper.compiler.JspReader
> + org.apache.jasper.runtime.PageContextImpl
> + org.apache.jasper.servlet.JspServletWrapper
> + org.apache.jasper.xmlparser.ParserUtils
> * By "steal", I mean that these loggers end up in the
> LoggerRepository of the given web app. Their configuration is thus
> controlled by it. Also, they use the log4j library from the given
> web app.
There's nothing unexpected here: Jasper is a regular servlet, and thus
all of its classes will be loaded with the webapp's classloader. It's
basically like if you had the Jasper JARs inside /WEB-INF/lib. The
problem then is that Jasper uses static logger instances, while it
should either log to the servlet context or have per instance loggers,
as it resides in a classloader shared across webapps. Regardless of what
happens, we will need to cleanup Jasper's logging behavior.
Another completely different strategy for acquiring loggers is to use
the CL which loaded the class (ie, to use straight delegation). There's
the problem that it could cause classcast exceptions, however, and it's
more annoying to configure.
Both solutions behave differently, but they have their own merits. I
happen to prefer the context classloader oriented one in a J2EE
environment (so it was used for the java.util.logging implementation I
added recently based on some user submitted code that I heavily modfied
- see http://issues.apache.org/bugzilla/show_bug.cgi?id=33143).
> I could always be mistaken, but my examination of the LoggerRepository's
> involved seems pretty conclusive.
>
> If one has to have log4j and commons-logging in one's web app, then the
> only solution appears to be to put log4j in Tomcat and use a
> non-contextual classloader based LogRepositorySelector. Avoiding the
> contextual classloader based LogRepositorySelector only keeps Tomcats
> loggers from sharing the web app's intended LoggerRepository -- they
> still use the web app's log4j and its default LoggerRepository.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Jess Holle wrote:
> Remy Maucherat wrote:
>
>>>> BTW, JBoss (supposedly, I didn't check personally) uses
>>>> commons-logging everywhere, and the logging implementation used is
>>>> log4j.
>>>
>>> That works since *everything* uses log4j. The issue is with Tomcat
>>> is really one of *not* having log4j at the Tomcat level but having
>>> it in your web app. This leads to:
>>>
>>> * whole crop of loggers using java.util.logging (fine, to be
>>> expected, and there are Java 5 MBeans -- albeit limited -- to
>>> interact with these)
>>> * a few core Tomcat loggers that are *not* by nature per web app
>>> loggers using the log4j jar and configuration of the first web app
>>> that uses the class enclosing them (e.g. the first web app to get
>>> a request!)
>>> * the web app's own classes using whatever you specify
>>>
>>> It is the 2nd of these 3 bullet that is so disturbing to me. I'd
>>> like to see these either have separate loggers for each web app, or
>>> behave like the rest the Tomcat loggers and cause a leak of data and
>>> references between web apps. This -- and a reasonable set of MBeans
>>> to control/expose loggers seems quite doable with the approach Yoav
>>> and Bill laid out. It's just unfortunate that the out-of-the-box
>>> behavior with web apps using log4j is so onerous.
>>
>> The core loggers you talk about are probably the ones used for
>> reporting your servlets/filters/etc loading errors. This seems webapp
>> related to me.
>
> Considering the classes containing these loggers are not per web app
> as best I can tell I don't believe the loggers are, but I guess more
> thorough debugging on my part is in order. Perhaps I am mistaken and
> these are Tomcat loggers, but are specific to my web app.
Okay, I did a bit more digging.
*If*:
* Your web app contains log4j.jar *and* commons-logging.jar.
* You do not have log4j installed in any of Tomcat's own lib
directories.
* You use a JNDI or other contextual classloader based
LogRepositorySelector.
*Then*:
* The first Tomcat web application will "steal" loggers from the
Tomcat base, i.e. any that happen to be obtained while the first
web app's contextual classloader is active.
o In a brief, simple test, whichever web app receives the
first JSP page request will "steal" the following Tomcat
loggers:
+ org.apache.jasper.compiler.Compiler
+ org.apache.jasper.compiler.JspReader
+ org.apache.jasper.runtime.PageContextImpl
+ org.apache.jasper.servlet.JspServletWrapper
+ org.apache.jasper.xmlparser.ParserUtils
* By "steal", I mean that these loggers end up in the
LoggerRepository of the given web app. Their configuration is thus
controlled by it. Also, they use the log4j library from the given
web app.
I could always be mistaken, but my examination of the LoggerRepository's
involved seems pretty conclusive.
If one has to have log4j and commons-logging in one's web app, then the
only solution appears to be to put log4j in Tomcat and use a
non-contextual classloader based LogRepositorySelector. Avoiding the
contextual classloader based LogRepositorySelector only keeps Tomcats
loggers from sharing the web app's intended LoggerRepository -- they
still use the web app's log4j and its default LoggerRepository.
--
Jess Holle
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
>>> BTW, JBoss (supposedly, I didn't check personally) uses
>>> commons-logging everywhere, and the logging implementation used is
>>> log4j.
>>
>> That works since *everything* uses log4j. The issue is with Tomcat
>> is really one of *not* having log4j at the Tomcat level but having it
>> in your web app. This leads to:
>>
>> * whole crop of loggers using java.util.logging (fine, to be
>> expected, and there are Java 5 MBeans -- albeit limited -- to
>> interact with these)
>> * a few core Tomcat loggers that are *not* by nature per web app
>> loggers using the log4j jar and configuration of the first web app
>> that uses the class enclosing them (e.g. the first web app to get
>> a request!)
>> * the web app's own classes using whatever you specify
>>
>> It is the 2nd of these 3 bullet that is so disturbing to me. I'd
>> like to see these either have separate loggers for each web app, or
>> behave like the rest the Tomcat loggers and cause a leak of data and
>> references between web apps. This -- and a reasonable set of MBeans
>> to control/expose loggers seems quite doable with the approach Yoav
>> and Bill laid out. It's just unfortunate that the out-of-the-box
>> behavior with web apps using log4j is so onerous.
>
> The core loggers you talk about are probably the ones used for
> reporting your servlets/filters/etc loading errors. This seems webapp
> related to me.
Considering the classes containing these loggers are not per web app as
best I can tell I don't believe the loggers are, but I guess more
thorough debugging on my part is in order. Perhaps I am mistaken and
these are Tomcat loggers, but are specific to my web app.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> Remy Maucherat wrote:
>
>> Jess Holle wrote:
>>
>>> Why out of curiosity? I don't have a pro-UGLI ax to grind here, but
>>> Commons-Logging's behavior in Tomcat is really undesirable as is.
>>
>> It would be the same anyway: the loading configuration and the logger
>> instances will be tied to the webapp classloader. It has to work this
>> way. As I understand it, the thing that does not work for you right
>> now is that Tomcat uses your webapp's logger namespace before your
>> callbacks are called.
>
> Yes. The issue is really that Tomcat uses log4j out of my web app for
> loggers that are to be used outside my web app. Not only is the library
> used out of my web app but so is the configuration -- meaning web app A
> gets core Tomcat log output from web apps B and C...
>
> Yoav confirmed that the solution is to move log4j and a default
> configuration higher in the stack so that everything uses it. This
> together with a per-web-app ClassLoader (but not contextual
> classloader!) based LoggerRepository will ensure each web app gets its
> own loggers and configuration files and Tomcat core gets its own.
Yes, the logging namespaces need to be separate. I was faced with the
issue very recently when writing a log manager for java.util.logging
which would have a separate logger namespace for each classloader.
>>> Now if you're inside JBoss and it has pre-established log4j and
>>> configured it prior to Tomcat loading, then I don't see a problem
>>> with Commons Logging. Standalone Tomcat's Commons Logging behavior
>>> vis-a-vis log4j would seem to be an issue, though. The issues are
>>> especially bad and bizarre when log4j is used in a web app but Tomcat
>>> itself does not have log4j installed, but this is only part of the
>>> issue.
>>
>> I don't see any real difference. There should be plenty of container
>> listeners and stuff available to configure this.
>> (I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue
>> what it is)
>
> The nice thing about this as I understand it is that it would allow me
> to set up my own MBeans for a Tomcat-level / app-wide log4j
> LoggerRepository.
>
> You're right, though, as far as per-web-app MBeans and
> LoggerRepository's -- there are more than enough servlet listeners, etc,
> in the servlet spec to handle this.
>
>> BTW, JBoss (supposedly, I didn't check personally) uses
>> commons-logging everywhere, and the logging implementation used is log4j.
>
> That works since *everything* uses log4j. The issue is with Tomcat is
> really one of *not* having log4j at the Tomcat level but having it in
> your web app. This leads to:
>
> * whole crop of loggers using java.util.logging (fine, to be
> expected, and there are Java 5 MBeans -- albeit limited -- to
> interact with these)
> * a few core Tomcat loggers that are *not* by nature per web app
> loggers using the log4j jar and configuration of the first web app
> that uses the class enclosing them (e.g. the first web app to get
> a request!)
> * the web app's own classes using whatever you specify
>
> It is the 2nd of these 3 bullet that is so disturbing to me. I'd like
> to see these either have separate loggers for each web app, or behave
> like the rest the Tomcat loggers and cause a leak of data and references
> between web apps. This -- and a reasonable set of MBeans to
> control/expose loggers seems quite doable with the approach Yoav and
> Bill laid out. It's just unfortunate that the out-of-the-box behavior
> with web apps using log4j is so onerous.
The core loggers you talk about are probably the ones used for reporting
your servlets/filters/etc loading errors. This seems webapp related to me.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Jess Holle wrote:
>
>> Why out of curiosity? I don't have a pro-UGLI ax to grind here, but
>> Commons-Logging's behavior in Tomcat is really undesirable as is.
>
> It would be the same anyway: the loading configuration and the logger
> instances will be tied to the webapp classloader. It has to work this
> way. As I understand it, the thing that does not work for you right
> now is that Tomcat uses your webapp's logger namespace before your
> callbacks are called.
Yes. The issue is really that Tomcat uses log4j out of my web app for
loggers that are to be used outside my web app. Not only is the library
used out of my web app but so is the configuration -- meaning web app A
gets core Tomcat log output from web apps B and C...
Yoav confirmed that the solution is to move log4j and a default
configuration higher in the stack so that everything uses it. This
together with a per-web-app ClassLoader (but not contextual
classloader!) based LoggerRepository will ensure each web app gets its
own loggers and configuration files and Tomcat core gets its own.
>> Now if you're inside JBoss and it has pre-established log4j and
>> configured it prior to Tomcat loading, then I don't see a problem
>> with Commons Logging. Standalone Tomcat's Commons Logging behavior
>> vis-a-vis log4j would seem to be an issue, though. The issues are
>> especially bad and bizarre when log4j is used in a web app but Tomcat
>> itself does not have log4j installed, but this is only part of the
>> issue.
>
> I don't see any real difference. There should be plenty of container
> listeners and stuff available to configure this.
> (I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue
> what it is)
The nice thing about this as I understand it is that it would allow me
to set up my own MBeans for a Tomcat-level / app-wide log4j
LoggerRepository.
You're right, though, as far as per-web-app MBeans and
LoggerRepository's -- there are more than enough servlet listeners, etc,
in the servlet spec to handle this.
> BTW, JBoss (supposedly, I didn't check personally) uses
> commons-logging everywhere, and the logging implementation used is log4j.
That works since *everything* uses log4j. The issue is with Tomcat is
really one of *not* having log4j at the Tomcat level but having it in
your web app. This leads to:
* whole crop of loggers using java.util.logging (fine, to be
expected, and there are Java 5 MBeans -- albeit limited -- to
interact with these)
* a few core Tomcat loggers that are *not* by nature per web app
loggers using the log4j jar and configuration of the first web app
that uses the class enclosing them (e.g. the first web app to get
a request!)
* the web app's own classes using whatever you specify
It is the 2nd of these 3 bullet that is so disturbing to me. I'd like
to see these either have separate loggers for each web app, or behave
like the rest the Tomcat loggers and cause a leak of data and references
between web apps. This -- and a reasonable set of MBeans to
control/expose loggers seems quite doable with the approach Yoav and
Bill laid out. It's just unfortunate that the out-of-the-box behavior
with web apps using log4j is so onerous.
--
Jess Holle
Re: Web apps vs. Logging vs. Tomcat
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> Why out of curiosity? I don't have a pro-UGLI ax to grind here, but
> Commons-Logging's behavior in Tomcat is really undesirable as is.
It would be the same anyway: the loading configuration and the logger
instances will be tied to the webapp classloader. It has to work this
way. As I understand it, the thing that does not work for you right now
is that Tomcat uses your webapp's logger namespace before your callbacks
are called.
> Now if you're inside JBoss and it has pre-established log4j and
> configured it prior to Tomcat loading, then I don't see a problem with
> Commons Logging. Standalone Tomcat's Commons Logging behavior vis-a-vis
> log4j would seem to be an issue, though. The issues are especially bad
> and bizarre when log4j is used in a web app but Tomcat itself does not
> have log4j installed, but this is only part of the issue.
I don't see any real difference. There should be plenty of container
listeners and stuff available to configure this.
(I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue
what it is)
BTW, JBoss (supposedly, I didn't check personally) uses commons-logging
everywhere, and the logging implementation used is log4j.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Yoav Shapira wrote:
>
>> UGLI is far from mature enough to be used by Tomcat at this point. When
>> log4j 1.3 is out, we'll see.
>
> I already voted on that: -1.
Why out of curiosity? I don't have a pro-UGLI ax to grind here, but
Commons-Logging's behavior in Tomcat is really undesirable as is.
Now if you're inside JBoss and it has pre-established log4j and
configured it prior to Tomcat loading, then I don't see a problem with
Commons Logging. Standalone Tomcat's Commons Logging behavior vis-a-vis
log4j would seem to be an issue, though. The issues are especially bad
and bizarre when log4j is used in a web app but Tomcat itself does not
have log4j installed, but this is only part of the issue.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Web apps vs. Logging vs. Tomcat
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
> Yoav Shapira wrote:
> > UGLI is far from mature enough to be used by Tomcat at this point. When
> > log4j 1.3 is out, we'll see.
>
> I already voted on that: -1.
>
> Rémy
Yup, I know. I'm holding out for the possibility that UGLI will be a good
enough solution and a significant enough improvement of JCL to merit
re-consideration at some future time.
As I said, it's not something I'm pushing now, as the above is far (on the
time scale) from happening.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Remy Maucherat <re...@apache.org>.
Yoav Shapira wrote:
> UGLI is far from mature enough to be used by Tomcat at this point. When
> log4j 1.3 is out, we'll see.
I already voted on that: -1.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Web apps vs. Logging vs. Tomcat
Posted by Yoav Shapira <yo...@MIT.EDU>.
UGLI is far from mature enough to be used by Tomcat at this point. When
log4j 1.3 is out, we'll see.
Yoav
> -----Original Message-----
> From: Jess Holle [mailto:jessh@ptc.com]
> Sent: Thursday, March 17, 2005 4:17 PM
> To: Tomcat Developers List
> Subject: Re: Web apps vs. Logging vs. Tomcat
>
> P.S. Why does Tomcat use Commons Logging rather than UGLI?
>
> Jess Holle wrote:
>
> > I had e-mailed this to users mailing list, but I have what I believe
> > is a more "dev" follow-on question:
> >
> > Is there a good way to get my own start/stop action called at a
> > per-VM level?
> >
> > This is assuming I end up having to move log4j up into Tomcat's
> > classloaders -- at which point I'll want to install my
> > LoggerRepository controlling MBeans up at this level as well -- as
> > log4j's MBeans have issues and using log4j loggers means you don't
> > get the (admittedly sparse) java.util.logging MBean coverage.
> >
> > --
> > Jess Holle
> >
> > Jess Holle wrote:
> >
> >> I have been trying to get really serious about log4j in web apps.
> >>
> >> I note that Tomcat (thanks to commons-logging) uses java.util.logging
> >> *except* for loggers created while my web app's classloader is the
> >> current contextual classloader -- at which point it suddenly uses
> >> log4j (since my web app does) without giving my web app a chance to
> >> initialize it in any way as best I can tell.
> >>
> >> My web app has a ServletContextListener which initializes log4j by
> >> setting up its own LoggerRepository, configuration file and watcher
> >> (since log4j's won't shutdown), etc. Of course, every Tomcat logger
> >> created within my web app up until this point is now using log4j from
> >> my web app (!) and using the basic log4j.properties [if present] from
> >> my web app -- for loggers that apply to all web apps!
> >>
> >> How is one supposed to work this? I am currently using a static
> >> LoggerRepository reference within my web app so that a log4j loaded
> >> higher in the classloader tree won't cause LoggerRepository sharing.
> >> I was using a JNDI-based LoggerRepositorySelector as per log4j author
> >> recommendations, but this goes a step further than above -- it puts
> >> all the Tomcat loggers that are errantly using my log4j into my
> >> LoggerRepository -- which would be fine if these loggers were not
> >> shared with other web apps.
> >>
> >> What's the solution here? Do I have to put log4j into Tomcat's lib
> >> directories to force it to use its own centralized log4j? Is that
> >> the best solution?
> >>
> >> --
> >> Jess Holle
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
P.S. Why does Tomcat use Commons Logging rather than UGLI?
Jess Holle wrote:
> I had e-mailed this to users mailing list, but I have what I believe
> is a more "dev" follow-on question:
>
> Is there a good way to get my own start/stop action called at a
> per-VM level?
>
> This is assuming I end up having to move log4j up into Tomcat's
> classloaders -- at which point I'll want to install my
> LoggerRepository controlling MBeans up at this level as well -- as
> log4j's MBeans have issues and using log4j loggers means you don't
> get the (admittedly sparse) java.util.logging MBean coverage.
>
> --
> Jess Holle
>
> Jess Holle wrote:
>
>> I have been trying to get really serious about log4j in web apps.
>>
>> I note that Tomcat (thanks to commons-logging) uses java.util.logging
>> *except* for loggers created while my web app's classloader is the
>> current contextual classloader -- at which point it suddenly uses
>> log4j (since my web app does) without giving my web app a chance to
>> initialize it in any way as best I can tell.
>>
>> My web app has a ServletContextListener which initializes log4j by
>> setting up its own LoggerRepository, configuration file and watcher
>> (since log4j's won't shutdown), etc. Of course, every Tomcat logger
>> created within my web app up until this point is now using log4j from
>> my web app (!) and using the basic log4j.properties [if present] from
>> my web app -- for loggers that apply to all web apps!
>>
>> How is one supposed to work this? I am currently using a static
>> LoggerRepository reference within my web app so that a log4j loaded
>> higher in the classloader tree won't cause LoggerRepository sharing.
>> I was using a JNDI-based LoggerRepositorySelector as per log4j author
>> recommendations, but this goes a step further than above -- it puts
>> all the Tomcat loggers that are errantly using my log4j into my
>> LoggerRepository -- which would be fine if these loggers were not
>> shared with other web apps.
>>
>> What's the solution here? Do I have to put log4j into Tomcat's lib
>> directories to force it to use its own centralized log4j? Is that
>> the best solution?
>>
>> --
>> Jess Holle
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
I had e-mailed this to users mailing list, but I have what I believe is
a more "dev" follow-on question:
Is there a good way to get my own start/stop action called at a
per-VM level?
This is assuming I end up having to move log4j up into Tomcat's
classloaders -- at which point I'll want to install my
LoggerRepository controlling MBeans up at this level as well -- as
log4j's MBeans have issues and using log4j loggers means you don't
get the (admittedly sparse) java.util.logging MBean coverage.
--
Jess Holle
Jess Holle wrote:
> I have been trying to get really serious about log4j in web apps.
>
> I note that Tomcat (thanks to commons-logging) uses java.util.logging
> *except* for loggers created while my web app's classloader is the
> current contextual classloader -- at which point it suddenly uses
> log4j (since my web app does) without giving my web app a chance to
> initialize it in any way as best I can tell.
>
> My web app has a ServletContextListener which initializes log4j by
> setting up its own LoggerRepository, configuration file and watcher
> (since log4j's won't shutdown), etc. Of course, every Tomcat logger
> created within my web app up until this point is now using log4j from
> my web app (!) and using the basic log4j.properties [if present] from
> my web app -- for loggers that apply to all web apps!
>
> How is one supposed to work this? I am currently using a static
> LoggerRepository reference within my web app so that a log4j loaded
> higher in the classloader tree won't cause LoggerRepository sharing.
> I was using a JNDI-based LoggerRepositorySelector as per log4j author
> recommendations, but this goes a step further than above -- it puts
> all the Tomcat loggers that are errantly using my log4j into my
> LoggerRepository -- which would be fine if these loggers were not
> shared with other web apps.
>
> What's the solution here? Do I have to put log4j into Tomcat's lib
> directories to force it to use its own centralized log4j? Is that the
> best solution?
>
> --
> Jess Holle
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by Henri Gomez <he...@gmail.com>.
jk 1.2.9-dev build on iSeries without problem.
Wit my admins to redeploy and test it
On Thu, 17 Mar 2005 20:37:58 +0100, Mladen Turk <mt...@apache.org> wrote:
> Rainer Jung wrote:
> > Concerning socket_timeout:
> >
> > 1) In common/jk_connect.c there is a typo:
> >
> > 374 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
> > 375 (const void *) &tv, sizeof(tv));
> > 376 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
> > 377 (const void *) &tv, sizeof(tv));
> >
> > so both setsockopts use the same option. It should be SO_SNDTIMEO in line
> > 376. Maybe that's easy enough to change for 1.2.9.
> >
>
> Yes, it should be SO_SNDTIMEO. Seems like typo :).
>
>
> > 2) The test in configure about functionality of the timeouts is broken.
> > The test program does not compile under Solaris, because it needs
> > "-lsocket".
> >
>
> Can you provide a patch for that?
>
> >
> > When I compile the test program with "-lsocket" it compiles but it exits
> > as expected with "1". So under Solaris the two timeouts are defined in the
> > include files, but they do not work with setsockopt. Since this doesn't
> > change the result in the end, it might also be corrected after 1.2.9.
> >
>
> Sure, that's the purpose of JK_CHECK_SETSOCKOPT function.
>
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by Mladen Turk <mt...@apache.org>.
Rainer Jung wrote:
> Concerning socket_timeout:
>
> 1) In common/jk_connect.c there is a typo:
>
> 374 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
> 375 (const void *) &tv, sizeof(tv));
> 376 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
> 377 (const void *) &tv, sizeof(tv));
>
> so both setsockopts use the same option. It should be SO_SNDTIMEO in line
> 376. Maybe that's easy enough to change for 1.2.9.
>
Yes, it should be SO_SNDTIMEO. Seems like typo :).
> 2) The test in configure about functionality of the timeouts is broken.
> The test program does not compile under Solaris, because it needs
> "-lsocket".
>
Can you provide a patch for that?
>
> When I compile the test program with "-lsocket" it compiles but it exits
> as expected with "1". So under Solaris the two timeouts are defined in the
> include files, but they do not work with setsockopt. Since this doesn't
> change the result in the end, it might also be corrected after 1.2.9.
>
Sure, that's the purpose of JK_CHECK_SETSOCKOPT function.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by Rainer Jung <to...@kippdata.de>.
Concerning socket_timeout:
1) In common/jk_connect.c there is a typo:
374 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
375 (const void *) &tv, sizeof(tv));
376 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
377 (const void *) &tv, sizeof(tv));
so both setsockopts use the same option. It should be SO_SNDTIMEO in line
376. Maybe that's easy enough to change for 1.2.9.
2) The test in configure about functionality of the timeouts is broken.
The test program does not compile under Solaris, because it needs
"-lsocket".
Undefined first referenced
symbol in file
socket /var/tmp//ccKuhLE0.o
setsockopt /var/tmp//ccKuhLE0.o
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
configure:19481: $? = 1
configure: program exited with status 1
When I compile the test program with "-lsocket" it compiles but it exits
as expected with "1". So under Solaris the two timeouts are defined in the
include files, but they do not work with setsockopt. Since this doesn't
change the result in the end, it might also be corrected after 1.2.9.
3) in common/jk_connect.c in method jk_is_socket_connected the second
argument "timeout" is never used.
4) Still need to test functionality of socket_timeout under Solaris.
Regards,
Rainer
> Rainer Jung wrote:
>> Hi,
>>
>> I could help with Solaris info. If you tell me, what you are interested
>> in, I can do some tests.
>>
>
> Build, socket_timeout and JkShmFile.
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by Rainer Jung <to...@kippdata.de>.
Hi Mladen,
- Build for apache 1.3 OK (but see detailed comments).
- Running with apache 1.3 and JkShmFile: Looks OK
- jkstatus: Looks OK
- socket_timeout: Still needs to be tested (will try later)
- Logging shows mod_jk initialization two times! Once for a process A,
which does no longer exist after apache startup has finished, and a
second time the same lines for the usual parent process B. System call
trace shows, that A forks B and exits during startup. In my case, apache
is not run from the root account.
Anything else (apart from socket_timeout) I should test (test cases?)
Details:
Code from CVS HEAD today 17:00 CET.
Environment Solaris 8 UltraSparc, autoconf 2.59, automake 1.9, libtool
1.5, GNU m4 1.4.2, GNU make 3.80, gcc 3.2, Solaris ld 1.279.
CFLAGS set to "-O2", CC set to "gcc -specs=MY_SPECS_PATH/specs" and the
specs file differs from the standard one by:
51c51
< %{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc
-lgcc_eh}%{shared-libgcc:-lgcc_s%M -lgcc}}%{shared:-lgcc_s%M}}}
---
> %{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc
-lgcc_eh}%{shared-libgcc:-lgcc_s%M -lgcc}}}
This is to link statically against libgcc. Otherwise the runtime system
must have libgcc_s.so, which usually is not the case for Solaris systems.
buildconf.sh warns:
configure.in:59: warning: underquoted definition of JK_CHECK_SETSOCKOPT
run info '(automake)Extending aclocal'
or see
http://sources.redhat.com/automake/automake.html#Extending%20aclocal
configure.in: installing `scripts/build/unix/install-sh'
configure.in: installing `scripts/build/unix/missing'
The underquoted warning means, that future versions of automake might
require line 59 to include additional brackets:
AC_DEFUN([JK_CHECK_SETSOCKOPT], [
./configure --with-apxs=MY_APXS_PATH/apxs
Nothing special.
make: Warning:
libtool: install: warning: remember to run `libtool --finish SOME_PATH'
libtool: install: warning: remember to run `libtool --finish SOME_PATH'
but inspection of libtools show, that --finish would not do anything in
our case.
Copied apache-1.3/mod_jk.so.0.0.0 to libexec/mod_jk.so.
Configured apache:
LoadModule jk_module libexec/mod_jk.so
AddModule mod_jk.c
JkWorkersFile /SOME_PATH/conf/workers.properties
JkShmFile /SOME_PATH/logs/mod_jk.shm
JkLogFile /SOME_PATH/logs/mod_jk.log
JkLogLevel trace
...
# Inside virtual host
# Where to put jk logs
JkLogFile /SOME_PATH/logs/mod_jk_21000.log
JkLogLevel trace
JkMount /status status
JkMount /*.jsp balancer
Test:
lynx -cfg=/home/jung/lib/lynx.cfg http://localhost:21000/status
shows version 1.2.9 and detail info for load balancing worker and single
worker.
Regards,
Rainer
Mladen Turk wrote:
> Rainer Jung wrote:
>
>> Hi,
>>
>> I could help with Solaris info. If you tell me, what you are
>> interested in, I can do some tests.
>>
>
> Build, socket_timeout and JkShmFile.
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by Mladen Turk <mt...@apache.org>.
Rainer Jung wrote:
> Hi,
>
> I could help with Solaris info. If you tell me, what you are interested
> in, I can do some tests.
>
Build, socket_timeout and JkShmFile.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by Rainer Jung <to...@kippdata.de>.
Hi,
I could help with Solaris info. If you tell me, what you are interested
in, I can do some tests.
Regards,
Rainer
Mladen Turk wrote:
> Mark Thomas wrote:
>
>>
>> I suspect that most of them are invalid/already fixed bug would be
>> grateful if you could take a look.
>>
>
> Hi,
>
> Yes, most are fixed. Other I simply do not understand.
> I'll clean up fixed and invalid, and instruct the reporters
> to check beta version. Some problem like Solaris one are
> really hard to track down without a box :)
>
> Regards,
> Mladen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by Mladen Turk <mt...@apache.org>.
Mark Thomas wrote:
>
> I suspect that most of them are invalid/already fixed bug would be
> grateful if you could take a look.
>
Hi,
Yes, most are fixed. Other I simply do not understand.
I'll clean up fixed and invalid, and instruct the reporters
to check beta version. Some problem like Solaris one are
really hard to track down without a box :)
Regards,
Mladen
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tagging JK 1.2.9 on 3/17/2005
Posted by Mark Thomas <ma...@apache.org>.
Since you went through the previous set of JK bugs for TC4 a few more
have emerged. They are:
8541
15314
24628
29777
32519
32696
32998
33248
I suspect that most of them are invalid/already fixed bug would be
grateful if you could take a look.
Cheers,
Mark
Mladen Turk wrote:
> Hi all,
>
> My plan is to tag the JK_1_2_9_BETA on March 17th.
> The beta release will be available for testing from that date.
>
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org