geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Blythe" <>
Subject Re: Daytrader logging...
Date Fri, 23 Mar 2007 15:57:02 GMT

Thanks for the feedback. After a little digging, I finally figured out
somewhat of a workaround for Glassfish. Basically, I can append the
commons-logging jar to the servers classpath and then update the logging
level for DayTrader via their AdminConsole. The only downside to this
approach is that the streamer appclient doesn't have access to the
commons-logging jar when it is launched remotely (via Java WebStart). In
order for it to have access, you have to package it inside the ear (since
Glassfish does not provide a way to modify the JNLP properties). I guess
that can be a "manual step" for now if you really want to use the app
client. Anyway, I guess this approach will have to suffice for non-JCL based
app servers (which could possibly be just Glassfish).

Thanks again...


On 3/22/07, Jason Dillon <> wrote:
> On Mar 22, 2007, at 1:31 PM, Christopher Blythe wrote:
> > After working with Glassfish (Sun Server 9) as part of the
> > DayTrader/EJB3 development effort, it dawned on me that our logging
> > configuration might be too tightly coupled to Geronimo and may not
> > be that portable to other application servers. The DayTrader Logger
> > class depends on Apache commons-logging which is fortunately
> > provided by the Geronimo core. However, as I found with Glassfish,
> > not all application servers commons-logging to provided their
> > logging/tracing infrastructure.
> >
> > I had some thoughts on how we could make logging within DayTrader
> > more portable. Here are a few ideas...
> >
> > 1) Package the dependent jars (common-logging, log4j, etc.) within
> > the ear as part of the maven build process. Also include a default
> > set of logging config properties files.
> I'm not sure that JCL is going to be very happy about this, its been
> a chronic PITA wrt being loaded multiple classloaders.  If it wasn't
> such a PITA then I would say that JCL could be included, but not the
> underlying impl.  I'm guessing Glassfish uses the java.util.logging
> mess, and in which case you'd simply configure JCL to delegate to the
> Jdk14Logger, which JCL should actually figure out automatically.
> If JCL is happy with a jar in the system and a jar in the ear/war,
> then that would be the way to go.  But defs don't include the log4j
> stuff.
> > 2) Modify DayTrader to log all messages to system.out or system.err.
> OMG please no!  *shivers*.
> > Overall, I think option 1 provides the best mix of portability and
> > flexibility. By including the dependent logging jars within the
> > application, we are no longer dependent upon the application server
> > to provide the jars.
> >
> > Any thoughts or other suggestions?
> Somewhat related... I'm starting to think that we would be *much*
> better off by using slf4j ( ) instead of JCL
> for our logging abstraction layer.  From what I hear slf4j has less
> wrinkles and doesn't freakout when multiple versions might have been
> loaded in the same way that JCL does.  Its also packaged up much
> better that JCL, so its easier to pick the supported.
> I think we could also do with a round of general logging updates, to
> make sure all of our components use the same api and use it in a
> consistent way.  Maybe something for 2.1, not sure anyone has time to
> dig into this more at the moment.
> --jason

"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden

View raw message