You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Harald Ommang <ha...@ommang.com> on 2003/05/06 22:13:28 UTC
[PROPOSAL] Further logging enhancements
Hi!
Refer to some of the discussion in Cleanup Logging
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15214)
The patch for this bug improves error logging, encloses debug logging, and fixes
imports (from .* to .specific class) The latter makes it easier to search the
code and do the next step that I am suggesting here.
I have checked what is going on in Turbine 2.3. It lookes as though they are
getting rid of their own logging class (org.apache.turbine.util.Log) and starts
using Commons Logging directly. I therefore propose the following:
* Rewrite Mark's logging service into a Commons Logging wrapper and a helper
clas or two, as the package org.apache.turbine.services.logging will cease to
exist. This wrapper will use Commons Logging, instead of using CL directly in
all our code. It is then easier to change logging tool if wanted.
* Change all use of org.apache.turbine.util.Log to our own Logger.class.
* Use a fine grained LOG4J configuration. Meaning something like this.
static Logger logger = Log.getLogger(<class>.class);
* Possibly add our own categories for certain use, suggestions welcome.
* Provide LOG4J configuration file that shows Jetspeed users recommended ways to
configure for debugging and for production use. LOG4J configuration could be
supplied in .properties and .xml versions, for users preferred choice. (I
believe the XML-version has some more options than the .properties)
* Other logging related enhancements.
If you want to have this included in b5, I'd love to do the work. I'm very eager
to start working on this, after i get comments from the developers. I'll then
start by putting a revised proposal as and [ENH in Bugzilla. I hope one of the
comitters have time to commit the Cleanup Logging patch, so I can start on this.
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: [PROPOSAL] Further logging enhancements
Posted by Mark Orciuch <ma...@ngsltd.com>.
Harald and James,
Thanks for your input. have never implemented a fine grained LOG4J
configuration. What strategy would you propose for Jetspeed? How "fine
grained" do we want to get? Do we have a logger per service? What about
other classes (such as actions)? I also like the idea of verbosity levels -
similar to what Raphael did in the Registry service.
I think that we can get started on rewriting the logging service
immediately. I would still like to hear feedback from other committers on
the fine grained LOG4J configuration.
Best regards,
Mark Orciuch - morciuch@apache.org
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/
> -----Original Message-----
> From: James Nguyen [mailto:sentinel@duskyblue.net]
> Sent: Thursday, May 08, 2003 6:41 PM
> To: Jetspeed Developers List
> Subject: RE: [PROPOSAL] Further logging enhancements
>
>
> I can also lend a helping hand to Harald if needed since I'm fairly
> familiar with Log4J seeing how easy it is to use. Given the 1 month time
> frame is plenty of time even for a one person task like this.
>
> James Nguyen
>
> At 02:35 PM 5/8/2003 -0500, you wrote:
> >Harald,
> >
> > > * Rewrite Mark's logging service into a Commons Logging wrapper
> > > and a helper
> > > clas or two, as the package org.apache.turbine.services.logging
> > > will cease to
> > > exist. This wrapper will use Commons Logging, instead of using CL
> > > directly in
> > > all our code. It is then easier to change logging tool if wanted.
> > >
> >
> >+1. This service was just an interim solution and it will be
> good to be able
> >to easily plugin any logging solution.
> >
> > > * Change all use of org.apache.turbine.util.Log to our own
> Logger.class.
> > >
> >
> >+1
> >
> > > * Provide LOG4J configuration file that shows Jetspeed users
> > > recommended ways to
> > > configure for debugging and for production use. LOG4J
> > > configuration could be
> > > supplied in .properties and .xml versions, for users
> preferred choice. (I
> > > believe the XML-version has some more options than the .properties)
> >
> >I'd say the first three proposals are essential for the final release (I
> >think Beta 5 may become the final release if all goes well). Also, they
> >carry very little risk in destabilizing the code before the
> final release.
> >
> > > * Use a fine grained LOG4J configuration. Meaning something like this.
> > > static Logger logger = Log.getLogger(<class>.class);
> > >
> > > * Possibly add our own categories for certain use,
> suggestions welcome.
> > >
> >
> >I can see separate loggers for Registry, Profiler, PsmlManager, Security,
> >etc, so this is certainly a good suggestion. My vote would be to
> implement
> >these two after the final release unless you think that they can be
> >implemented relatively quickly (within a months or so). What do
> you think?
> >
> >Hopefully, we'll apply your patches quicker than before :-)
> >
> >Best regards,
> >
> >Mark Orciuch - morciuch@apache.org
> >Jakarta Jetspeed - Enterprise Portal in Java
> >http://jakarta.apache.org/jetspeed/
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
> James Nguyen
> I/T Professional
> 600 Anton Boulevard - Suite 360
> Costa Mesa, California 92626
>
> "Cogito ergo sum"
> -Rene Descartes
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: [PROPOSAL] Further logging enhancements
Posted by James Nguyen <se...@duskyblue.net>.
I can also lend a helping hand to Harald if needed since I'm fairly
familiar with Log4J seeing how easy it is to use. Given the 1 month time
frame is plenty of time even for a one person task like this.
James Nguyen
At 02:35 PM 5/8/2003 -0500, you wrote:
>Harald,
>
> > * Rewrite Mark's logging service into a Commons Logging wrapper
> > and a helper
> > clas or two, as the package org.apache.turbine.services.logging
> > will cease to
> > exist. This wrapper will use Commons Logging, instead of using CL
> > directly in
> > all our code. It is then easier to change logging tool if wanted.
> >
>
>+1. This service was just an interim solution and it will be good to be able
>to easily plugin any logging solution.
>
> > * Change all use of org.apache.turbine.util.Log to our own Logger.class.
> >
>
>+1
>
> > * Provide LOG4J configuration file that shows Jetspeed users
> > recommended ways to
> > configure for debugging and for production use. LOG4J
> > configuration could be
> > supplied in .properties and .xml versions, for users preferred choice. (I
> > believe the XML-version has some more options than the .properties)
>
>I'd say the first three proposals are essential for the final release (I
>think Beta 5 may become the final release if all goes well). Also, they
>carry very little risk in destabilizing the code before the final release.
>
> > * Use a fine grained LOG4J configuration. Meaning something like this.
> > static Logger logger = Log.getLogger(<class>.class);
> >
> > * Possibly add our own categories for certain use, suggestions welcome.
> >
>
>I can see separate loggers for Registry, Profiler, PsmlManager, Security,
>etc, so this is certainly a good suggestion. My vote would be to implement
>these two after the final release unless you think that they can be
>implemented relatively quickly (within a months or so). What do you think?
>
>Hopefully, we'll apply your patches quicker than before :-)
>
>Best regards,
>
>Mark Orciuch - morciuch@apache.org
>Jakarta Jetspeed - Enterprise Portal in Java
>http://jakarta.apache.org/jetspeed/
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
James Nguyen
I/T Professional
600 Anton Boulevard - Suite 360
Costa Mesa, California 92626
"Cogito ergo sum"
-Rene Descartes
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [PROPOSAL] Further logging enhancements
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Tuesday, May 6, 2003, at 04:13 PM, Harald Ommang wrote:
> Hi!
>
> Refer to some of the discussion in Cleanup Logging
> (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15214)
>
> The patch for this bug improves error logging, encloses debug logging,
> and fixes
> imports (from .* to .specific class) The latter makes it easier to
> search the
> code and do the next step that I am suggesting here.
>
> I have checked what is going on in Turbine 2.3. It lookes as though
> they are
> getting rid of their own logging class (org.apache.turbine.util.Log)
> and starts
> using Commons Logging directly. I therefore propose the following:
>
> * Rewrite Mark's logging service into a Commons Logging wrapper and a
> helper
> clas or two, as the package org.apache.turbine.services.logging will
> cease to
> exist. This wrapper will use Commons Logging, instead of using CL
> directly in
> all our code. It is then easier to change logging tool if wanted.
>
+1
> * Change all use of org.apache.turbine.util.Log to our own
> Logger.class.
>
+1
> * Use a fine grained LOG4J configuration. Meaning something like this.
> static Logger logger = Log.getLogger(<class>.class);
>
+1
> * Possibly add our own categories for certain use, suggestions welcome.
>
> * Provide LOG4J configuration file that shows Jetspeed users
> recommended ways to
> configure for debugging and for production use. LOG4J configuration
> could be
> supplied in .properties and .xml versions, for users preferred choice.
> (I
> believe the XML-version has some more options than the .properties)
>
> * Other logging related enhancements.
>
> If you want to have this included in b5, I'd love to do the work. I'm
> very eager
> to start working on this, after i get comments from the developers.
> I'll then
> start by putting a revised proposal as and [ENH in Bugzilla. I hope
> one of the
> comitters have time to commit the Cleanup Logging patch, so I can
> start on this.
>
I've been gone for a week. Give me time to catch up reading and see if
anyone has already volunteered...
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: [PROPOSAL] Further logging enhancements
Posted by Mark Orciuch <ma...@ngsltd.com>.
Harald,
> * Rewrite Mark's logging service into a Commons Logging wrapper
> and a helper
> clas or two, as the package org.apache.turbine.services.logging
> will cease to
> exist. This wrapper will use Commons Logging, instead of using CL
> directly in
> all our code. It is then easier to change logging tool if wanted.
>
+1. This service was just an interim solution and it will be good to be able
to easily plugin any logging solution.
> * Change all use of org.apache.turbine.util.Log to our own Logger.class.
>
+1
> * Provide LOG4J configuration file that shows Jetspeed users
> recommended ways to
> configure for debugging and for production use. LOG4J
> configuration could be
> supplied in .properties and .xml versions, for users preferred choice. (I
> believe the XML-version has some more options than the .properties)
I'd say the first three proposals are essential for the final release (I
think Beta 5 may become the final release if all goes well). Also, they
carry very little risk in destabilizing the code before the final release.
> * Use a fine grained LOG4J configuration. Meaning something like this.
> static Logger logger = Log.getLogger(<class>.class);
>
> * Possibly add our own categories for certain use, suggestions welcome.
>
I can see separate loggers for Registry, Profiler, PsmlManager, Security,
etc, so this is certainly a good suggestion. My vote would be to implement
these two after the final release unless you think that they can be
implemented relatively quickly (within a months or so). What do you think?
Hopefully, we'll apply your patches quicker than before :-)
Best regards,
Mark Orciuch - morciuch@apache.org
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org