Hi Dan, I understand your concerns about not having a dependency on log4j in celtix. Again considering the fact that, log4j has been used by many for a while now and is robust, why not make use of it's features? I know j.u.l provides similar features, but why to re-invent something incase if we need some enhanced logging functionality when it's available in log4j? For example if you want to add new formatting mechanism you need to extend the formatter class for j.u.l but log4j has this builtin already and you can simply use the pattern for the log output.
Again it really depends on to what extent we want to use our logging, if we have to extend j.u.l to achieve this than it's better to use log4j since it has lot of features. But I think your idea of extending j.u.l interface to accomodate log4j or any other logging mechanism is not bad either. Cheers, Prasad On 4/21/06, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > > Balaji, > > > So can't we do the same thing the other way around, use the log4j > > logging api & have the a custom jdk logger based on the log4j api... > > Yes, but then you HAVE to ship log4j for the interfaces and such. If the > API is based on the JDK stuff, all the API's are already in the JDK. > There is nothing we need to ship. We wouldn't have any dependencies on > anything else. From a Celtix standpoint, I don't want a dependency on > log4j. Thus, if the Celtix distribution (not the actual runtime, but > the installable package) is to include yoko parts, I don't want them > dependent on the log4j API's. > > Enjoy! > Dan > > > > On Friday 21 April 2006 09:08, Mosur Ravi, Balaji wrote: > > I like this idea... Since yoko is going to be used by different > > projects (celtix, geronimo), we should be able to log to any system... > > > > If I understand you correctly then what you suggest is to use the > > java.util.Logger as the logging API instead of creating our own logging > > api... We will have a log4j Logger & default jdk logger... > > > > So can't we do the same thing the other way around, use the log4j > > logging api & have the a custom jdk logger based on the log4j api... > > > > I haven't worked much with either api to know which has the complete > > list of logging api's, i.e which can be considered as a superset, > > because it would be hard to map from a subset to a superset... > > > > If log4j has the complete list of log api's, then we will use it > > instead... > > > > - Balaji > > > > -----Original Message----- > > From: Kulp, John Daniel > > Sent: Friday, April 21, 2006 7:49 AM > > To: yoko-dev@incubator.apache.org > > Cc: Lars Kühne > > Subject: Re: Logging > > > > > > > > -1 to defining our own logging API. That is silly when there is a > > perfectly good logging API that meets the requirements (logging > > requirements, not integration requirements), is very simple to use, > > that is already installed on everyones machines, does not have "version > > number" issues, etc... > > > > Also, for all parts that are based on, use, or derive from Celtix, you > > will have to deal with JDK logging anyway. All logging in Celtix is > > JDK logging. Thus, the tools and bindings stuff might as well just > > use JDK logging since that is where a large number of the log messages > > are going to go anyway. There is no plans (or desire) to change > > Celtix at this point. It would be a lot of work for little/no gain. > > > > > > How is this for an idea/comprimise: > > For all logging, we use JDK Logger objects. However, instead of > > calling Logger.getLogger(....), we create a utility class and call: > > LoggerFactory.getInstance().getLogger(.....). (several varieties of > > getLogger calls). The default factory just passes them on to JDK > > Logger getLogger calls. However, if you want, you can replace the > > LoggerFactory with one that will wrapper log4j Loggers or whatever else > > you want. The JDK Logger object is not final (or have any final > > methods) so we can use it as the API for logging, the underlying > > logging can be just about anything. I COULD be convinced to do > > something in similar in Celtix as this would JUST affect the Logger > > creation mechanisms, not any of the actual logging. > > > > What are peoples thoughts about that? > > > > Enjoy! > > Dan > > > > > -1 for using JDK logging directly > > > > > > I detailed this in my earlier messages, the short version is that > > > most people use/want/need log4j. Those people include myself for my > > > apps at work. Since Geronimo uses commons logging I assume that G > > > won't easily be able drop support for log4j either, but Geronimo > > > commiters might have more details on that. > > > > > > /Lars > > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 > [EMAIL PROTECTED] >
