You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Richard Sitze <rs...@us.ibm.com> on 2003/03/03 05:06:47 UTC
Re: [logging] Class Loading Problems
I'm partially responsible for the current classloading scheme. I'd sure
like to understand what your problems are. Can you describe a
step-by-step scenario that demonstrates what you see happening, and why
you think it's not correct?
Likewise, for any code changes that you make, please help me understand
what you are doing differently, and why. Remember that it's important
that you preserve current behavior (fixing if broken is OK, changing
because you don't agree with it isn't... admittedly a subtle distinction,
but one I've gone to some effort to adhere to).
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
Hi,
this misunderstanding is not any kind of problem,
I yust do not know all convensions and have problems with my english.
I will try to fix this problem on weekend, it must trivial to solve for
some of situations,
proposed solution "class loader priority" will not wok 100%, but it will
work then "ThreadContextClassLoader" is
the "SystemClassLoader". All problems I have saw on user lists (problem in
logging and lang) are caused by
"SystemClassLoader" = "ThreadContextClassLoader", but
"AppLicationClassLoader" != "SystemClassLoader".
Howdy,
>>>can I add myself to logging comiters list and fix this problem ?
>>
>> No, you can't make yourself a committer. You are welcome to open bug
>
>A commons committer can participate in any common component.
I know -- it was my misunderstanding. I should've checked if the person
was already committer for other commons things. I apologize ;)
Yoav Shapira
Millennium ChemInformatics
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential,
proprietary
and/or privileged. This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else. If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender. Thank you.
---------------------------------------------------------------------
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: [logging] Class Loading Problems
Posted by Juozas Baliuka <ba...@centras.lt>.
I have added test, classloading scheme is not changed :
------------------------------ this must always work------------------------
Class cls = reload();
Thread.currentThread().setContextClassLoader(cls.getClassLoader());
execute(cls);
cls = reload();
Thread.currentThread().setContextClassLoader(null);
execute(cls);
--------------------------------this must fail if we will change
classloading scheme-----------------
cls = reload();
Thread.currentThread().setContextClassLoader(ClassLoader.getSystemClassLoade
r());
try{
execute(cls);
fail("SystemClassLoader");
}catch( LogConfigurationException ok ){
}
cls = reload();
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader(
));
try{
execute(cls);
fail("ContainerClassLoader");
}catch( LogConfigurationException ok ){
}
-------------------------------------------------------------------------
--------------
Lats two use cases emulate fatal bugs in container, but it is possible to
change classloder priority
and not to depend on container.
Log LOG = LogFactory.getLog(MyClass.class);//we know class loader in this
case
Problems was reported on tomcat,jrun and resin. There are three situations:
1. contener set ThreadContext loader to system class loader
2. some jdk implementation uses system class loader as default.
3. lame configuration.
----- Original Message -----
From: "Richard Sitze" <rs...@us.ibm.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, March 03, 2003 6:06 AM
Subject: Re: [logging] Class Loading Problems
> I'm partially responsible for the current classloading scheme. I'd sure
> like to understand what your problems are. Can you describe a
> step-by-step scenario that demonstrates what you see happening, and why
> you think it's not correct?
>
> Likewise, for any code changes that you make, please help me understand
> what you are doing differently, and why. Remember that it's important
> that you preserve current behavior (fixing if broken is OK, changing
> because you don't agree with it isn't... admittedly a subtle distinction,
> but one I've gone to some effort to adhere to).
>
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
>
>
>
>
> Hi,
> this misunderstanding is not any kind of problem,
> I yust do not know all convensions and have problems with my english.
> I will try to fix this problem on weekend, it must trivial to solve for
> some of situations,
> proposed solution "class loader priority" will not wok 100%, but it will
> work then "ThreadContextClassLoader" is
> the "SystemClassLoader". All problems I have saw on user lists (problem in
> logging and lang) are caused by
> "SystemClassLoader" = "ThreadContextClassLoader", but
> "AppLicationClassLoader" != "SystemClassLoader".
>
>
>
> Howdy,
>
> >>>can I add myself to logging comiters list and fix this problem ?
> >>
> >> No, you can't make yourself a committer. You are welcome to open bug
> >
> >A commons committer can participate in any common component.
>
> I know -- it was my misunderstanding. I should've checked if the person
> was already committer for other commons things. I apologize ;)
>
> Yoav Shapira
> Millennium ChemInformatics
>
>
>
>
> This e-mail, including any attachments, is a confidential business
> communication, and may contain information that is confidential,
> proprietary
> and/or privileged. This e-mail is intended only for the individual(s) to
> whom it is addressed, and may not be saved, copied, printed, disclosed or
> used by anyone else. If you are not the(an) intended recipient, please
> immediately delete this e-mail from your computer system and notify the
> sender. Thank you.
>
>
> ---------------------------------------------------------------------
> 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