On 2002.05.19 22:06:24 -0400 Frederick N. Brier wrote: > Wow. This could be a major bummer. Castor was only one of several > MBean(s) where I was going to use this technique. I have other MBeans > that > also needed to read their own XML files out of the .sar. I was > accomplishing this before (JBoss 2.4.x) with my DeploymentNotification > extension. I am aware of the idea that a .sar might not have any code in > > it. But isn't the purpose of the: > > <classpath codebase="lib" archives="castor.jar, castor-jdo-plugin.jar, > > jboss-system.jar, jboss-jmx.jar, jndi.jar, xercesImpl.jar"/> > > XML element to define a ClassLoader for the archive? No, it's to make sure all these things are loaded before the xml mbean config is processed. One UnifiedClassloader per entry is created, also I believe one DeploymentInfo/entry.
The MBean was not > loading due to missing classes until all the appropriate .jar(s) were > listed in the above statement. I thought it would be creating a > ClassLoader for the MBean(s) and contained .jar(s). MBeans don't get individual classloaders any more. The MBeanClassLoader was an idea to track the dependency between an mbean and its class, and it turned out to be easier to do without the extra classloader. Why would it not add > a > classpath to the root directory of where the .sar was expanded? Then any > > resources could be loaded out of the archive. There's still a [Unified] classloader for each DeploymentInfo. I think what you want to do is figure out which deployment info relates to where the database.xml is (such as by the convention that it is in the same sar, and including the name somewhere) and use its classloader directly. > > Also, it appears I seemed to have missed a big architectural change. > Where > is the directory where the .war(s), .ear(s), etc, are unpacked? Do they > no > longer need to be expanded? wars are sometimes unpacked by the web container. Everything else has its unpacking hidden by the njar url protocol handler. You may end up with a url something like njar:njar:jar:file://usr/java/mysar.sar^here/myrar.rar^lib/mylib.jar!org.me.myproject.myclass.class (I probably got some details wrong) I thought I saw code in the deployer where > they were still be unzipped? Help!! <panic setting in> Because I was > using the Deployment Info to determine the actual temporary directory the > > archive was being unpacked in. From that, I was able to find the > required > XML resource files for my dynamic MBeans. If you can find the appropriate DeploymentInfo, you should be able to load resources from its classloader without needing to know where its package might or might not be. Does this make sense? david jencks > > Fred. > > At 08:44 PM 5/19/2002, you wrote: > >I don't think you are going to be able to use a classloader to try to > find > >something in the "same" deployment unit as a mbean config snippet. For > >instance, the mbean could be created in code rather than from a .sar, or > >created in a standalone xml file. > > > >I think you will either have to provide another means of locating the > >database.xml etc such as naming the deployment unit it is in or > incorporate > >the contents into your mbean configuration directly as xml element > valued > >attributes. > > > >Another possibility might be to make a CastorDeployer that could deploy > >.jar files containing META-INF/database.xml and mapping.xml files. > > > >In a somewhat different direction, Matthew Baird was working on > jca-ifying > >the OJB project, and seemed to have gotten pretty far. This might > provide > >an alternate deployment mechanism. He had several posts on the jca > forum. > > > >david jencks > > <snip> _______________________________________________________________ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
