You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Mike Perham (JIRA)" <ji...@apache.org> on 2007/01/04 17:26:27 UTC
[jira] Created: (GERONIMO-2693) Application classloader contains a
massive number of duplicate classpath entries
Application classloader contains a massive number of duplicate classpath entries
--------------------------------------------------------------------------------
Key: GERONIMO-2693
URL: https://issues.apache.org/jira/browse/GERONIMO-2693
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: kernel
Affects Versions: 1.1.1
Environment: WAS CE 1.1.0.1
Reporter: Mike Perham
I have an EAR with an MDB jar and two WARs. The EAR contains a large number of jars within a lib directory. The wars and ejb-jar all contain MANIFEST.MF Class-Path entries which reference those jars within lib/.
When I print out my WAR classpath, I get output attached. The duplications don't really matter all that much except for the duplications due to non-canonicalized paths:
jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/lib/fabric-gov-api-1.4.0.jar!/META-INF
jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/fabric-tools-web.war/../lib/fabric-gov-api-1.4.0.jar!/META-INF
If I do a getResources("foo") and that gov-api jar has a foo resource, the system will think there are two foo resources when in fact there is only one, due to different URLs for the same resource. As a result, for instance, this causes Apache Hivemind to blow up with an error due to it thinking a component jar is doubly defined in the classpath.
I'm unclear why Geronimo is adding all the lib jars to my classpath without my asking. It seems like the various J2EE modules should be able to control their own classpath wrt jars in the ear.
This is a blocker preventing us from using our application on WAS CE.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2693) Application classloader contains a
massive number of duplicate classpath entries
Posted by "Mike Perham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Perham updated GERONIMO-2693:
----------------------------------
Attachment: cpath.txt
> Application classloader contains a massive number of duplicate classpath entries
> --------------------------------------------------------------------------------
>
> Key: GERONIMO-2693
> URL: https://issues.apache.org/jira/browse/GERONIMO-2693
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: kernel
> Affects Versions: 1.1.1
> Environment: WAS CE 1.1.0.1
> Reporter: Mike Perham
> Attachments: cpath.txt
>
>
> I have an EAR with an MDB jar and two WARs. The EAR contains a large number of jars within a lib directory. The wars and ejb-jar all contain MANIFEST.MF Class-Path entries which reference those jars within lib/.
> When I print out my WAR classpath, I get output attached. The duplications don't really matter all that much except for the duplications due to non-canonicalized paths:
> jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/lib/fabric-gov-api-1.4.0.jar!/META-INF
> jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/fabric-tools-web.war/../lib/fabric-gov-api-1.4.0.jar!/META-INF
> If I do a getResources("foo") and that gov-api jar has a foo resource, the system will think there are two foo resources when in fact there is only one, due to different URLs for the same resource. As a result, for instance, this causes Apache Hivemind to blow up with an error due to it thinking a component jar is doubly defined in the classpath.
> I'm unclear why Geronimo is adding all the lib jars to my classpath without my asking. It seems like the various J2EE modules should be able to control their own classpath wrt jars in the ear.
> This is a blocker preventing us from using our application on WAS CE.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2693) Application classloader contains a
massive number of duplicate classpath entries
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks reassigned GERONIMO-2693:
--------------------------------------
Assignee: David Jencks
> Application classloader contains a massive number of duplicate classpath entries
> --------------------------------------------------------------------------------
>
> Key: GERONIMO-2693
> URL: https://issues.apache.org/jira/browse/GERONIMO-2693
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: kernel
> Affects Versions: 1.1.1
> Environment: WAS CE 1.1.0.1
> Reporter: Mike Perham
> Assigned To: David Jencks
> Attachments: cpath.txt
>
>
> I have an EAR with an MDB jar and two WARs. The EAR contains a large number of jars within a lib directory. The wars and ejb-jar all contain MANIFEST.MF Class-Path entries which reference those jars within lib/.
> When I print out my WAR classpath, I get output attached. The duplications don't really matter all that much except for the duplications due to non-canonicalized paths:
> jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/lib/fabric-gov-api-1.4.0.jar!/META-INF
> jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/fabric-tools-web.war/../lib/fabric-gov-api-1.4.0.jar!/META-INF
> If I do a getResources("foo") and that gov-api jar has a foo resource, the system will think there are two foo resources when in fact there is only one, due to different URLs for the same resource. As a result, for instance, this causes Apache Hivemind to blow up with an error due to it thinking a component jar is doubly defined in the classpath.
> I'm unclear why Geronimo is adding all the lib jars to my classpath without my asking. It seems like the various J2EE modules should be able to control their own classpath wrt jars in the ear.
> This is a blocker preventing us from using our application on WAS CE.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2693) Application classloader contains a
massive number of duplicate classpath entries
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks updated GERONIMO-2693:
-----------------------------------
Attachment: GERONIMO-2693.patch
the attached patch doesn't scan geronimo classloaders more than once from findResources and I think fixes the unnormailized path problem. The system classloader still gets scanned many times.
> Application classloader contains a massive number of duplicate classpath entries
> --------------------------------------------------------------------------------
>
> Key: GERONIMO-2693
> URL: https://issues.apache.org/jira/browse/GERONIMO-2693
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: kernel
> Affects Versions: 1.1.1
> Environment: WAS CE 1.1.0.1
> Reporter: Mike Perham
> Assigned To: David Jencks
> Attachments: cpath.txt, GERONIMO-2693.patch
>
>
> I have an EAR with an MDB jar and two WARs. The EAR contains a large number of jars within a lib directory. The wars and ejb-jar all contain MANIFEST.MF Class-Path entries which reference those jars within lib/.
> When I print out my WAR classpath, I get output attached. The duplications don't really matter all that much except for the duplications due to non-canonicalized paths:
> jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/lib/fabric-gov-api-1.4.0.jar!/META-INF
> jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/fabric-tools-web.war/../lib/fabric-gov-api-1.4.0.jar!/META-INF
> If I do a getResources("foo") and that gov-api jar has a foo resource, the system will think there are two foo resources when in fact there is only one, due to different URLs for the same resource. As a result, for instance, this causes Apache Hivemind to blow up with an error due to it thinking a component jar is doubly defined in the classpath.
> I'm unclear why Geronimo is adding all the lib jars to my classpath without my asking. It seems like the various J2EE modules should be able to control their own classpath wrt jars in the ear.
> This is a blocker preventing us from using our application on WAS CE.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2693) Application classloader contains
a massive number of duplicate classpath entries
Posted by "Mike Perham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462241 ]
Mike Perham commented on GERONIMO-2693:
---------------------------------------
You can easily print out your own classpath with this elegant hack. :-)
Enumeration e = Thread.currentThread().getContextClassLoader().getResources("META-INF");
List entries = Collections.list(e);
> Application classloader contains a massive number of duplicate classpath entries
> --------------------------------------------------------------------------------
>
> Key: GERONIMO-2693
> URL: https://issues.apache.org/jira/browse/GERONIMO-2693
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: kernel
> Affects Versions: 1.1.1
> Environment: WAS CE 1.1.0.1
> Reporter: Mike Perham
> Attachments: cpath.txt
>
>
> I have an EAR with an MDB jar and two WARs. The EAR contains a large number of jars within a lib directory. The wars and ejb-jar all contain MANIFEST.MF Class-Path entries which reference those jars within lib/.
> When I print out my WAR classpath, I get output attached. The duplications don't really matter all that much except for the duplications due to non-canonicalized paths:
> jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/lib/fabric-gov-api-1.4.0.jar!/META-INF
> jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/fabric-tools-web.war/../lib/fabric-gov-api-1.4.0.jar!/META-INF
> If I do a getResources("foo") and that gov-api jar has a foo resource, the system will think there are two foo resources when in fact there is only one, due to different URLs for the same resource. As a result, for instance, this causes Apache Hivemind to blow up with an error due to it thinking a component jar is doubly defined in the classpath.
> I'm unclear why Geronimo is adding all the lib jars to my classpath without my asking. It seems like the various J2EE modules should be able to control their own classpath wrt jars in the ear.
> This is a blocker preventing us from using our application on WAS CE.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2693) Application classloader contains a
massive number of duplicate classpath entries
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks resolved GERONIMO-2693.
------------------------------------
Resolution: Fixed
Fix Version/s: 2.0-beta1
I think this is fixed in trunk in rev 518426. I'd rather there was a test, especially for the non-normailized urls Mike was seeing. This issue was making jetty start at less than a snails pace due to its search for tlds, and fixing it considerably speeds up jetty's startup.
> Application classloader contains a massive number of duplicate classpath entries
> --------------------------------------------------------------------------------
>
> Key: GERONIMO-2693
> URL: https://issues.apache.org/jira/browse/GERONIMO-2693
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: kernel
> Affects Versions: 1.1.1
> Environment: WAS CE 1.1.0.1
> Reporter: Mike Perham
> Assigned To: David Jencks
> Fix For: 2.0-beta1
>
> Attachments: cpath.txt, GERONIMO-2693.patch
>
>
> I have an EAR with an MDB jar and two WARs. The EAR contains a large number of jars within a lib directory. The wars and ejb-jar all contain MANIFEST.MF Class-Path entries which reference those jars within lib/.
> When I print out my WAR classpath, I get output attached. The duplications don't really matter all that much except for the duplications due to non-canonicalized paths:
> jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/lib/fabric-gov-api-1.4.0.jar!/META-INF
> jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/fabric-tools-web.war/../lib/fabric-gov-api-1.4.0.jar!/META-INF
> If I do a getResources("foo") and that gov-api jar has a foo resource, the system will think there are two foo resources when in fact there is only one, due to different URLs for the same resource. As a result, for instance, this causes Apache Hivemind to blow up with an error due to it thinking a component jar is doubly defined in the classpath.
> I'm unclear why Geronimo is adding all the lib jars to my classpath without my asking. It seems like the various J2EE modules should be able to control their own classpath wrt jars in the ear.
> This is a blocker preventing us from using our application on WAS CE.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.