commons-dev mailing list archives

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


Mime
View raw message