You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by "J. Wolfgang Kaltz" <ka...@interactivesystems.info> on 2005/03/07 15:44:26 UTC
Re: Some notes on the switch to LogEnabled
Hi all (&& especially logging experts)
I'm trying to assist in the switching to LogEnabled. Right now I'm
looking at src/java/org/apache/lenya/cms/task and
src/java/org/lenya/cms/publishing (I realize there are some deprecated
classes in there, but might as well try to change everything)
I guess the best approach is to "extends AbstractLogEnabled" in the
highest level of a hierarchy ? In this case
o.a.l.cms.task.AbstractTask
Then the challenge remains to find where objects are created, so that
enableLogging() can be called at the right place, right ?
(this addresses http://issues.apache.org/bugzilla/show_bug.cgi?id=19556)
If I'm on the right track, I'll keep on hacking away at this this week.
A unified logging mechanism + configuration possibility for the logging
is (of course) a prerequisite for successful debugging - whereas my
short-term goal is to better be able to trace what is going on, so I can
improve my understanding of Lenya internals.
Wolfgang
Andreas Hartmann schrieb:
> Hi Lenya devs,
>
> I managed to switch quite a lot of classes from Log4j to
> LogEnabled. The access control and workflow components
> are Log4j-free.
>
> Some observations:
>
>
> - The most convenient way to pass the logger to an object is
>
> ContainerUtil.enableLogging(object, logger);
>
> This method doesn't pass the logger unless the object is
> LogEnabled, and it throws an exception if the logger is null.
> I added this info to the Cocoon wiki.
>
>
> - In cases where there was no logger available, I passed a
> ConsoleLogger to the object. This results in a lot of DEBUG
> messages to the console. If anyone finds a better solution
> (e.g., wrap the Log4j category with an Avalon logger), please
> send a mail to lenya-dev.
>
>
> - You really have to take care of properly initializing all loggers.
> Otherwise, you end up with NPEs when a log message is written.
> I managed this using Eclipse's "find references" function on the
> constructor. But I think we should find a standardized way.
> In some cases (builders and factories), I pass the logger
> in the constructor. No idea if this is a good practise.
>
>
> - In case someone didn't yet know: Implementing an object as an
> Avalon service makes life much easier. Just extend AbstractLogEnabled
> and forget the rest :)
>
>
> - You can't use static methods with logging, because the logger
> is not static anymore. This is IMO a *very good thing*, because it
> prevents us from using the questionable static method approach :)
>
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Some notes on the switch to LogEnabled
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> Hi all (&& especially logging experts)
>
> I'm trying to assist in the switching to LogEnabled.
Cool! :)
> Right now I'm
> looking at src/java/org/apache/lenya/cms/task and
> src/java/org/lenya/cms/publishing (I realize there are some deprecated
> classes in there, but might as well try to change everything)
> I guess the best approach is to "extends AbstractLogEnabled" in the
> highest level of a hierarchy ? In this case
> o.a.l.cms.task.AbstractTask
Yes, that sounds like a good idea.
> Then the challenge remains to find where objects are created, so that
> enableLogging() can be called at the right place, right ?
The call chain is basically
TaskAction/Scheduler
-> CocoonTaskWrapper/DefaultTaskWrapper
-> TaskManager
-> Task
> (this addresses http://issues.apache.org/bugzilla/show_bug.cgi?id=19556)
>
> If I'm on the right track, I'll keep on hacking away at this this week.
> A unified logging mechanism + configuration possibility for the logging
> is (of course) a prerequisite for successful debugging - whereas my
> short-term goal is to better be able to trace what is going on, so I can
> improve my understanding of Lenya internals.
If you want to see how Lenya 1.2 works, the packages you're currently
observing are very important - and very complicated :)
New developments in 1.4 focus on o.a.l.cms.usecase.* and the like which
are much simplier, but that does not mean that the task concept won't
be supported anymore.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Some notes on the switch to LogEnabled
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> (Again, regarding logging and
> http://issues.apache.org/bugzilla/show_bug.cgi?id=19556
> -> moving from direct usage of log4j to Avalon)
>
> Can somebody (Andreas?) pls confirm the following:
>
> in Lenya 1_2_X,
> - there is only one logging configuration file, log4j.xconf (since
> web.xml delegates all logging to log4j). logkit.xconf is not used at all
Hmm, I don't think so ... but I'm not sure.
> - only those classes that are defined as Cocoon components actually use
> AbstractLogEnabled. Avalon takes care of initializing the logger in
> these cases properly, so no problem there.
Yes.
> - classes logging through Avalon no longer have their class name as
> category, so I suggest the ConversionPattern in log4j.xconf should
> contain %C (the class name) - otherwise when classes higher up in the
> hierarchy use the logger, you can't see in which class you are (example:
> DefaultAccessController)
Makes sense.
> I suppose it doesn't make sense to change source code in Lenya 1_2_X
> regarding the logging.
I agree.
> The bug entry does indeed suggest only trunk is
> affected. Since logging can in fact configured in a single file (if I
> understand correctly that logkit.xconf is not used), it would not be
> worth the risk to alter 1_2_X regarding logging
>
> So conclusions would be
> - remove logkit.xconf from repository to avoid confusion for debuggers
> (it certainly confused me)
Not sure (see above)
> - add class name to log4j.xconf pattern
+1
> - focus exclusively on trunk for logging changes
+1
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Some notes on the switch to LogEnabled
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
(Again, regarding logging and
http://issues.apache.org/bugzilla/show_bug.cgi?id=19556
-> moving from direct usage of log4j to Avalon)
Can somebody (Andreas?) pls confirm the following:
in Lenya 1_2_X,
- there is only one logging configuration file, log4j.xconf (since
web.xml delegates all logging to log4j). logkit.xconf is not used at all
- only those classes that are defined as Cocoon components actually use
AbstractLogEnabled. Avalon takes care of initializing the logger in
these cases properly, so no problem there.
- classes logging through Avalon no longer have their class name as
category, so I suggest the ConversionPattern in log4j.xconf should
contain %C (the class name) - otherwise when classes higher up in the
hierarchy use the logger, you can't see in which class you are (example:
DefaultAccessController)
I suppose it doesn't make sense to change source code in Lenya 1_2_X
regarding the logging. The bug entry does indeed suggest only trunk is
affected. Since logging can in fact configured in a single file (if I
understand correctly that logkit.xconf is not used), it would not be
worth the risk to alter 1_2_X regarding logging
So conclusions would be
- remove logkit.xconf from repository to avoid confusion for debuggers
(it certainly confused me)
- add class name to log4j.xconf pattern
- focus exclusively on trunk for logging changes
?
Wolfgang
> Andreas Hartmann schrieb:
>
>> Hi Lenya devs,
>>
>> I managed to switch quite a lot of classes from Log4j to
>> LogEnabled. The access control and workflow components
>> are Log4j-free.
>>
>> Some observations:
>>
>>
>> - The most convenient way to pass the logger to an object is
>>
>> ContainerUtil.enableLogging(object, logger);
>>
>> This method doesn't pass the logger unless the object is
>> LogEnabled, and it throws an exception if the logger is null.
>> I added this info to the Cocoon wiki.
>>
>>
>> - In cases where there was no logger available, I passed a
>> ConsoleLogger to the object. This results in a lot of DEBUG
>> messages to the console. If anyone finds a better solution
>> (e.g., wrap the Log4j category with an Avalon logger), please
>> send a mail to lenya-dev.
>>
>>
>> - You really have to take care of properly initializing all loggers.
>> Otherwise, you end up with NPEs when a log message is written.
>> I managed this using Eclipse's "find references" function on the
>> constructor. But I think we should find a standardized way.
>> In some cases (builders and factories), I pass the logger
>> in the constructor. No idea if this is a good practise.
>>
>>
>> - In case someone didn't yet know: Implementing an object as an
>> Avalon service makes life much easier. Just extend AbstractLogEnabled
>> and forget the rest :)
>>
>>
>> - You can't use static methods with logging, because the logger
>> is not static anymore. This is IMO a *very good thing*, because it
>> prevents us from using the questionable static method approach :)
>>
>>
>> -- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org