commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Rydahl Andersen" <...@eos.dk>
Subject Re: [Attributes] dependancy on Logging
Date Sun, 02 Mar 2003 19:12:27 GMT
> > 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 ?

Why does people get in to trouble when depending on ThreadContext
classloader which is
the correct way to load classes with (if one want to be container friendly
:)

Depending on ThreadContext classloader will work if the container follows
the spec - and if there
are no TCL, then use class.forname - but remmeber to do it from a
method/class that is loaded
with your classes own classloader ....

/max


>
>
> >
> > 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
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