You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Paul Hammant <Pa...@yahoo.com> on 2003/03/02 13:48:43 UTC
Re: [Attributes] dependancy on Logging
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).
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
Re: [Attributes] dependancy on Logging
Posted by Paul Hammant <Pa...@yahoo.com>.
Juozas,
>>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 ?
>
>
>
My problem is simple, I do not want to have to distribute
commons-logging for because attributes depends on it. I do not want to
distribute it becuase it will never get called. It is a compilation
dependency only.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Attributes] dependancy on Logging
Posted by Paul Hammant <Pa...@yahoo.com>.
Juozas,
>>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
>>
>>
>
>I do not like this kind of workarounds too, but some containers heve
>problems with this, I do not have any problems
>myself, but there are a lot reports from users.
>Possible some users have problems to configure container and workarounds
>will not help.
>
>
>
You guys chat amongst yourselves if you like.
I don't want to use common logging for a _single_ (nearly-never-called)
warning. That is my reason, and nothing to do with context-classloader.....
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Attributes] dependancy on Logging
Posted by Juozas Baliuka <ba...@centras.lt>.
<snip>
> 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
I do not like this kind of workarounds too, but some containers heve
problems with this, I do not have any problems
myself, but there are a lot reports from users.
Possible some users have problems to configure container and workarounds
will not help.
>
>
> >
> >
> > >
> > > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Attributes] dependancy on Logging
Posted by Max Rydahl Andersen <ma...@eos.dk>.
> > 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
Re: [Attributes] dependancy on Logging
Posted by Juozas Baliuka <ba...@centras.lt>.
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: 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