Loggers

[ri...@geoquip-rnd.demon.co.uk]

In FONode, it say:

    //TODO Remove getLogger() method!

Yet everywhere around the code base it says foo.getLogger(),
in particular for FObj instances. What is the preferred way
to aquire a logger instance?

Richard

Re: Loggers

[Andreas L Delmelle <a_...@pandora.be>]

On Jan 11, 2007, at 18:31, Andreas L Delmelle wrote:

> ... use an instance method to access a protected static member of  
> the superclass. That's a good one! :-)

And what about:

if (log.isDebugEnabled()) {  getLogger().debug("..."); }

unless we were thinking about tying the settings for the static  
logger to a possible instance-based logger (if debug enabled on the  
static logger, then route message to instance logger?) Hmm...


Cheers,

Andreas

Re: Loggers

[Andreas L Delmelle <a_...@pandora.be>]

On Jan 11, 2007, at 19:51, richardw@geoquip-rnd.demon.co.uk wrote:

> Andreas L Delmelle writes:
>> log is a protected static, so if the class resides in the same
>> package, then you can use direct member access. Currently, in some
>> places, the properties seem to be routing the message to the FO's
>> logger, instead of using Property.log directly...
>
> Or even worse - keeeping a reference to the FObj in question as a
> member for the sole purpose of being able to call the getLogger()
> method later on  - see LengthBase for example.

Not entirely true, I'm afraid. The fobj is also used to pass into  
PercentBaseContext.getBaseLength()... so FTM, I only replaced the  
call to getLogger() with logging to a specific logger for LengthBase.

>> Don't worry, already cleaning up.
>
> OK. When your changes are submitted and checked in, I'll update my
> tree and submit a new patch for the properties fixes.

Done, see: http://svn.apache.org/viewvc?view=rev&rev=495371

Thanks for pointing this out!

Cheers,

Andreas

Re: Loggers

[ri...@geoquip-rnd.demon.co.uk]

Andreas L Delmelle writes:
 > log is a protected static, so if the class resides in the same  
 > package, then you can use direct member access. Currently, in some  
 > places, the properties seem to be routing the message to the FO's  
 > logger, instead of using Property.log directly...

Or even worse - keeeping a reference to the FObj in question as a
member for the sole purpose of being able to call the getLogger()
method later on  - see LengthBase for example.

 > Well, who knows, maybe today's JVMs do inline instance methods if  
 > called by the instance itself. ;-)

Listening to what Neal Gafter had to say at Javapolis, the current
JVMs are doing a lot of clever optimizations. I'd expect something
as trivial as this to be covered in a lot of cases - but it's still
stupid design.

 > Don't worry, already cleaning up.

OK. When your changes are submitted and checked in, I'll update my
tree and submit a new patch for the properties fixes. The TXTHandler
looks to have been pretty badly broken by my fixes but everything
else should remain fine,

Regards,

Richard

Re: Loggers

[Andreas L Delmelle <a_...@pandora.be>]

On Jan 11, 2007, at 13:41, richardw@geoquip-rnd.demon.co.uk wrote:

>
> In FONode, it say:
>
>     //TODO Remove getLogger() method!
>
> Yet everywhere around the code base it says foo.getLogger(),
> in particular for FObj instances. What is the preferred way
> to aquire a logger instance?

log is a protected static, so if the class resides in the same  
package, then you can use direct member access. Currently, in some  
places, the properties seem to be routing the message to the FO's  
logger, instead of using Property.log directly... and now that you  
mention it, what strikes me as utterly absurd are the occurrences  
where getLogger() is used *to access the FObj logger from within an  
FObj*! 8-O ... Let me re-phrase: use an instance method to access a  
protected static member of the superclass. That's a good one! :-)
Well, who knows, maybe today's JVMs do inline instance methods if  
called by the instance itself. ;-)

Don't worry, already cleaning up.


Cheers,

Andreas