You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Michael Lipp (JIRA)" <je...@portals.apache.org> on 2005/05/31 11:40:55 UTC
[jira] Created: (JS2-274) Digester uses wrong class loader
Digester uses wrong class loader
--------------------------------
Key: JS2-274
URL: http://issues.apache.org/jira/browse/JS2-274
Project: Jetspeed 2
Type: Bug
Components: Other
Versions: 2.0-M3
Environment: Linux/JBoss
Reporter: Michael Lipp
Attachments: patch.txt
I'm trying to pack Jetspeed2 in an EAR. The basic setup is: all libraries that are "shared" in Tomcat become client modules in the EAR (so they are "common" components in the classpath of all WAR modules). Libraries in WEB-INF/lib take precedence (as specified for servlets). Xerces, Xalan and xml-apis have been removed from the WARs; latest versions are configured using the endorsed libraries mechanisms as recommended (besides not being compliant to the mechanism's specification, having individual XML libraries in every WAR's/PA's classloader consumes a lot of memory).
In this environment I find that the Digester cannot load all classes. By default, the digester uses its own class loader to lookup class in the ObjectCreateRule. This should work if the digester can only be found in the WAR's WEB-INF/lib. This does not seem to be the case. I haven't tracked down why (propably it is due to the use of "common" XML libraries which causes the Digester class in the Tomcat container to be used). As class loaders are explicitly passed around in Jetspeed, they should be used anyway and used to configure the Digester. Where explicit classloaders are not available, the context class loader should be used. I have provided a patch against M3.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Assigned: (JS2-274) Digester uses wrong class loader
Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-274?page=all ]
David Sean Taylor reassigned JS2-274:
-------------------------------------
Assign To: David Sean Taylor
> Digester uses wrong class loader
> --------------------------------
>
> Key: JS2-274
> URL: http://issues.apache.org/jira/browse/JS2-274
> Project: Jetspeed 2
> Type: Bug
> Components: Other
> Versions: 2.0-M3
> Environment: Linux/JBoss
> Reporter: Michael Lipp
> Assignee: David Sean Taylor
> Attachments: better-patch.txt, patch.txt
>
> I'm trying to pack Jetspeed2 in an EAR. The basic setup is: all libraries that are "shared" in Tomcat become client modules in the EAR (so they are "common" components in the classpath of all WAR modules). Libraries in WEB-INF/lib take precedence (as specified for servlets). Xerces, Xalan and xml-apis have been removed from the WARs; latest versions are configured using the endorsed libraries mechanisms as recommended (besides not being compliant to the mechanism's specification, having individual XML libraries in every WAR's/PA's classloader consumes a lot of memory).
> In this environment I find that the Digester cannot load all classes. By default, the digester uses its own class loader to lookup class in the ObjectCreateRule. This should work if the digester can only be found in the WAR's WEB-INF/lib. This does not seem to be the case. I haven't tracked down why (propably it is due to the use of "common" XML libraries which causes the Digester class in the Tomcat container to be used). As class loaders are explicitly passed around in Jetspeed, they should be used anyway and used to configure the Digester. Where explicit classloaders are not available, the context class loader should be used. I have provided a patch against M3.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-274) Digester uses wrong class loader
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-274?page=comments#action_12314220 ]
Michael Lipp commented on JS2-274:
----------------------------------
Maybe my comment was misleading: the better patch is there (better-patch.txt). I'm running Jetspeed bundled in an EAR for two weeks now, so you can call it well tested. I'd be grateful if someone could review and apply this (would reduce the diffs I have to track in my source tree).
> Digester uses wrong class loader
> --------------------------------
>
> Key: JS2-274
> URL: http://issues.apache.org/jira/browse/JS2-274
> Project: Jetspeed 2
> Type: Bug
> Components: Other
> Versions: 2.0-M3
> Environment: Linux/JBoss
> Reporter: Michael Lipp
> Attachments: better-patch.txt, patch.txt
>
> I'm trying to pack Jetspeed2 in an EAR. The basic setup is: all libraries that are "shared" in Tomcat become client modules in the EAR (so they are "common" components in the classpath of all WAR modules). Libraries in WEB-INF/lib take precedence (as specified for servlets). Xerces, Xalan and xml-apis have been removed from the WARs; latest versions are configured using the endorsed libraries mechanisms as recommended (besides not being compliant to the mechanism's specification, having individual XML libraries in every WAR's/PA's classloader consumes a lot of memory).
> In this environment I find that the Digester cannot load all classes. By default, the digester uses its own class loader to lookup class in the ObjectCreateRule. This should work if the digester can only be found in the WAR's WEB-INF/lib. This does not seem to be the case. I haven't tracked down why (propably it is due to the use of "common" XML libraries which causes the Digester class in the Tomcat container to be used). As class loaders are explicitly passed around in Jetspeed, they should be used anyway and used to configure the Digester. Where explicit classloaders are not available, the context class loader should be used. I have provided a patch against M3.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-274) Digester uses wrong class loader
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-274?page=comments#action_66608 ]
Michael Lipp commented on JS2-274:
----------------------------------
Just noticed that I got it wrong. In most cases the digester needs the class loader of the class that prepares it, because the class loader of this class also knows how to find the classes that represent the parsed structure. Going to provide a better patch shortly (still testing).
> Digester uses wrong class loader
> --------------------------------
>
> Key: JS2-274
> URL: http://issues.apache.org/jira/browse/JS2-274
> Project: Jetspeed 2
> Type: Bug
> Components: Other
> Versions: 2.0-M3
> Environment: Linux/JBoss
> Reporter: Michael Lipp
> Attachments: patch.txt
>
> I'm trying to pack Jetspeed2 in an EAR. The basic setup is: all libraries that are "shared" in Tomcat become client modules in the EAR (so they are "common" components in the classpath of all WAR modules). Libraries in WEB-INF/lib take precedence (as specified for servlets). Xerces, Xalan and xml-apis have been removed from the WARs; latest versions are configured using the endorsed libraries mechanisms as recommended (besides not being compliant to the mechanism's specification, having individual XML libraries in every WAR's/PA's classloader consumes a lot of memory).
> In this environment I find that the Digester cannot load all classes. By default, the digester uses its own class loader to lookup class in the ObjectCreateRule. This should work if the digester can only be found in the WAR's WEB-INF/lib. This does not seem to be the case. I haven't tracked down why (propably it is due to the use of "common" XML libraries which causes the Digester class in the Tomcat container to be used). As class loaders are explicitly passed around in Jetspeed, they should be used anyway and used to configure the Digester. Where explicit classloaders are not available, the context class loader should be used. I have provided a patch against M3.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Resolved: (JS2-274) Digester uses wrong class loader
Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-274?page=all ]
David Sean Taylor resolved JS2-274:
-----------------------------------
Resolution: Fixed
patch applied
> Digester uses wrong class loader
> --------------------------------
>
> Key: JS2-274
> URL: http://issues.apache.org/jira/browse/JS2-274
> Project: Jetspeed 2
> Type: Bug
> Components: Other
> Versions: 2.0-M3
> Environment: Linux/JBoss
> Reporter: Michael Lipp
> Assignee: David Sean Taylor
> Attachments: better-patch.txt, patch.txt
>
> I'm trying to pack Jetspeed2 in an EAR. The basic setup is: all libraries that are "shared" in Tomcat become client modules in the EAR (so they are "common" components in the classpath of all WAR modules). Libraries in WEB-INF/lib take precedence (as specified for servlets). Xerces, Xalan and xml-apis have been removed from the WARs; latest versions are configured using the endorsed libraries mechanisms as recommended (besides not being compliant to the mechanism's specification, having individual XML libraries in every WAR's/PA's classloader consumes a lot of memory).
> In this environment I find that the Digester cannot load all classes. By default, the digester uses its own class loader to lookup class in the ObjectCreateRule. This should work if the digester can only be found in the WAR's WEB-INF/lib. This does not seem to be the case. I haven't tracked down why (propably it is due to the use of "common" XML libraries which causes the Digester class in the Tomcat container to be used). As class loaders are explicitly passed around in Jetspeed, they should be used anyway and used to configure the Digester. Where explicit classloaders are not available, the context class loader should be used. I have provided a patch against M3.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Updated: (JS2-274) Digester uses wrong class loader
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-274?page=all ]
Michael Lipp updated JS2-274:
-----------------------------
Attachment: patch.txt
> Digester uses wrong class loader
> --------------------------------
>
> Key: JS2-274
> URL: http://issues.apache.org/jira/browse/JS2-274
> Project: Jetspeed 2
> Type: Bug
> Components: Other
> Versions: 2.0-M3
> Environment: Linux/JBoss
> Reporter: Michael Lipp
> Attachments: patch.txt
>
> I'm trying to pack Jetspeed2 in an EAR. The basic setup is: all libraries that are "shared" in Tomcat become client modules in the EAR (so they are "common" components in the classpath of all WAR modules). Libraries in WEB-INF/lib take precedence (as specified for servlets). Xerces, Xalan and xml-apis have been removed from the WARs; latest versions are configured using the endorsed libraries mechanisms as recommended (besides not being compliant to the mechanism's specification, having individual XML libraries in every WAR's/PA's classloader consumes a lot of memory).
> In this environment I find that the Digester cannot load all classes. By default, the digester uses its own class loader to lookup class in the ObjectCreateRule. This should work if the digester can only be found in the WAR's WEB-INF/lib. This does not seem to be the case. I haven't tracked down why (propably it is due to the use of "common" XML libraries which causes the Digester class in the Tomcat container to be used). As class loaders are explicitly passed around in Jetspeed, they should be used anyway and used to configure the Digester. Where explicit classloaders are not available, the context class loader should be used. I have provided a patch against M3.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org