AltRMI uses two commons comps now.  Attributes and HTTPClient.  Both require Commons Logging.  I'd prefer it if highly reusable beans dod not have logging, but hey I'm not the author of these.

I'm often asked what my objection is to logging APIs that are in the static camp rather than the IoC camp.  The answer is typically that they allow logging to be assigned on a per class basis and IoC affords per instance logging (if that is what the deployer wants).  If there were a ..

  interface CommonsLogEnabled {
    void enableLogging(Log log);
  }

.. I'd be over the moon.  Well, over the moon if people actually used the IoC interface rather than the established ..

  Log log = LogFactory.getLog(Blahhh.class);

.. design.  The trouble is that people would have to use it, which they will not.

What to do?  It is not as simple as you'd think in a container world.  Trees of classloaders are common, and it really complicates a logging picture.  On the client side static logging is just fine.  Fine that is unless you're looking to distribute your client as component, where the same IoC needs would be true.  Imagine each Eclipse plugin insisting on its own logging design :-(

Still, I'm looking forward to Joe's response.



blog comments powered by Disqus

Published

December 21st, 2002
Reads:

Tags