commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <si...@ecnetwork.co.nz>
Subject Re: [digester] TO-DO for release 1.6
Date Wed, 14 Apr 2004 00:33:42 GMT
On Wed, 2004-04-14 at 10:09, robert burrell donkin wrote:
> i've been thinking about LogUtils. often, improved factoring of the 
> code allows further improvements. i'd prefer to allow the user more 
> flexibility in their choice of logging and i'd like to add this before 
> the 1.6 release (which i assume includes the refactored plugin stuff).
> 
> i think that we can preserve the default behaviour by calling the 
> plugin context to provide the log implementation. if we get the 
> signature right, it should be possible to allow per-class logging (as 
> an option). we may need to consider whether it would be better to 
> factor out a separate log provider class exposed by a property or just 
> add the call to the context (and then expect users to subclass).
> 
> if this sounds a good plan (and you don't fancy implementing it 
> yourself), let me know and i'll post a patch tomorrow.

Please go ahead. I'll look for your patch later.

However here are what I think the requirements are for a *real* solution
to digester logging:

* There should be no performance penalty for "normal" users, ie the
  99.999% of them that don't redirect logging on a per-digester basis.
* Code should always log using a category that matches the logging
  class name. Under normal use, the underlying logging framework should
  be told the correct category so it can correctly filter. Under
  "redirected" logging, it is desirable for the underlying framework to
  be told the correct category but if a solution can be found that ends
  up "losing" this info, I would be happy, as I don't really care if
  "redirected" logging is actually useable or not. 
* Code should be able to declare
      private static Log log = LogFactory.getLog(this.class);
  because this is much more efficient than retrieving the logger by
  category name each time. 
* Code should be able to log even when it doesn't have a reference to
  a digester object (or a PluginContext object or whatever). This allows
  classes to log *before* they have an associated digester object, and
  means that classes which *never* have an explicit reference to their
  associated digester can still log.
* When Digester code calls into BeanUtils, and BeanUtils outputs a log
  message, that message should also be redirected to whatever 
  destination the calling digester instance logging is being sent to.
* When Digester code calls into user-written rules and they log, that
  message should also be redirected to whatever destination the
  calling digester instance logging is being sent to.

The current logging approach of Digester fails every one of the above.

I believe the only solution that satisfies all the above involves
writing custom commons-logging LogFactory/Log classes, and redirecting
the logging at that level in a manner which makes the logging
redirection totally transparent to the calling code. Normal code just
uses standard commons-logging, so gets standard behaviour. Code that
wants redirection sets up commons-logging with the custom LogFactory
etc. And if it's totally transparent to the logging code, then the
problem has been solved without any "LogUtils" module so any work done
now on "LogUtils" classes or similar becomes obsolete.

I spent a full day recently experimenting with common-logging, and made
some progress. But a lot more time needs to be spent on this to get the
commons-logging-based solution right, and I would prefer to do that in
the 1.7 cycle rather than tackle it for 1.6. Of course someone more
familiar with commons-logging than me could possibly solve it faster.


Despite all the above, if you have something in mind which is an
improvement on the current logging approach for digester, even if it
doesn't meet 100% of the above requirements then that would be cool. I
look forward to seeing your patch.


Cheers,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message