On Mon, 4 Feb 2002, Steve Downey wrote:
> > The case: you have 2 apps you want to keep isolated. Allowing one to
> > log into the other's log is unacceptable. Classloader tricks are not
> > allways possible and are extremely error prone ( and I would say -
> > ineffective, can be tricked ). And the security manager is not
> > something most people understand.
> >
> > We should at minimum require that getInstance( name ) would get
> > you a logger _local_ to your app, if in a container env.
> > ( impl: use thread class loader, or the class loader as a
> > namespace qualifier ).
> >
>
> That's got to be the business of the logging package, and commons-logging is
> not a logging package, it's an interface to logging packages.
> Commons-logging shouldn't make any claims or guarantees about what the
> logging package does.
common-logging is an API for logging. It will have multiple
implementations, like log4j, jdk1.4, etc. The way the API is defined
is important. If we say: getInstance() should return the logger
with this name, the impl. should do exactly that.
If we say getInstance() should return a logger with this name,
but local to the application env ( if running in a multi-app env
like container, applet, etc ) - the the logger impl and adapter
should do exactly that. It will have to do it by using some
hidden info to distinguish between apps - like thread class loader.
If we pass a second param that will be used as a 'guard' to
distingusish apps, then the impl. can make an explicit selection,
and we'll have more flexibility ( like sharing loggers between
apps, as long as they share a referenec to a guard object ).
The impl is allways constrained by the API, and the way we define
the API now ( which seems to be the first case ) is not secure in
container env.
> > What does it gives you ? Most cases will use delegation anyway.
> >
> > Having it as an abstract method, with a static getLog() method
> > will make the user interact with a single class - Log - instead
> > of 2. The LogManager/LogFactory will do the work 'behind the scene'.
> >
> > Nothing else change in the code ( except replacing implements with
> > extends ). Except maybe simplifying some adapters by keeping
> > common stuff in the base class.
> >
>
> The advantage of interfaces over abstract classes in Java is that interfaces
> may be multiply inherited from. This doesn't seem to be an issue here. I
> don't see any XLogImpl classes that need to mix in the commons logging
> interface. The downside is that the static will have to have an
> implementation. If that forwards to LogSource (LogManager?), it does reduce
> the surface complexity of commons logging a bit. Most components will not
> need LogSource at all.
Exactly. And LogManager will no longer need static methods.
Some people believe that using interfaces is the only way to do
'real' OO software. I think it's the API that matters, and abstract
base classes ( or plain classes ) are more likely to make code
simpler and cleaner in most cases.
Having FooInterface, BaseFoo, MyFoo just adds more files the user
will have to navigate through - and not add too much value compared
with just having a Foo and extending it if you ever want to alter
the behavior. In almost all 'interface' based designs I've seen
you end up with most interfaces having a BaseFoo and I don't
think I've seen many cases where the interface was used ( all
classes will eventually extend BaseFoo ) for the simple reason
that too many methods need to be implemented and a lot of
hidden behavior will get into the base class.
> I think that log(int level,...) is a bad idea. Where do those ints come
> from? If they are the levels defined by the logging package (ie logkit,
> log4j, jdk, ...) then components can NOT use them. Not without having random
> behavior when packages are changed. If they are constants that are defined
> by the commons logging package, you've just added a new mapping problem. Or
> it's just a switch statement that dispatches to {trace(), debug(), info(),
> ...}, which doesn't seem to add anything.
It can be an Object as well, or Comparable.
> > Otherwise we'll still have to code against Log4j APIs ( to set the
> > config file for example ) - and what's the point of using
> > commons logging
> > if we already require and hardcode log4j ?
> >
>
> commons-X will not require or hardcode log4j or logkit. Application Z, that
> uses commons-X will require or hardcode log4j or logkit or something else.
>
> Will Tomcat hardcode or require some logging package? Possibly. That's up to
> Tomcat. But, SO WHAT? It's not as though that will be exposed to webapps
> running within Tomcat. It's Tomcat's business how log information is
> produced. So long as log information IS produced. Does anyone care what
> syslog package httpd uses?
So commons-logging should be used only by commons components ?
Having a setAttribute()/getAttribute() mechanism can't hurt anyone. Take a
look at SAX/Jaxp - what you are saying is that SAX users should hardcode
calls to Xerces/Crimson/etc to set the sax features.
I don't see a difference between SAX and logging - both are APIs that
hide real implementations. If you require the user to allways use the
real impl., there's little value in the API.
Costin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
