commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject RE: [Logging] more issues with stack reading
Date Thu, 25 Jul 2002 18:47:55 GMT
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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message