using digester and struts in an EAR file
I have a web app and ejb jar files combined in an ear file. If I want to use struts in the war file and the digester in some of the ejbs, I have a problem because the war classloader is a child of the ejb classloader (at least in Weblogic 6.1) which means classes loaded by the ejb class loader can't see the webapp's classes including the classes in struts.jar. If I put the commons-digester.jar in the ejb classpath (via the Manifest.mf Classpath:) then when the struts-config.xml is parsed the digester won't be able to find struts classes. If I leave commons-digester.jar in the webapp lib directory then the ejbs that want to use it can't see the digester classes. Am I missing something? Is there any way that the Digester could be told which class loader to use when it instantiates objects that it's looking for? Maybe then the ActionServlet could tell the Digester to use the ActionServlet classloader which should allow the Digester to find all the classes in the webapp? Then I could include common-digester.jar in both the ejb classpath and the webapp classpath. Has anyone else run into this problem? Thanks, Hal -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: using digester and struts in an EAR file
On Tue, 11 Dec 2001, Deadman, Hal wrote: Date: Tue, 11 Dec 2001 14:43:21 -0500 From: Deadman, Hal [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], Deadman, Hal [EMAIL PROTECTED] To: 'Struts Dev List' [EMAIL PROTECTED] Subject: using digester and struts in an EAR file I have a web app and ejb jar files combined in an ear file. If I want to use struts in the war file and the digester in some of the ejbs, I have a problem because the war classloader is a child of the ejb classloader (at least in Weblogic 6.1) which means classes loaded by the ejb class loader can't see the webapp's classes including the classes in struts.jar. If I put the commons-digester.jar in the ejb classpath (via the Manifest.mf Classpath:) then when the struts-config.xml is parsed the digester won't be able to find struts classes. If I leave commons-digester.jar in the webapp lib directory then the ejbs that want to use it can't see the digester classes. Am I missing something? Is there any way that the Digester could be told which class loader to use when it instantiates objects that it's looking for? Maybe then the ActionServlet could tell the Digester to use the ActionServlet classloader which should allow the Digester to find all the classes in the webapp? Then I could include common-digester.jar in both the ejb classpath and the webapp classpath. Has anyone else run into this problem? I take it you are using nightly builds of Struts for this (and therefore a current build of Digester from commons)? If so, you have two options (assuming that commons-digester.jar is in a shared repository in your server): * Call digester.setClassLoader() to set the class loader you want Digester to use for loading application classes. Normally, this would be the class loader for your web application, which can be more easily accessed by the second option -- but you can set any class loader you need. * Call digester.setUseContextClassLoader(true) before calling parse(). This tells Digester to use the thread context class loader (which will be the class loader for your web app) to load classes from, even if Digester itself is loaded from a shared class loader. Thanks, Hal Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: using digester and struts in an EAR file
Shouldn't the struts ActionServlet be calling setClassLoader() or setUseContextClassLoader()? When I move commons-digester.jar and commons-collections.jar to the ejb classpath where they are available to both EJBs and struts, the the digester can't find ActionFormBean and all of the other struts classes that it looks for (because they are in the child classloader of the ejb classloader). Moving struts.jar to the ejb classpath would not help because the classes that extend the struts classes would not be visable to the ActionServlet. Maybe there should be an initparam option that tells the ActionServlet to call setUseContextClassLoader? Hal -Original Message- From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig R. McClanahan Sent: Tuesday, December 11, 2001 3:05 PM To: Struts Developers List; Deadman, Hal Subject: Re: using digester and struts in an EAR file On Tue, 11 Dec 2001, Deadman, Hal wrote: Date: Tue, 11 Dec 2001 14:43:21 -0500 From: Deadman, Hal [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], Deadman, Hal [EMAIL PROTECTED] To: 'Struts Dev List' [EMAIL PROTECTED] Subject: using digester and struts in an EAR file I have a web app and ejb jar files combined in an ear file. If I want to use struts in the war file and the digester in some of the ejbs, I have a problem because the war classloader is a child of the ejb classloader (at least in Weblogic 6.1) which means classes loaded by the ejb class loader can't see the webapp's classes including the classes in struts.jar. If I put the commons-digester.jar in the ejb classpath (via the Manifest.mf Classpath:) then when the struts-config.xml is parsed the digester won't be able to find struts classes. If I leave commons-digester.jar in the webapp lib directory then the ejbs that want to use it can't see the digester classes. Am I missing something? Is there any way that the Digester could be told which class loader to use when it instantiates objects that it's looking for? Maybe then the ActionServlet could tell the Digester to use the ActionServlet classloader which should allow the Digester to find all the classes in the webapp? Then I could include common-digester.jar in both the ejb classpath and the webapp classpath. Has anyone else run into this problem? I take it you are using nightly builds of Struts for this (and therefore a current build of Digester from commons)? If so, you have two options (assuming that commons-digester.jar is in a shared repository in your server): * Call digester.setClassLoader() to set the class loader you want Digester to use for loading application classes. Normally, this would be the class loader for your web application, which can be more easily accessed by the second option -- but you can set any class loader you need. * Call digester.setUseContextClassLoader(true) before calling parse(). This tells Digester to use the thread context class loader (which will be the class loader for your web app) to load classes from, even if Digester itself is loaded from a shared class loader. Thanks, Hal Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
