On Sat, 2 Feb 2002, Remy Maucherat wrote: > > Both log4j and logkit have solutions that allow safe use in a container > > environment, i.e. support of isolation for the users of the API > > ( one app using the package can't mess with another app's logging ). > > I'm -1 on releasing with this whole in it. > > You can always hide it in the core of the container. And the SM will protect > you :) > I agree it may be a problem in some cases, but it won't be for Tomcat.
Don't overestimate the SM. If the logger is successfull and a lot of components will depend on it, it's very likely it'll end up in the common class loader ( or even the system loader ), at least in some configurations. Even if tomcat's class loader may protect a bit ( and I doubt that), many other applications don't have such a xxxxx class loader. Remember all the problems and mess with jaxp in tc - the code is extremely tricky if you don't want jaxp in the common loader. Not too many people can understand how it works and when it works. > 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. > > - 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. > > - 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. > > - 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. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
