Santiago Gala wrote:
>
> [EMAIL PROTECTED] escribió:
>
> > Alan McAuley wrote:
> > >
> > > >
> > > > // creates new String objects only if Log is logging
> > > > if (Log.isLogging()) {
> > > > Log.note("SimpleTransform: transforming url: " + url +
> > > > " with stylesheet: " + stylesheet_url );
> > > > }
> > > >
> > >
> > > What about centralising the "isLogging" code to the Log class itself. The
> > > above is quite cumbersome really. So the Log class is centrally
> > > enabled/disabled. Log.note would then make the check to see if logging is
> > > enabled..... Ive done something similar before (havent we all!) - have a flag
> > > in a properties file to enable/disable logging when first initialised.
> > >
> >
> > If you want to disable debugging for performance reason, you don't want to generate
> > the debug string because String manipulation is expensive in Java, so it makes
> > sense from a performance point of view to use the construct Thomas proposed
> > rather than filtering at the Log class level.
>
> A less cumbersome alternative could be to implement several variations of the
> Log.note, Log.warning, Log.error , ... methods as:
>
> note(String mess);
> note(String mess1, String mess2);
> note(String mess1, String mess2, String mess3);
> ... (upto maybe 5 Strings)
>
> where each alternative would check for the log flag and then concatenate the Strings
> and log them, or else call a method that would not put a line end in the log except
> for the last message part. This hides the code complexity in the Log class, where it
> should be, instead of adding complexity to the rest of the code. I don't like it very
> much, but it would delay the concatenation until after the flag is checked.
>
> I am also concerned about the code complexity. I think that the isLogging() method is
> not enough, in addition. We want to disable logging in three levels: note, warning,
> error, ...
>
> If we have to write something like
>
> if(Log.isLoggingNotes() )
> Log.note( " ... " + s1 + " ... " + s2 + "...");
>
> developers will log less events, which is bad.
>
> Log.note(" ...", s1, "...", s2, "...");
>
> is more acceptable to me.
>
> What do you think?
>
That this code does not belong to Jetspeed but to the framework. ;)
There are already way too many logging class around here and I don't
see the point in implementing yet another one.
Logging and debug features are important but should be (and maybe
are already ) addressed by Turbine, so the extensions to the logging
capabilities of Turbine should be discussed on Turbine.
As for me, I'd be happy with any scheme right now because I don't think
performance will be very important before 2 or 3 other alpha releases.
I'd focus right now of usability and functionalities.
--
Raphaël Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
