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 ( http://www.slf4j.org/ ) 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
