On Sat, 2 Feb 2002, Steve Downey wrote:
> > - security: getLogNames() and getInstance() are evil and unacceptable.
> > Both log4j and logkit have solutions that allow safe use in a
> >
> Could you elaborate on getInstance()? If the underlying logging packages
First, is the combination of getLogNames() and getInstance() - any user of
the logger will be able to see all the logs and will be able to log to
every log ( some may be potentially used by other users of the logger).
I'm thinking in terms of 'complex' applications, like a container.
Relying on ClassLoader is not enough to protect, and it'll become almost
impossible if common-logging is successfull and get used in all
components.
Even without getLogNames(), an app can guess the log name used by other
app, or you may have conflicts.
One solution is to 'define' that getLogNames() and getInstance() should
return an instance that is local to the app - but then you may need to
pass a param ( like a 'guard' ) that is specific to the app or just rely
on the thread class loader ( but that's not the most generic solution ).
I'm not saying it's imposible to fix - but the current code doesn't seem
like providing the required protection.
> > - It's missing a log() method that takes a level parameter.
> > Having 5 fixed levels is fine for most apps, but not
> > extensible enough.
> > Most loggers provide such a thing.
> >
>
> But deciding how to map those different log level parameters to levels is a
> matter of the logger policy. The commons log package is, to my
> understanding, to be used by components and containers that are not in
> charge of policy. While I agree that some applications may be interested in
> using more than {trace, debug, info, warn, error, fatal}, that should be
> sufficient for a component that is policy neutral and meant to be reused.
That's reasonable.
> > - Given that it is a facade, it would need some way to pass at least
> > config info to the underlying logger ( at least setProperty like ).
> > Some logger may not need any, but if they do it'll require using
> > internal APIs.
> >
>
> The configuration should be done with the logging package API. A component
> is not going to do configuration, the application, or the administrator, is
> going to. The components need a uniform way of accessing the logging system
> that the application is using.
>
> Incidentally, this implies to me that if no logging system is configured,
> then components should not log. It should be a no-op. Not even print to
> stderr. [god forbid stdout]
I don't agree. You should be able to pass some information to the logger,
at least the location of a logger-specific config, in a way that's
independent to the logger.
And if no logging is configured, the default should be a 'simple' logger.
> > - I don't like the idea of constructors with a param. All other APIs
> > use a no-param constructor. You can easily call a setter if
> > you need to.
> >
> Two things come to mind. What are the semantics of calling the setter after
> the object has been created? More important, in a multithreaded environment,
> setting during the constructor avoids messy coherency issues, as no other
> thread has access until the construction is complete.
Again - all APIs that I use are based on no-param constructors.
Check servlets, jaxp, jdbc, etc - they all seem to work, and it's a
pattern we are all familiar with.
Costin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
