I'm new this part of the game (classloaders), but I'm becoming more and
more aware of the issues. So, I'd like to add to your question some bigger
issues surrounding the placement of commons-logging & other apache
utility/libraries in web application servers:
1. How do we find & overload factories (I think this is the issue you set
forth below)?
2. How do we find & overload resources in general (NLS
messaging/properties files)?
3. How do we configure (NOT System properties as we do today - that has
global implications)?
The fundamental problem I have is how do we sync classloader mechanisms
with other algorithms in common use (including the logger): try resource
named "resource", then try resouce named "package.resource". This last one
conflicts with classloader in application servers because what we get is:
1. Classloader(s) look for "resource" in application context
2. Classloader(s) look for "resource" in system context
3. Classloader(s) look for "package.resource" in application context
4. Classloader(s) look for "package.resource" in system context
but what we want is:
1. Classloader(s) look for "resource" in application context
2. Classloader(s) look for "package.resource" in application context
3. Classloader(s) look for "resource" in system context
4. Classloader(s) look for "package.resource" in system context
I think we may need to design a solution, and - of course - provide an
implementation as part of the commons project. If there are answers out
there, I'd like to see them in a developers guide (common-doc - general
guidelines?)
<ras>
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
[EMAIL PROTECTED]
To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
06/06/2002 01:08
cc: List Tomcat-Dev <[EMAIL PROTECTED]> PM
Subject: Logging: more classloader problems.
Please respond to "Jakarta Commons Developers List"
The problem: it won't work if commons-logging.jar is installed in the
parent class loader, and log4j.jar ( or another logger ) is installed in
a child loader ( like WEB-INF/lib ).
What happens:
- the factory uses the thread class loader to check if the log4j (
or any other impl. ) exists ( and it does ).
- it creates an instance of the Logger adapter. This will be created
using parent loader ( the one that loads commons-logging ).
- the Logger instance makes references to Category or other classes
that are used in it's implementation. End of story, since the
class loader can't find the reference.
This works fine for JAXP because the adapter for a parser is part of the
parser jar. It doesn't work for c-l because the adapter is in the
root loader ( with the API), not with the logging impl.
That doesn't affect people who just use a single logger or can put
the logger impl. in the same place with common-logging. It only
affect containers like tomcat, when you want to let each webapp
use it's own logger impl. of choice.
I tried all kind of introspection games, it won't work. The only solution
I see is to make sure the adapters are in the same place with the logger.
Solution:
Split commons-logging.jar in commons-logging-api.jar ( only the API and
the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar.
Alternatively, leave commons-logging.jar as it is and create a second
commons-logging-api.jar.
The -api will be included in the common loader. Each webapp will have to
include commons-logging.jar ( or -impl ), and it's own logger.
Or course, the best would be to have the adapter included in the
logger impl.
What do you think ? Craig, Remy can we make another c-l dot release with
this change ? ( I'll do some more testing to see how it works )
Costin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED].
org>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED].
org>
--1__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
<html><body>I'm new this part of the game (classloaders), but I'm becoming
more and more aware of the issues. So, I'd like to add to your question
some bigger issues surrounding the placement of commons-logging & other
apache utility/libraries in web application servers:<br>
<br>
1. How do we find & overload factories (I think this is the issue you
set forth below)?<br>
2. How do we find & overload resources in general (NLS
messaging/properties files)?<br>
3. How do we configure (NOT System properties as we do today - that has
global implications)?<br>
<br>
The fundamental problem I have is how do we sync classloader mechanisms
with other algorithms in common use (including the logger): try resource
named "resource", then try resouce named "package.
resource". This last one conflicts with classloader in application
servers because what we get is:<br>
1. Classloader(s) look for "resource" in application
context<br>
2. Classloader(s) look for "resource" in system context<br>
3. Classloader(s) look for "package.resource" in
application context<br>
4. Classloader(s) look for "package.resource" in system
context<br>
<br>
but what we want is:<br>
<br>
1. Classloader(s) look for "resource" in application
context<br>
2. Classloader(s) look for "package.resource" in
application context<br>
3. Classloader(s) look for "resource" in system context<br>
4. Classloader(s) look for "package.resource" in system
context<br>
<br>
I think we may need to design a solution, and - of course - provide an
implementation as part of the commons project. If there are answers out
there, I'd like to see them in a developers guide (common-doc - general
guidelines?)<br>
<ras><br>
<br>
*******************************************<br>
Richard A. Sitze [EMAIL PROTECTED]<br>
CORBA Interoperability & WebServices<br>
IBM WebSphere Development<br>
<img src="cid:[EMAIL PROTECTED]"; width="16"
height="16" alt="">[EMAIL PROTECTED]<br>
<br>
<br>
<table V5DOTBL=true width="100%" border="0" cellspacing="0"
cellpadding="0">
<tr valign="top"><td width="1%"><img src="cid:
[EMAIL PROTECTED]" border="0" height="1"
width="72" alt=""><br>
</td><td style="background-image:url(cid:
[EMAIL PROTECTED]); background-repeat: no-
repeat; " width="1%"><img src="cid:20__=09BBE143DFF5E87F8f9e8a93df938@us.
ibm.com" border="0" height="1" width="220" alt=""><br>
<ul>
<ul>
<ul>
<ul><b><font size="2">[EMAIL PROTECTED]</font></b>
<p><font size="2">06/06/2002 01:08 PM</font><br>
<font size="2">Please respond to "Jakarta Commons Developers
List"</font></ul>
</ul>
</ul>
</ul>
</td><td width="100%"><img src="cid:20__=09BBE143DFF5E87F8f9e8a93df938@us.
ibm.com" border="0" height="1" width="1" alt=""><br>
<font size="1" face="Arial"> </font><br>
<font size="2"> To: </font><font size="2">Jakarta Commons Developers List
<[EMAIL PROTECTED]></font><br>
<font size="2"> cc: </font><font size="2">List Tomcat-Dev <tomcat-
[EMAIL PROTECTED]></font><br>
<font size="2"> Subject: </font><font size="2">Logging: more classloader
problems.</font><br>
<br>
<font size="1" face="Arial"> </font></td></tr>
</table>
<br>
<br>
<tt><br>
The problem: it won't work if commons-logging.jar is installed in the <br>
parent class loader, and log4j.jar ( or another logger ) is installed in
<br>
a child loader ( like WEB-INF/lib ).<br>
<br>
What happens:<br>
- the factory uses the thread class loader to check if the log4j ( <br>
or any other impl. ) exists ( and it does ).<br>
<br>
- it creates an instance of the Logger adapter. This will be created<br>
using parent loader ( the one that loads commons-logging ).<br>
<br>
- the Logger instance makes references to Category or other classes<br>
that are used in it's implementation. End of story, since the <br>
class loader can't find the reference.<br>
<br>
This works fine for JAXP because the adapter for a parser is part of the
<br>
parser jar. It doesn't work for c-l because the adapter is in the <br>
root loader ( with the API), not with the logging impl.<br>
<br>
That doesn't affect people who just use a single logger or can put<br>
the logger impl. in the same place with common-logging. It only <br>
affect containers like tomcat, when you want to let each webapp<br>
use it's own logger impl. of choice.<br>
<br>
I tried all kind of introspection games, it won't work. The only
solution<br>
I see is to make sure the adapters are in the same place with the logger.
<br>
<br>
Solution:<br>
Split commons-logging.jar in commons-logging-api.jar ( only the API and<br>
the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. <br>
<br>
Alternatively, leave commons-logging.jar as it is and create a second<br>
commons-logging-api.jar.<br>
<br>
The -api will be included in the common loader. Each webapp will have
to<br>
include commons-logging.jar ( or -impl ), and it's own logger. <br>
<br>
Or course, the best would be to have the adapter included in the <br>
logger impl.<br>
<br>
What do you think ? Craig, Remy can we make another c-l dot release with
<br>
this change ? ( I'll do some more testing to see how it works )<br>
<br>
Costin<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
To unsubscribe, e-mail: <</tt><tt><a href="mailto:commons-dev-
[EMAIL PROTECTED]">mailto:commons-dev-unsubscribe@jakarta.
apache.org</a></tt><tt>><br>
For additional commands, e-mail: <</tt><tt><a href="mailto:commons-dev-
[EMAIL PROTECTED]">mailto:[EMAIL PROTECTED]
</a></tt><tt>><br>
<br>
</tt></body></html>
--1__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F--
--0__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F
Content-type: image/gif;
name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <[EMAIL PROTECTED]>
Content-transfer-encoding: base64
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
--0__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F
Content-type: image/gif;
name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <[EMAIL PROTECTED]>
Content-transfer-encoding: base64
R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7
--0__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F--
