You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2007/03/29 14:06:20 UTC
Re: svn commit: r523580 - /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/caching/impl/CacheImpl.java
felixk@apache.org wrote:
> Make method getLogger() visible for extending
> - private Log getLogger() {
> + protected Log getLogger() {
Felix,
As far as commons logging usage pattern goes, extending classes should create
own instances of the log, otherwise log will get really confusing, with class
name of one class and message from another class.
Vadim
Re: svn commit: r523580 - /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/caching/impl/CacheImpl.java
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>> felixk@apache.org wrote:
>>> Make method getLogger() visible for extending
>>
>>> - private Log getLogger() {
>>> + protected Log getLogger() {
>>
>> Felix,
>>
>> As far as commons logging usage pattern goes, extending classes should
>> create own instances of the log, otherwise log will get really
>> confusing, with class name of one class and message from another class.
>
> if the getClass() method is used, then extending classes should be safe.
> It's only problematic when static logging is used, then you're right,
> that you would log into the category of the parent object.
Yep, thanks for correction, I was still assuming static logger :)
Vadim
Re: svn commit: r523580 - /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/caching/impl/CacheImpl.java
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> felixk@apache.org wrote:
>> Make method getLogger() visible for extending
>
>> - private Log getLogger() {
>> + protected Log getLogger() {
>
> Felix,
>
> As far as commons logging usage pattern goes, extending classes should
> create own instances of the log, otherwise log will get really
> confusing, with class name of one class and message from another class.
if the getClass() method is used, then extending classes should be safe. It's
only problematic when static logging is used, then you're right, that you would
log into the category of the parent object.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: svn commit: r523580 - /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/caching/impl/CacheImpl.java
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Felix Knecht wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vadim Gritsenko schrieb:
>> felixk@apache.org wrote:
>>> Make method getLogger() visible for extending
>>> - private Log getLogger() { + protected Log getLogger() {
>> Felix,
>>
>> As far as commons logging usage pattern goes, extending classes
>> should create own instances of the log, otherwise log will get
>> really confusing, with class name of one class and message from
>> another class.
>
> I see. But in this case we also can avoid the private method
> 'getLogger()' and use the defined class logger directly without going
> the long way round getLogger() ?
I think reason getLogger() was added simply to avoid many small changes to the file.
Vadim
Re: svn commit: r523580 - /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/caching/impl/CacheImpl.java
Posted by Felix Knecht <fe...@otego.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vadim Gritsenko schrieb:
> felixk@apache.org wrote:
>> Make method getLogger() visible for extending
>
>> - private Log getLogger() { + protected Log getLogger() {
>
> Felix,
>
> As far as commons logging usage pattern goes, extending classes
> should create own instances of the log, otherwise log will get
> really confusing, with class name of one class and message from
> another class.
I see. But in this case we also can avoid the private method
'getLogger()' and use the defined class logger directly without going
the long way round getLogger() ?
Felix
>
> Vadim
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGC7Au2lZVCB08qHERAg7uAJ91PlNkdvStwzTN17pm2p9ztMk6twCgpjzl
vMFTmpE+iQXdhrreK/BZ4ZI=
=yy1O
-----END PGP SIGNATURE-----