[Json-rpc-java] logging
Arthur Blake
arthur.blake at gmail.com
Thu Jun 28 22:14:19 SGT 2007
I've come around to your point of view about JCL (Jakarta Commons Logging)!
I've had some significant issues with the Jakarta Commons Logging library in
certain environments (especially WebSphere). I have switched to SLF4J.
It's great-- much simpler to use and none of the classloading headaches.
I'm using it in my own open source library (log4jdbc, see
http://log4jdbc.sourceforge.net.)
With SLF4J you include a very tiny facade .jar and then one additional jar
that connects to your logging system of choice (which can be java standard
logging, log4j, logback, or even JCL among others) This gives you a lot
more flexibility when integrating libraries into larger applications that
may use a different logging system. Rather than having a discovery process
like JCL that can go wrong in different classloading environments, you
simply pop in the jar of choice for whatever logging system you are using...
this is a much simpler approach and gets rid of the headaches.
The need still exists to have the json-rpc-java library send it's logging to
the user's logging system of choice rather than being forced to use the jdk
logging api. What do you guys think about using SLF4J? I'd be willing to
submit the code changes. (it would be a piece of cake.) The standard
json-rpc-java build could still use the java logging system by default
(although via SLF4J.) I've had to run on a slightly customized version of
json-rpc-java to get by for the last year, but I'd love for this to get into
the library, and I think it would be a great improvement.
See http://slf4j.org/ for more information on SLF4J.
On 5/11/06, Brett Connor <brettconnor+tl at spamcop.net> wrote:
>
> I cannot find a bookmarked link, but from a quick search and a quick scan
> through I _think_ this is the one:
>
> http://www.qos.ch/logging/classloader.jsp
>
> Interestingly it now has a reference to a thing called Simple Logging
> Facade for
> Java (SLF4J). Whether this is or will become widespread I don't know.
>
> Brett Connor
>
>
>
> Quoting Arthur Blake < arthur.blake at gmail.com>:
>
> > I can't argue with that. I would say however that the latest version of
> the
> > commons logging library (1.1) has specific changes to compensate for the
> > downsides that you mentioned.
> >
> > from the 1.1 release preamble:
> >
> > "This release makes several changes that are intended to resolve issues
> that
> > have been encountered when using commons-logging in servlet containers
> or
> > j2ee containers where complex classpaths are present and multiple copies
> of
> > commons-logging libraries are present at different levels."
> >
> > I would be interested in reading that article if you can find it.
> >
> > Arthur
> >
> > On 5/7/06, Brett Connor <brettconnor at spamcop.net> wrote:
> > >
> > > While I agree with this in principal, commons logging in particular
> does
> > > have it's downside - there can be serious classloader type issues
> IIRC.
> > > If they don't affect you then you're fine, if they do then you're
> pretty
> > > much stuffed. I can't remember the details now, it's a wihle since I
> > > read the article, I'll see if I can dig out a reference to it.
> > >
> > > For this reason alone, I personnaly would like JSON to stick wiith
> java
> > > logging. Being a standard part of the JDK the hope is that one day it
> > > will become the standard API. If Sun had thought about logging earlier
> > > on it would have helped, I don't know how many thousands of people
> wrote
> > > a logging package as one of the first things they did. They could
> > > equally have put some thought into allowing the Java logging to be
> > > configured as an adaptor to other systems. I don't think as it stands
> > > there is any perfect solution.
> > >
> > >
> > > Arthur Blake wrote:
> > > > from the commons logging FAQ:
> > > > When should I use commons-logging?
> > > >
> > > > Commons-logging is very important when writing *libraries* that
> might be
> > > > used in other projects. If the library directly calls a concrete
> logging
> > > > library API (eg log4j or java.util.logging) but the application it
> is
> > > > embedded in is using some other logging library then there is a
> problem.
> > > > However if the library is using commons-logging then commons-logging
> > > simply
> > > > forwards all calls to whatever logging library the surrounding
> > > application
> > > > is using, ensuring output is all nicely unified. The specific
> underlying
> > > > library commons-logging uses can be explicitly configured
> (recommended),
> > > or
> > > > commons-logging can be permitted to auto-detect it.
> > > >
> > > > ~~~~
> > > >
> > > > More and more of the really useful open source libraries (for
> example,
> > > > hibernate and spring) use commons logging (not to mention the bulk
> of
> > > the
> > > > jakarta suite of open source libs). It gets you away from being
> tied to
> > > any
> > > > particular logging implementation and instead uses whatever logger
> that
> > > the
> > > > application you are integrating with uses.
> > > > This seems like a no-brainer to me.
> > > > A
> > > >
> > > > On 4/24/06, Arthur Blake <arthur.blake at gmail.com> wrote:
> > > >
> > > >> I believe that whether java logging or log4j is better and more
> > > powerful
> > > >> is highly debatable (flame-bateable?). But this was not the point.
> > > >> With apache commons logging (which is logger agnostic), you are not
> > > tied
> > > >> to any particular logger and you can plug in whatever logger you
> want
> > > at
> > > >> runtime (by default, commons logging uses the java logging system
> if no
> > > >> other logging system is found.)
> > > >>
> > > >>
> > > >> On 4/24/06, Cyril Bouteille <cyril at hotwire.com> wrote:
> > > >>
> > > >>> java.util.logging is the official standard and it's much more
> > > powerful
> > > >>> so I'd stick to that as much as possible.
> > > >>> In order to integrate 3rd-party libs using log4j, you can easily
> plug
> > > an
> > > >>> adapter class in the log4j.properties, e.g.
> > > >>>
> > > >>> log4j.appender.java14=hotwire.j2ee.Java14Log4jAppender
> > > >>>
> > > >>> public class Java14Log4jAppender extends AppenderSkeleton {
> > > >>>
> > > >>> java.util.logging.Logger log = ...
> > > >>>
> > > >>> protected void append(LoggingEvent event) {
> > > >>> String cat = event.getLoggerName();
> > > >>> int p = cat.lastIndexOf('.');
> > > >>> if (p != -1) {
> > > >>> cat = cat.substring(p+1);
> > > >>> }
> > > >>> String msg = cat + ": " + event.getRenderedMessage();
> > > >>> try {
> > > >>> if ( event.getLevel().isGreaterOrEqual(
> > > >>> org.apache.log4j.Level.ERROR)) {
> > > >>> log.severe(msg);
> > > >>> }
> > > >>> else if ( event.getLevel().equals(
> > > org.apache.log4j.Level.WARN))
> > > >>> {
> > > >>> log.warning(msg);
> > > >>> }
> > > >>> else {
> > > >>> log.fine(msg);
> > > >>> }
> > > >>> }
> > > >>> catch(Exception e) {
> > > >>> System.err.println("Log publication failed for " +
> msg);
> > > >>> e.printStackTrace();
> > > >>> }
> > > >>> }
> > > >>> }
> > > >>>
> > > >>> Arthur Blake wrote:
> > > >>>
> > > >>> Wouldn't it be much more useful to have json-rpc-java use apache
> > > jakarta
> > > >>> commons logging instead of java logging? That way we can use
> whatever
> > > logger
> > > >>> we want at run time. It seems like more and more, people are using
> > > this as
> > > >>> the standard for logging.. and it makes sense to me because
> commons
> > > logging
> > > >>> pretty much automatically detects what kind of logging you are
> using
> > > and
> > > >>> intelligently uses that. I just bring this up, because I am using
> > > >>> json-rpc-java in a project that uses commons logging and log4j,
> and I
> > > cannot
> > > >>> use my log4j logging to show the json-rpc-java log output. (see
> > > >>> http://jakarta.apache.org/commons/logging/
> > > >>> ) Also is there currently a way to log just the JSON itself (both
> > > input
> > > >>> & output) whenever a json-rpc-java call is made, in a nicely
> formatted
> > > and
> > > >>> indented way? _______________________________________________
> > > Json-rpc-java
> > > >>> mailing list Json-rpc-java at oss.metaparadigm.com
> > > >>> http://oss.metaparadigm.com/mailman/listinfo/json-rpc-java
> > > >>> --
> > > >>> *Cyril Bouteille*
> > > >>> Senior Software Architect [image: Hotwire.com Logo]<
> > > http://www.hotwire.com >
> > > >>> *Work:* 415-343-8405
> > > >>> *Fax:* 415-343-8401
> > > >>> *Email:* cyril at hotwire.com
> > > >>> *IM:* cyrilbouteille (Yahoo!)
> > > >>> * Professional Profile <https://www.linkedin.com/e/fps/124267/>*
> > > >>> *Hotwire.com*
> > > >>> < http://www.hotwire.com> 333 Market St
> > > >>> San Francisco, CA 94105 USA<
> > >
> >
>
> http://maps.google.com/maps?q=333+Market+St%2CSan+Francisco%2CCA+94105%2CUSA&hl=en
> > > >
> > > >>>
> > > >>> *This email message is for the sole use of the intended
> recipient(s)
> > > and
> > > >>> may contain confidential information. Any unauthorized review,
> use,
> > > >>> disclosure or distribution of this message is prohibited. If you
> are
> > > not
> > > >>> intended recipient of this message please contact the sender by
> reply
> > > email
> > > >>> and destroy all copies of the original message.*
> > > >>>
> > > >>>
> > > >>
> > > >
> > > >
> > > >
> ------------------------------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > Json-rpc-java mailing list
> > > > Json-rpc-java at oss.metaparadigm.com
> > > > http://oss.metaparadigm.com/mailman/listinfo/json-rpc-java
> > > >
> > >
> > > _______________________________________________
> > > Json-rpc-java mailing list
> > > Json-rpc-java at oss.metaparadigm.com
> > > http://oss.metaparadigm.com/mailman/listinfo/json-rpc-java
> > >
> > _______________________________________________
> > Json-rpc-java mailing list
> > Json-rpc-java at oss.metaparadigm.com
> > http://oss.metaparadigm.com/mailman/listinfo/json-rpc-java
> >
> _______________________________________________
> Json-rpc-java mailing list
> Json-rpc-java at oss.metaparadigm.com
> http://oss.metaparadigm.com/mailman/listinfo/json-rpc-java
>
More information about the Json-rpc-java
mailing list