Answer inline:
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, February 03, 2002 11:24 AM
>
>
> On Sat, 2 Feb 2002, Remy Maucherat wrote:
>
> ...
>
> > I don't see a problem with getInstance, though. What's the problem ?
> > Using getInstance, or just constructing the object with a new seems
> > equivalent to me.
>
> Creating a new object may be different - getInstance may give you the
> logger that is already used by a different application.
Maybe you should only be able to go down the current subtree of loggers.
(Or the current subtree of the Hierarchy or whatever vocabulary applies
in your favorite logger.)
> > > - static methods in LogSource. I suppose LogSource is a sort of
> > > factory - the pattern used here is completely unnatural ( or at least
> > > different from most APIs in use ).
> >
> > Static everywhere, actually ;-)
> > There's some syncing needed in there, also (the loggers are in
> a HashMap).
>
> Yes. I don't mind 1-2 static methods ( preferably in Log ), for
> convenience, but they should just be a shortcut for calling a virtual
> method in the log manager.
I do not mind a static method if they do not mind a singleton.
IMO, if you want to use something as a part of a big app or framework,
singletons are to be avoided at all costs.
> > > - 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.
> >
> > I don't see very well how to configure the logger either. In
> Catalina and
> > Slide, we just instantiate the logger directly, so there's no
> such problem.
>
> I just hate the config mechanism for log4j - a system property is
> a nightmare in a container env ( with multiple apps, etc ), and a
> properties file in classes/ is not very nice ( by my taste ). I would
> prefer a file in conf/ or etc/ or constructed from the component
> 'natural' config.
>
> Passing at least a basic piece of config to the logger is essential,
> it doesn't have to be supported by all loggers.
IMHO, there should be several configuration layers, each one building
on top of the previous one, and it should be easy to use a layer as
"low" as you want without having to pay the price of the more
sophisticated layers above.
Layers I am thinking on, from lower to higher level:
(0) You just configure your favorite logger yourself, wrap it with
the right wrapper and pass it to the rest of your app;
(1) There is a registry of loggers <=> wrappers to which you pass
your favorite logger already configured, getting the matching
wrapper ready to use. This simple registry is configured trough
an API and has an optional "default" configuration for the 3
"major APIs";
(2) You have a logger factory interface that will be used by the
several possible discovery implementations;
(3) There is a class-loader based implementation for the logger
factory (2) that tries to find out which API is available. This
is not good for some applications but is quite practical for
others and IMHO should be available.
- You can configure via API what are your most favorite and
less favorite logging APIs and the discovery process will
follow that order;
- You can set a "minimum common denominator" configuration
that works for any of the APIs available (e.g.: all the big
3 accept logging to a file with rotating file names).
(4) Configuring (3) via properties, directly passed to the factory
or loaded from a given source. Optionally you can set the names
and/or a common prefix for each property (e.g. for prefix:
saying that all the property names should be prefixed with
"velocity.logger.");
(5) Any other crazy thing that implements (2).
What do you think?
> > > - no support for i18n-style messages. Probably not a big deal
> > > for the first release, but it would be nice to think about it ( I know
> > > log4j can do that, I assume other as well ).
> >
> > You mean have the logger handle the message bundle for you, and
> just give it
> > the message key (+ params) ?
>
> That would be a good idea. One possible optimization for the logger would
> be to store the unprocessed key/params, and have them processed off line
> ( or just have an efficient way to generate the message ). StringBundle
> has some issues.
The "official" (SUN) i18n APIs all have several issues and that is why
several alternative solutions are popping across Jakarta. Avalon alone
as more than one.
I would suggest dropping this one from the logging API. Let separate
packages extend this one with their favorite i18n flavor without
favoring a specific solution that might prove not being the best in the
near future.
I also was adding i18n to my logging package and dropped it.
> Costin
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
