2007/7/17, Niclas Hedhman <[EMAIL PROTECTED]>:
> On Monday 16 July 2007 23:35, Damian Gołda wrote:
>
> > So maybe it would be good idea to put that one class to pax.logging.jcl ?
> > And export package org.apache.commons.logging.impl ?
> >
> > What do you think?
>
> Hmmm.... I don't really like that.
>
> > Or any alternative solutions?
>
> Either;
> 1. You can stick such a class into your own bundle and export it, since Pax
> Logging does not export ...impl .
Yes, of course I cane create own private bundle.
But people may be surprised: I have commons-digester, replace jcl to
pax logging and have "missing import error"?!
Maybe it should be additional "digester compatibility" jar in pax logging?
>
> 2. We could create a better Commons-Digester bundle which contains this class
> internally.
Could be. Where is the place to put our bundles with 3rd party libraries?
>
> And I also think one should take a closer look at Commons-Digester and
> see "why" it does this. Perhaps this happens in some classes that should not
> be included in the bundle.
Package org.apache.commons.logging.impl (precisely class NoOpLog) is
used only in one place, class LogUtils:
class LogUtils {
/**
* Get the Log object associated with the specified Digester instance,
* or a "no-op" logging object if the digester reference is null.
* <p>
* You should use this method instead of digester.getLogger() in
* any situation where the digester might be null.
*/
static Log getLogger(Digester digester) {
if (digester == null) {
return new org.apache.commons.logging.impl.NoOpLog();
}
return digester.getLogger();
}
}
It is completely stupid, because they can use own "no operation"
implementation of Log interface, instead of importing from jcl impl.
It applies to version 1.7 of digester, which I have to use.
--
Damian
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
