geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Daytrader logging...
Date Thu, 22 Mar 2007 20:51:11 GMT
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  

> 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.


View raw message