RE: cvs commit:jakarta-commons/logging/src/java/org/apache/common s/logging/implLogFactoryImpl.java

[co...@covalent.net]

On Wed, 13 Feb 2002, Steve Downey wrote:

> What I can't imagine is a component that knows about multiple logging
> hierarchies. That smells an awful lot like the business of the application,
> not the component. What it comes down to, is, what can a Digester pass into
> the LogFactory.getInstance call to specify a domain or guard? 

Nothing, most of the times. Each application can have it's own favorite
logger ( in lib ), and it'll be automatically picked up and used.

However in some cases the container may want to provide a 'default'
logger - maybe you are in a sandbox and the webapp is not allowed
to create files or initiate net connections, while the logger
 provided by container has the permissions ( and uses 'doPriviledged').
In this case the app has no rights and any attempt to configure a logger
will probably fail. 

A third case is when you have a set of webapps and you want to share the
same logger. The default should definitely be 'don't allow application
1 to get the same logger as application 2, even if they use the same 
name', so loggers must be qualified by a domain. If you want to use
 a common logger, you'll need API support.


> What would make sense, is for Digester to have a setLogFactory() method. The
> custom factory would be responsible for setting up the log in the correct,
> customer defined, hierarchy.
> 
> Any logging during construction would have to go to the system default
> logger. Whatever that is. 

Not if you want the components to be useable in a secure ( sandboxed ) 
environment. 

Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>