You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by co...@covalent.net on 2002/07/25 19:15:19 UTC
[Logging] more issues with stack reading
Ok, back to the subject of extracting the method name from the
stack trace.
The problem is actually a bit more complicated and I think we're
doing the wrong thing at the moment, and all proposed solutions
are quite bad.
What we are trying to solve: display the method and classname that
makes the log call.
Log4j and jdk1.4 logging provide a config format to enable displaying this
- logkit doesn't seem to, so it's not a problem there ( since it couldn't
be displayed in the first place - if it does, same issue as in jdk1.4
apply )
Log4j has the best support for this - if you enable the display for
method and classname it'll generate a Throwable and walk the stack to
find the caller. It also have support for passing a Object which is
indicates the 'wrapper' - so if log4j is wrapped, we display the real
caller, not the wrapper.
JDK1.4 does almost the same thing - if called directly and if the
method display is configured, it'll walk the stack. It is also possible
to pass the class/method as String params ( as oposed to log4j
where you pass the Object wrapper ).
The problem in JDK1.4 is that there is no good way to deal with the
case when their logger is wrapped ( by commons-logging or by a tomcat
logger or any other method ). So we have to 'emulate' this and extract
the information from stack in the wrapper. We could ask the user
to pass this explicitely - but that's stupid, since the info is redundant
( we already _have_ it, in the stack ) and make the logger hard to use.
We solve the problem for commons-logging, but what if commons-logging
itself is wrapped ? Well, same solution as in log4j can be used here,
i.e. pass ( somehow ) information about the wrapper and skip it from
the stack walk.
However there are 2 huge problems:
1. Performance. Generating an exception and parsing the stack trace
is _extremely_ expensive. If you need the information - you'll have
to pay for it, but the problem is that you pay for it even if you
_don't_ use it.
2. Configuration. We either add explicit API to pass this info in each
Log method or we allow to configure it per LogFactory or once per Log
( i.e. a single method - generic or not - to configure it ).
What that means is that in order to avoid the performance when it is
not needed, we also need to request the logger to enable stack checking
in 1.4 ( again, log4j works without problems anyway ).
The solution of casting or constructing Jdk14Logger explicitely is
wrong - we loose the pluggability and discovery.
IMHO the only way to deal with that is to allow some form of
configuration ( hints ) that is generic to all loggers.
I'll ask for a vote - after I hear your comments. The hints
will be passed by whoever creates the Logger, and so far the
best solution seems to be setAttribute in Logger.
There is one alternative - that doesn't require API changes, and it
may be much better:
Require ( or recomend ? ) that each Log and LogFactory to support a form
of JMX.
That would mean that we'll be able to find if a Log or LogFactory support
configuration, pass configuration using a standard API, use the
existing JMX support in log4j, get the loggers to integrate nicely
in tomcat and apps that use JMX.
A static MBean would be the best choice for this case - as it
doesn't introduce _any_ dependency on JMX, it's just a programming
style where each LogFactory/Log impl would also implement an interface
with getters/setters. For log4j we could expose the 'real' MBean
of the Category, since it already exist and get access to all
the config capabilities.
Yet another alternative is to just use getter/setters and the
introspection-based dynamic MBean in tomcat-util ( which can be used
to transparently enable any bean as a JMX component - like 3.3
interceptors or jk handlers ).
I hope at least someone has read all this long message and will respond
:-)
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Logging] more issues with stack reading
Posted by Bob Herrmann <bo...@jadn.com>.
On Thu, 2002-07-25 at 13:15, costinm@covalent.net wrote:
> Ok, back to the subject of extracting the method name from the
> stack trace.
>
> The problem is actually a bit more complicated and I think we're
> doing the wrong thing at the moment, and all proposed solutions
> are quite bad.
>
> What we are trying to solve: display the method and classname that
> makes the log call.
>
> Log4j and jdk1.4 logging provide a config format to enable displaying this
> - logkit doesn't seem to, so it's not a problem there ( since it couldn't
> be displayed in the first place - if it does, same issue as in jdk1.4
> apply )
>
> Log4j has the best support for this - if you enable the display for
> method and classname it'll generate a Throwable and walk the stack to
> find the caller. It also have support for passing a Object which is
> indicates the 'wrapper' - so if log4j is wrapped, we display the real
> caller, not the wrapper.
>
> JDK1.4 does almost the same thing - if called directly and if the
> method display is configured, it'll walk the stack. It is also possible
> to pass the class/method as String params ( as oposed to log4j
> where you pass the Object wrapper ).
>
> The problem in JDK1.4 is that there is no good way to deal with the
> case when their logger is wrapped ( by commons-logging or by a tomcat
> logger or any other method ). So we have to 'emulate' this and extract
> the information from stack in the wrapper. We could ask the user
> to pass this explicitly - but that's stupid, since the info is redundant
> ( we already _have_ it, in the stack ) and make the logger hard to use.
yea, I imagine the explicit reference might be handy if you generate
java code from another source (like a JSP page.)
>
> We solve the problem for commons-logging, but what if commons-logging
> itself is wrapped ? Well, same solution as in log4j can be used here,
> i.e. pass ( somehow ) information about the wrapper and skip it from
> the stack walk.
>
> However there are 2 huge problems:
>
> 1. Performance. Generating an exception and parsing the stack trace
> is _extremely_ expensive. If you need the information - you'll have
> to pay for it, but the problem is that you pay for it even if you
> _don't_ use it.
Yea, definitely need to be able to switch stack walking on/off.
> 2. Configuration. We either add explicit API to pass this info in each
> Log method or we allow to configure it per LogFactory or once per Log
> ( i.e. a single method - generic or not - to configure it ).
>
> What that means is that in order to avoid the performance when it is
> not needed, we also need to request the logger to enable stack checking
> in 1.4 ( again, log4j works without problems anyway ).
>
> The solution of casting or constructing Jdk14Logger explicitely is
> wrong - we loose the pluggability and discovery.
>
> IMHO the only way to deal with that is to allow some form of
> configuration ( hints ) that is generic to all loggers.
>
> I'll ask for a vote - after I hear your comments. The hints
> will be passed by whoever creates the Logger, and so far the
> best solution seems to be setAttribute in Logger.
Hopefully the hint will enable a commons-log user to supply a "Stack
Trace method extraction Strategy" (to make me happy anyway.)
> There is one alternative - that doesn't require API changes, and it
> may be much better:
>
> Require ( or recomend ? ) that each Log and LogFactory to support a form
> of JMX.
>
> That would mean that we'll be able to find if a Log or LogFactory support
> configuration, pass configuration using a standard API, use the
> existing JMX support in log4j, get the loggers to integrate nicely
> in tomcat and apps that use JMX.
>
> A static MBean would be the best choice for this case - as it
> doesn't introduce _any_ dependency on JMX, it's just a programming
> style where each LogFactory/Log impl would also implement an interface
> with getters/setters. For log4j we could expose the 'real' MBean
> of the Category, since it already exist and get access to all
> the config capabilities.
>
> Yet another alternative is to just use getter/setters and the
> introspection-based dynamic MBean in tomcat-util ( which can be used
> to transparently enable any bean as a JMX component - like 3.3
> interceptors or jk handlers ).
So commons-logging would expose a JMX version of a logger which my code
can probe, and configure it to use a "Stack Trace classname methodname
extraction Strategy" of my choice (if the exposed logger supported the
ability.) Sounds workable.
>
> I hope at least someone has read all this long message and will respond
> :-)
I read it. :)
Cheers
-bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Logging] more issues with stack reading
Posted by Bob Herrmann <bo...@jadn.com>.
On Thu, 2002-07-25 at 13:15, costinm@covalent.net wrote:
> Ok, back to the subject of extracting the method name from the
> stack trace.
>
> The problem is actually a bit more complicated and I think we're
> doing the wrong thing at the moment, and all proposed solutions
> are quite bad.
>
> What we are trying to solve: display the method and classname that
> makes the log call.
>
> Log4j and jdk1.4 logging provide a config format to enable displaying this
> - logkit doesn't seem to, so it's not a problem there ( since it couldn't
> be displayed in the first place - if it does, same issue as in jdk1.4
> apply )
>
> Log4j has the best support for this - if you enable the display for
> method and classname it'll generate a Throwable and walk the stack to
> find the caller. It also have support for passing a Object which is
> indicates the 'wrapper' - so if log4j is wrapped, we display the real
> caller, not the wrapper.
>
> JDK1.4 does almost the same thing - if called directly and if the
> method display is configured, it'll walk the stack. It is also possible
> to pass the class/method as String params ( as oposed to log4j
> where you pass the Object wrapper ).
>
> The problem in JDK1.4 is that there is no good way to deal with the
> case when their logger is wrapped ( by commons-logging or by a tomcat
> logger or any other method ). So we have to 'emulate' this and extract
> the information from stack in the wrapper. We could ask the user
> to pass this explicitly - but that's stupid, since the info is redundant
> ( we already _have_ it, in the stack ) and make the logger hard to use.
yea, I imagine the explicit reference might be handy if you generate
java code from another source (like a JSP page.)
>
> We solve the problem for commons-logging, but what if commons-logging
> itself is wrapped ? Well, same solution as in log4j can be used here,
> i.e. pass ( somehow ) information about the wrapper and skip it from
> the stack walk.
>
> However there are 2 huge problems:
>
> 1. Performance. Generating an exception and parsing the stack trace
> is _extremely_ expensive. If you need the information - you'll have
> to pay for it, but the problem is that you pay for it even if you
> _don't_ use it.
Yea, definitely need to be able to switch stack walking on/off.
> 2. Configuration. We either add explicit API to pass this info in each
> Log method or we allow to configure it per LogFactory or once per Log
> ( i.e. a single method - generic or not - to configure it ).
>
> What that means is that in order to avoid the performance when it is
> not needed, we also need to request the logger to enable stack checking
> in 1.4 ( again, log4j works without problems anyway ).
>
> The solution of casting or constructing Jdk14Logger explicitely is
> wrong - we loose the pluggability and discovery.
>
> IMHO the only way to deal with that is to allow some form of
> configuration ( hints ) that is generic to all loggers.
>
> I'll ask for a vote - after I hear your comments. The hints
> will be passed by whoever creates the Logger, and so far the
> best solution seems to be setAttribute in Logger.
Hopefully the hint will enable a commons-log user to supply a "Stack
Trace method extraction Strategy" (to make me happy anyway.)
> There is one alternative - that doesn't require API changes, and it
> may be much better:
>
> Require ( or recomend ? ) that each Log and LogFactory to support a form
> of JMX.
>
> That would mean that we'll be able to find if a Log or LogFactory support
> configuration, pass configuration using a standard API, use the
> existing JMX support in log4j, get the loggers to integrate nicely
> in tomcat and apps that use JMX.
>
> A static MBean would be the best choice for this case - as it
> doesn't introduce _any_ dependency on JMX, it's just a programming
> style where each LogFactory/Log impl would also implement an interface
> with getters/setters. For log4j we could expose the 'real' MBean
> of the Category, since it already exist and get access to all
> the config capabilities.
>
> Yet another alternative is to just use getter/setters and the
> introspection-based dynamic MBean in tomcat-util ( which can be used
> to transparently enable any bean as a JMX component - like 3.3
> interceptors or jk handlers ).
So commons-logging would expose a JMX version of a logger which my code
can probe, and configure it to use a "Stack Trace classname methodname
extraction Strategy" of my choice (if the exposed logger supported the
ability.) Sounds workable.
>
> I hope at least someone has read all this long message and will respond
> :-)
I read it. :)
Cheers
-bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Logging] more issues with stack reading
Posted by Bob Herrmann <bo...@jadn.com>.
On Thu, 2002-07-25 at 14:44, Bob Herrmann wrote:
> On Thu, 2002-07-25 at 14:16, Patrick Luby wrote:
> > Costin and Bob,
> >
> > costinm@covalent.net wrote:
> > >
> > > The problem we're having is support for the old wrappers in
> > > tomcat, as we need to filter them out too. We're trying to
> > > get commons-logging used everywhere, but keep backward
> > > compatibility since the Logger/Log interface is part of the
> > > tomcat APIs.
> > >
> >
> > I may be missing something, but would a possible approach be to change
> > all of the Logger/Log interface calls to commons-logging in the new
> > version of Tomcat (i.e. jakarta-tomcat-5). Since this is a very new
> > workspace, it seems the safest place to make the switch (messing with
> > Tomcat 4.x seems too risky to me). This would eliminate the need to put
> > in a Tomcat-specific class into commons-logging.
> >
> > What do you think?
>
> $ cd jakarta-tomcat-4.0
> $ grep -i -l 'void.*log(' `find . -name *.java`|wc -l
> 65
>
> Looks like 65 classes need to be beaten into using commons-logging. I
> will take a stab at this and see if it is simply cut/past/click/drag or
> if other nasty issues start popping up. Learn by doing, yippie. :-)
I have learned that, IMHO, Tomcat does a pretty decent job with logging
all on it's own.
Where the "issue" arises is getting Tomcat to use commons-logging. The
only "issue" is correctly unrolling the stack. (Namely that a wrapper
class is being used.)
A simple change to commons-logging is to pass it a hint, (per costin)
factory=LogFactory.getFactory();
factory.setAttribute( "commons-logging.wrapperClass",
"[CLASSNAME-OF-WRAPPER]");
factory.getLog().info("Hi mom");
This hint could be used by both the Log4j and Jdk1.4 loggers to provide
better class name and method name information to the log.
I think this small change makes commons-logger a better fit for Tomcat.
And probably for many projects.
Cheers,
-bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Logging] more issues with stack reading
Posted by Bob Herrmann <bo...@jadn.com>.
On Thu, 2002-07-25 at 14:16, Patrick Luby wrote:
> Costin and Bob,
>
> costinm@covalent.net wrote:
> >
> > The problem we're having is support for the old wrappers in
> > tomcat, as we need to filter them out too. We're trying to
> > get commons-logging used everywhere, but keep backward
> > compatibility since the Logger/Log interface is part of the
> > tomcat APIs.
> >
>
> I may be missing something, but would a possible approach be to change
> all of the Logger/Log interface calls to commons-logging in the new
> version of Tomcat (i.e. jakarta-tomcat-5). Since this is a very new
> workspace, it seems the safest place to make the switch (messing with
> Tomcat 4.x seems too risky to me). This would eliminate the need to put
> in a Tomcat-specific class into commons-logging.
>
> What do you think?
$ cd jakarta-tomcat-4.0
$ grep -i -l 'void.*log(' `find . -name *.java`|wc -l
65
Looks like 65 classes need to be beaten into using commons-logging. I
will take a stab at this and see if it is simply cut/past/click/drag or
if other nasty issues start popping up. Learn by doing, yippie. :-)
Cheers,
-bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Logging] more issues with stack reading
Posted by Patrick Luby <pa...@sun.com>.
Costin and Bob,
costinm@covalent.net wrote:
>
> The problem we're having is support for the old wrappers in
> tomcat, as we need to filter them out too. We're trying to
> get commons-logging used everywhere, but keep backward
> compatibility since the Logger/Log interface is part of the
> tomcat APIs.
>
I may be missing something, but would a possible approach be to change
all of the Logger/Log interface calls to commons-logging in the new
version of Tomcat (i.e. jakarta-tomcat-5). Since this is a very new
workspace, it seems the safest place to make the switch (messing with
Tomcat 4.x seems too risky to me). This would eliminate the need to put
in a Tomcat-specific class into commons-logging.
What do you think?
Patrick
--
________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Logging] more issues with stack reading
Posted by co...@covalent.net.
On Thu, 25 Jul 2002, Berin Loritsch wrote:
> > Of course Tomcat exposes API - it is intended for people
> > extending tomcat. Realms, loggers, valves, etc. And also the
> > embeding API used by all who include tomcat in their products.
>
> I learned something new today. :)
I would have assumed that anyone using tomcat noticed the server.xml
and all the 'Interceptor' 'Realm', 'Listener', Logger, etc.
Each corresponds to an interface - which has been frozen and
stable since 3.3 and 4.0 were released ( in reasonable limits,
of course :-). The plan for 5.0 is to continue the support
for the existing interfaces that we expose.
> Java Management eXtensions designed purpose is to expose management
> functionality for servers. The fact that it can be used for
> configuration is either a side benefit, or a bastardization of the
> spec--depending on your view (I know people on both sides of the
> coin, and I have no opinion yet).
I don't think 'for servers' is included in the spec. Its purpose
AFAIK is to standardise the management of java applications
( just like SNMP can be used for arbitrary applications - from
routers to databases ).
'Configuration' ( and runtime configuration ) is the core piece of
'management'.
> If a function is available via the wrapper, it should be available
> to all wrappers. That means the user will view it as being Commons
> Logging.
If the Logger exposes a JMX view - the user will view all the capabilities
of the specific logger implementation.
Think of a Realm - while all authenticators share the same interface,
a database realm will have a quite different set of attributes
to configure than a text realm.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Logging] more issues with stack reading
Posted by Berin Loritsch <bl...@apache.org>.
> From: costinm@covalent.net [mailto:costinm@covalent.net]
>
> On Thu, 25 Jul 2002, Berin Loritsch wrote:
>
> > Does Tomcat expose its API beyond the Servlet spec? IOW,
> is it common
> > to have direct plugins to Tomcat that are specific to Tomcat?
> >
> > If Tomcat is not meant to be used that way, you have the ability to
> > upgrade the logger in one massive sweep and be done with it.
> >
> > I wasn't aware of a real Tomcat Platform.
>
> Of course Tomcat exposes API - it is intended for people
> extending tomcat. Realms, loggers, valves, etc. And also the
> embeding API used by all who include tomcat in their products.
I learned something new today. :)
> And so far it seems extremely common to embed tomcat and to
> integrate it with other applications.
>
> We can upgrade the logger, but preserving backward
> compatibility for the APIs we expose is something very
> serious for us.
Obviously. Since I learned today that Tomcat is more than a
Servlet Container, that makes perfect sense.
> I don't know what 'Platform' means - I heard about
> "Java Platform" but I never understood what it actually means :-)
A Platform is a baseline that you can base other applications
on. The Java Platform is the baseline: the JVM, the APIs, the
language itself, the compiler, etc.
There are more specific platforms that can be built on top of
the Java Platform like J2EE, Avalon, and Tomcat.
> > For something like Tomcat where it *is* the application,
> and does not
> > provide any exposed framework, I don't see where that need
> has to be
> > enforced. IOW it is probably easier to just go through and
> change the
> > logger wrapper.
>
> Tomcat does expose a lot of APIs - and breaking backward compat
> is not an option.
Agreed.
> > > We could leave the old interfaces use their own file-based
> > > logging, but that wouldn't be very nice.
> >
> > How many third or second party plugins exist for Tomcat?
>
> Quite a few, I don't know the exact number. There are also
> many products embeding tomcat.
Ok. I was just fishing to see what the level of impact would be
for such a change.
> > > The JMX solution can avoid adding the configuration features
> > > into the loggers and keep the API simpler ( but it may make
> > > the implementation a bit more complex - but not very much )
> >
> >
> > The problem is where does it stop? If you start down the road of
> > configuring the underlying logging API, other users will start in
> > with, "Yeah that's nice, but wouldn't it be great if... ...and it
> > won't be that much more complex...."
>
> JMX is the API for configuration, and at least log4j already
> supports it.
Java Management eXtensions designed purpose is to expose management
functionality for servers. The fact that it can be used for
configuration is either a side benefit, or a bastardization of the
spec--depending on your view (I know people on both sides of the
coin, and I have no opinion yet).
To be honest, I have to learn JMX pretty soon (like within the next
two months). I will have an informed opinion after that.
> We just say that the configuration is not covered by
> commons-logging in
> any way, but by individual loggers ( or wrappers ).
>
> Whatever is supported by the logger ( directly or via wrapper )
> will be available to the user.
If a function is available via the wrapper, it should be available
to all wrappers. That means the user will view it as being Commons
Logging.
I do agree that the underlying configuration should be done by
the logging tool used--not by Commons Logging. My warnings reflect
personal experience.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Logging] more issues with stack reading
Posted by co...@covalent.net.
On Thu, 25 Jul 2002, Berin Loritsch wrote:
> > That's what we're using for the JDK1.4 logger ( where
> > obviously JDK1.4 is required anyway ).
>
>
> It can also be used for the other wrappers as well--if we are running
> on JDK 1.4.
For log4j - we don't need to, since log4j deals with it very well.
They should use it internally - but as long as this is done only
on demand ( if you enable display of the method name ) - it
is not that critical.
For logkit - I have no idea if it is even possible to pass this
information, the API doesn't seem to expose it.
> Does Tomcat expose its API beyond the Servlet spec? IOW, is
> it common to have direct plugins to Tomcat that are specific
> to Tomcat?
>
> If Tomcat is not meant to be used that way, you have the
> ability to upgrade the logger in one massive sweep and be
> done with it.
>
> I wasn't aware of a real Tomcat Platform.
Of course Tomcat exposes API - it is intended for people extending
tomcat. Realms, loggers, valves, etc. And also the embeding API
used by all who include tomcat in their products.
And so far it seems extremely common to embed tomcat and to
integrate it with other applications.
We can upgrade the logger, but preserving backward compatibility
for the APIs we expose is something very serious for us.
I don't know what 'Platform' means - I heard about
"Java Platform" but I never understood what it actually means :-)
> For something like Tomcat where it *is* the application, and
> does not provide any exposed framework, I don't see where that
> need has to be enforced. IOW it is probably easier to just
> go through and change the logger wrapper.
Tomcat does expose a lot of APIs - and breaking backward compat
is not an option.
> > We could leave the old interfaces use their own file-based
> > logging, but that wouldn't be very nice.
>
> How many third or second party plugins exist for Tomcat?
Quite a few, I don't know the exact number. There are also many products
embeding tomcat.
> > The JMX solution can avoid adding the configuration features
> > into the loggers and keep the API simpler ( but it may make
> > the implementation a bit more complex - but not very much )
>
>
> The problem is where does it stop? If you start down the road
> of configuring the underlying logging API, other users will start
> in with, "Yeah that's nice, but wouldn't it be great if...
> ...and it won't be that much more complex...."
JMX is the API for configuration, and at least log4j already
supports it.
We just say that the configuration is not covered by commons-logging in
any way, but by individual loggers ( or wrappers ).
Whatever is supported by the logger ( directly or via wrapper )
will be available to the user.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Logging] more issues with stack reading
Posted by Berin Loritsch <bl...@apache.org>.
> From: costinm@covalent.net [mailto:costinm@covalent.net]
>
> On Thu, 25 Jul 2002, Berin Loritsch wrote:
>
> > Keep in mind that JDK 1.4 has some improvements in this
> area, allowing
> > you to iterate more easily through the stack trace. It could be a
> > feature that is enabled by the JDK you are using.
>
> That's what we're using for the JDK1.4 logger ( where
> obviously JDK1.4 is required anyway ).
It can also be used for the other wrappers as well--if we are running
on JDK 1.4.
> The problem we're having is support for the old wrappers in
> tomcat, as we need to filter them out too. We're trying to
> get commons-logging used everywhere, but keep backward
> compatibility since the Logger/Log interface is part of the
> tomcat APIs.
Question:
Does Tomcat expose its API beyond the Servlet spec? IOW, is
it common to have direct plugins to Tomcat that are specific
to Tomcat?
If Tomcat is not meant to be used that way, you have the
ability to upgrade the logger in one massive sweep and be
done with it.
I wasn't aware of a real Tomcat Platform.
> > LogKit also allows displaying this information.
>
> I couldn't find this info - in any case the API doesn't seem
> to allow passing the 'wrapper' class, nor the
> classname/methodname, so it may be more difficult than for JDK1.4.
You are correct about the 'wrapper' class, but it can and does
print the current thread, and the calling class. It might control
the wrapper class issue by just a number of stack trace entries.
It also might be that we never got around to making that part
work yet.
> > If a logging wrapper is wrapped, then there is a real
> design problem.
>
> :-)
>
> I don't see any other solution - we can't abandon the old
> wrapper interface for backward compatibility, and we want
> to migrate to commons-logging.
For something like Tomcat where it *is* the application, and
does not provide any exposed framework, I don't see where that
need has to be enforced. IOW it is probably easier to just
go through and change the logger wrapper.
> We could leave the old interfaces use their own file-based
> logging, but that wouldn't be very nice.
How many third or second party plugins exist for Tomcat?
> > The whole discovery/pluggability framework is what you are
> now finding
> > you need to support now. Too much automagic stuff, and you
> will find
> > even more places where something as simple as logging will fail.
> > There comes a point where it is just easier to commit to one
> > particular logger.
>
> I believe it's better to have the choice of multiple logger
> implementations, and commit to one particular logger API.
Yep, and there are a couple of APIs that do that much.
> As for discovery/pluggability - it is allways possible to
> explicitely select an implementation, and we're using a very
> basic and clear standard ( the META-INF/services ).
I understand. I just come from a different mindset, and am
naturally distrusting of discovery/pluggability. Granted,
I am also an outsider so to speak.
> The JMX solution can avoid adding the configuration features
> into the loggers and keep the API simpler ( but it may make
> the implementation a bit more complex - but not very much )
The problem is where does it stop? If you start down the road
of configuring the underlying logging API, other users will start
in with, "Yeah that's nice, but wouldn't it be great if...
...and it won't be that much more complex...."
Before you even consider going down that path, you need to
draw a very clear line in the sand and explain exactly why
you won't consider anything more than the wrapper layer issues.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Logging] more issues with stack reading
Posted by co...@covalent.net.
On Thu, 25 Jul 2002, Berin Loritsch wrote:
> Keep in mind that JDK 1.4 has some improvements in this area,
> allowing you to iterate more easily through the stack trace.
> It could be a feature that is enabled by the JDK you are using.
That's what we're using for the JDK1.4 logger ( where obviously
JDK1.4 is required anyway ).
> > What we are trying to solve: display the method and classname
> > that makes the log call.
>
> The problem is due to the additional layer of the wrapper class.
> You need to work with the back end logging systems to come up with
> a proper solution. What calls the backend logger is not the line
> of code but the wrapper class.
The current code deals with commons-logging wrapping log4j or
jdk1.4, and displays the correct method ( by walking the stack ).
The problem we're having is support for the old wrappers in
tomcat, as we need to filter them out too. We're trying to
get commons-logging used everywhere, but keep backward
compatibility since the Logger/Log interface is part of the
tomcat APIs.
> LogKit also allows displaying this information.
I couldn't find this info - in any case the API doesn't seem to
allow passing the 'wrapper' class, nor the classname/methodname,
so it may be more difficult than for JDK1.4.
> If a logging wrapper is wrapped, then there is a real design
> problem.
:-)
I don't see any other solution - we can't abandon the old
wrapper interface for backward compatibility, and we want
to migrate to commons-logging.
We could leave the old interfaces use their own file-based
logging, but that wouldn't be very nice.
> The whole discovery/pluggability framework is what you are now
> finding you need to support now. Too much automagic stuff, and
> you will find even more places where something as simple as logging
> will fail. There comes a point where it is just easier to commit
> to one particular logger.
I believe it's better to have the choice of multiple logger
implementations, and commit to one particular logger API.
As for discovery/pluggability - it is allways possible to
explicitely select an implementation, and we're using a very
basic and clear standard ( the META-INF/services ).
> > IMHO the only way to deal with that is to allow some form of
> > configuration ( hints ) that is generic to all loggers.
>
> All I can say is beware of feature creep. By adding in more
> things into your logging framework, you raise the bar to add in
> yet another logging backend.
I agree - featurism is the worse thing that can happen to
an API.
The JMX solution can avoid adding the configuration features
into the loggers and keep the API simpler ( but it may make the
implementation a bit more complex - but not very much )
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Logging] more issues with stack reading
Posted by Berin Loritsch <bl...@apache.org>.
Keep in mind that JDK 1.4 has some improvements in this area,
allowing you to iterate more easily through the stack trace.
It could be a feature that is enabled by the JDK you are using.
You can detect the JDK at runtime by checking if the
java.sql.SavePoint class or the java.lang.CharSequence interface
exists. If so, then we can do this:
StackTraceElement[] trace = throwable.getStackTrace();
That will allow us to iterate neatly through the stacktrace and
make it work for us. Also, there is the ability to set the
stack trace (i.e. for those more advanced cases where you need
to override the stack trace information).
Relying on strings alone is quite problematic.
> From: costinm@covalent.net [mailto:costinm@covalent.net]
>
> Ok, back to the subject of extracting the method name from the
> stack trace.
>
> The problem is actually a bit more complicated and I think
> we're doing the wrong thing at the moment, and all proposed
> solutions are quite bad.
>
> What we are trying to solve: display the method and classname
> that makes the log call.
The problem is due to the additional layer of the wrapper class.
You need to work with the back end logging systems to come up with
a proper solution. What calls the backend logger is not the line
of code but the wrapper class.
> Log4j and jdk1.4 logging provide a config format to enable
> displaying this
> - logkit doesn't seem to, so it's not a problem there ( since
> it couldn't be displayed in the first place - if it does,
> same issue as in jdk1.4
> apply )
LogKit also allows displaying this information.
> We solve the problem for commons-logging, but what if
> commons-logging itself is wrapped ? Well, same solution as in
> log4j can be used here,
> i.e. pass ( somehow ) information about the wrapper and skip
> it from the stack walk.
If a logging wrapper is wrapped, then there is a real design
problem.
> However there are 2 huge problems:
>
> 1. Performance. Generating an exception and parsing the stack
> trace is _extremely_ expensive. If you need the information -
> you'll have
> to pay for it, but the problem is that you pay for it even if
> you _don't_ use it.
It gets better in JDK 1.4 as a platform. However the point is
taken.
> 2. Configuration. We either add explicit API to pass this
> info in each Log method or we allow to configure it per
> LogFactory or once per Log ( i.e. a single method - generic
> or not - to configure it ).
>
> What that means is that in order to avoid the performance
> when it is not needed, we also need to request the logger to
> enable stack checking in 1.4 ( again, log4j works without
> problems anyway ).
>
> The solution of casting or constructing Jdk14Logger explicitely is
> wrong - we loose the pluggability and discovery.
The whole discovery/pluggability framework is what you are now
finding you need to support now. Too much automagic stuff, and
you will find even more places where something as simple as logging
will fail. There comes a point where it is just easier to commit
to one particular logger.
> IMHO the only way to deal with that is to allow some form of
> configuration ( hints ) that is generic to all loggers.
All I can say is beware of feature creep. By adding in more
things into your logging framework, you raise the bar to add in
yet another logging backend.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>