Hi,
> Hi folks,
>
> Can we consider one of two solutions for this _single_ use of commons
> logging
>
> 1) Removal of the commons-logging from attributes?
>
> 2) Backwards compatible rework that will allow the application to run
> without commons logging in the classpath (or classloader tree for
> complex deployments).
I undersatnd this single use is not pragmatic, do you have problems with
classloading in logging ?
I have promissed to fix class loading in this component, it depends on
ThreadContext classloader and
it was a problem with this strategy in phoenix a year ago.
logging works on phoenix at this time, does not it ?
>
> Can I have some opinions here, or should I just dive in, make a change
> and wait for the flak?
>
> Regards,
>
> - Paul
>
> > Folks,
> >
> > In Attributes.java, there is a single use of commons logging :
> >
> > public static AttributeFinder getAttributeFinder() {
> > ....
> > } catch (Exception e) {
> > logger.warn("failed to initialize specified implementation " +
> > "of AttributeFinder, using default", e);
> > }
> > ....
> > }
> >
> > Is there a chance that we could eliminate this use given that the
> > system recovers with the instantiation of a default AttributeFinder ?
> >
> > It would be really useful :-)
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
