You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Christopher Blythe <cj...@gmail.com> on 2007/03/22 21:31:01 UTC
Daytrader logging...
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.
2) Modify DayTrader to log all messages to system.out or system.err.
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?
Chris
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: Daytrader logging...
Posted by Christopher Blythe <cj...@gmail.com>.
Jason...
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...
Chris
On 3/22/07, Jason Dillon <ja...@planet57.com> 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 ( 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
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: Daytrader logging...
Posted by Jason Dillon <ja...@planet57.com>.
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