incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kosuru" <prasadarao.kos...@gmail.com>
Subject Re: Logging
Date Fri, 21 Apr 2006 14:46:09 GMT
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 <daniel.kulp@iona.com> 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
> daniel.kulp@iona.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message