commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject RE: Logging: more classloader problems.
Date Thu, 06 Jun 2002 21:54:52 GMT
On Thu, 6 Jun 2002, Richard Sitze wrote:

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

There is a simple answer: dump everything in rt.jar, and you'll have no 
class loader problems :-) But we have to wait for JDK1.5 for that.

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

For 2 - it is _essential_ to use the right ResourceBundle method ( the
one with a loader parameter ), and pass the thread class loader ( or the
loader for a class that is in the same .jar - same thing ). That doesn't
work if you want JDK1.1 compat, in which case all .properties must be in
the top loader.

For 1 - that's pretty much what JAXP and commons-logging is doing to
locate the factory. Or you can use an explicit setting - but make
sure you use the thread class loader for everything.

I don't understand 3, but in general System properties shouldn't be
used for anything but simple apps ( i.e. not in a server env ). 
A simple config file ( .properties or xml ) should be used. Of course,
System props are a quick fix and are probably ok for special cases,
but don't expect them to scale.


> 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

Not sure who is doing this - are you talking about resource bundles or 
something else ? Most packages I know look for a single name.

To get a different behavior you must look explicitely in the class 
loaders ( but remember that a child will ask the parent ).


Costin

> 
> 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            rsitze@us.ibm.com
> CORBA Interoperability & WebServices
> IBM WebSphere Development
> 
> 
> 
> costinm@covalent.net
> To:      Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> 06/06/2002 01:08
> cc:      List Tomcat-Dev <tomcat-dev@jakarta.apache.org> 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:commons-dev-unsubscribe@jakarta.apache.
> org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
> 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 &amp; other
> apache utility/libraries in web application servers:<br>
> <br>
> 1.  How do we find &amp; overload factories (I think this is the issue you
> set forth below)?<br>
> 2.  How do we find &amp; 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 &quot;resource&quot;, then try resouce named &quot;package.
> resource&quot;.  This last one conflicts with classloader in application
> servers because what we get is:<br>
>      1.  Classloader(s) look for &quot;resource&quot; in application
> context<br>
>      2.  Classloader(s) look for &quot;resource&quot; in system context<br>
>      3.  Classloader(s) look for &quot;package.resource&quot; in
> application context<br>
>      4.  Classloader(s) look for &quot;package.resource&quot; in system
> context<br>
> <br>
> but what we want is:<br>
> <br>
>      1.  Classloader(s) look for &quot;resource&quot; in application
> context<br>
>      2.  Classloader(s) look for &quot;package.resource&quot; in
> application context<br>
>      3.  Classloader(s) look for &quot;resource&quot; in system context<br>
>      4.  Classloader(s) look for &quot;package.resource&quot; 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>
> &lt;ras&gt;<br>
> <br>
> *******************************************<br>
> Richard A. Sitze            rsitze@us.ibm.com<br>
> CORBA Interoperability &amp; WebServices<br>
> IBM WebSphere Development<br>
> <img src="cid:10__=09BBE143DFF5E87F8f9e8a93df938@us.ibm.com" width="16"
> height="16" alt="">costinm@covalent.net<br>
> <br>
> <br>
> 
> <table V5DOTBL=true width="100%" border="0" cellspacing="0"
> cellpadding="0">
> <tr valign="top"><td width="1%"><img src="cid:
> 20__=09BBE143DFF5E87F8f9e8a93df938@us.ibm.com" border="0" height="1"
> width="72" alt=""><br>
> </td><td style="background-image:url(cid:
> 30__=09BBE143DFF5E87F8f9e8a93df938@us.ibm.com); 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">costinm@covalent.net</font></b>
> <p><font size="2">06/06/2002 01:08 PM</font><br>
> <font size="2">Please respond to &quot;Jakarta Commons Developers
> List&quot;</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
> &lt;commons-dev@jakarta.apache.org&gt;</font><br>
> <font size="2"> cc: </font><font size="2">List Tomcat-Dev &lt;tomcat-
> dev@jakarta.apache.org&gt;</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: &nbsp; &lt;</tt><tt><a href="mailto:commons-dev-
> unsubscribe@jakarta.apache.org">mailto:commons-dev-unsubscribe@jakarta.
> apache.org</a></tt><tt>&gt;<br>
> For additional commands, e-mail: &lt;</tt><tt><a href="mailto:commons-dev-
> help@jakarta.apache.org">mailto:commons-dev-help@jakarta.apache.org
> </a></tt><tt>&gt;<br>
> <br>
> </tt></body></html>
> 
> --1__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F--
> 
> 
> --0__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F
> Content-type: image/gif;
> name="graycol.gif"
> Content-Disposition: inline; filename="graycol.gif"
> Content-ID: <10__=09BBE143DFF5E87F8f9e8a93df938@us.ibm.com>
> 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: <20__=09BBE143DFF5E87F8f9e8a93df938@us.ibm.com>
> Content-transfer-encoding: base64
> 
> R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7
> 
> --0__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F--


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message