"meta-inf" != "META-INF" --jason
Quoting "Frederick N. Brier" <[EMAIL PROTECTED]>: > Not a problem. Hopefully this email will contain the requested info. BTW, > > I'm not even sure I was asking for a new ClassLoader. I saw a significant > amount of code in MBeanServerImpl.invoke() and ServiceCreator.install() > that seemed to imply that the intention was to have a ClassLoader for each > deployed SAR. This made sense considering the issues I think I am running > into. Although the below SAR info is for the Castor MBean, I also have > several MBean(s) I have been writing to convert from my > DeploymentNotification approach under JBoss 2.4.x. The problem is being > able to read configuration files from the startService() method of an MBean > > such as CastorJDOImpl.java (in the varia module). My aiab-common.sar has > the following files in it: > > aiab-common.jar > castor-jdo-plugin.jar <---including this file or putting in in > jboss/lib makes no difference. > meta-inf/jboss-service.xml > meta-inf/Manifest.mf > meta-inf/database.xml > meta-inf/mapping.xml > > The jboss-service.xml file is: > > <?xml version="1.0" encoding="ISO-8859-1"?> > <!-- Author: Frederick N. Brier --> > <!DOCTYPE server> > <!-- $Id: jboss-service.xml,v 1.12 2002/04/27 Exp $ --> > <server> > <classpath codebase="lib" archives="castor.jar, jboss-system.jar, > jboss-jmx.jar, jndi.jar, xercesImpl.jar"/> > <mbean > code="org.jboss.jdo.castor.CastorJDOImpl" > name="DefaultDomain:service=CastorJDO,name=AIAB-Common"> > <attribute > name="Configuration">file:/META-INF/database.xml</attribute> > <attribute name="JndiName">jdo/aiabcommon</attribute> > <attribute name="LockTimeout">10000</attribute> > <attribute name="LoggingEnabled">true</attribute> > <attribute name="CommonClassPath">false</attribute> > <attribute name="AutoStore">false</attribute> > </mbean> > </server> > > The Configuration attribute becomes the CastorJDOImpl data member > _dbConf. Which is passed into the unmarshal() method. What I was hoping > was that a ClassLoader.getResource( "file:/META-INF/database.xml") call > would return a java.net.URL object that would have the proper njar: syntax > that could be passed to the unmarshal() method. Also note, I just did a > CVS update and built/deployed it so this is the latest code. The actual > exception dump from server.log is: > > java.io.FileNotFoundException: /META-INF/database.xml > at > org.jboss.net.protocol.file.FileURLConnection.connect(FileURLConnection.java:65 ) > at > org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection. java:72) > at java.net.URL.openStream(URL.java:798) > at > org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:740) > at > org.apache.xerces.impl.XMLEntityManager.startDocumentEntity(XMLEntityManager.ja va:685) > at > org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource(XMLDocumentScanner Impl.java:252) > at > org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfi guration.java:503) > at > org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfi guration.java:585) > at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147) > at > org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1148) > at > org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:338) > at > org.jboss.jdo.castor.CastorJDOImpl.startService(CastorJDOImpl.java:151) > at > org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:198) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatche r.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:8 67) > at $Proxy0.start(Unknown Source) > at > org.jboss.system.ServiceController.start(ServiceController.java:339) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatche r.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > at $Proxy3.start(Unknown Source) > at org.jboss.deployment.SARDeployer.start(SARDeployer.java:341) > at org.jboss.deployment.MainDeployer.start(MainDeployer.java:686) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatche r.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > at $Proxy4.deploy(Unknown Source) > at > org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.j ava:405) > at > org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymentSc anner.java:586) > at > org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.jav a:465) > at > org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDep loymentScanner.java:237) > at > org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:198) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatche r.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:8 67) > at $Proxy0.start(Unknown Source) > at > org.jboss.system.ServiceController.start(ServiceController.java:339) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatche r.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > at $Proxy3.start(Unknown Source) > at org.jboss.deployment.SARDeployer.start(SARDeployer.java:341) > at org.jboss.deployment.MainDeployer.start(MainDeployer.java:686) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatche r.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318) > at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216) > at org.jboss.Main.boot(Main.java:148) > at org.jboss.Main$1.run(Main.java:381) > at java.lang.Thread.run(Thread.java:484) > 2002-05-20 20:38:05,347 DEBUG [org.jboss.deployment.SARDeployer] > undeploying document > file:/usr/local/jboss/server/default/deploy/aiab-common.sar > > > At 12:18 PM 5/20/2002, you wrote: > >It is still not clear what the structure of the sar that is failing is. > >Answer that question before we start talking about introducing > >new class loaders. > > > >xxxxxxxxxxxxxxxxxxxxxxxx > >Scott Stark > >Chief Technology Officer > >JBoss Group, LLC > >xxxxxxxxxxxxxxxxxxxxxxxx > >----- Original Message ----- > >From: "Frederick N. Brier" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Sent: Monday, May 20, 2002 6:57 AM > >Subject: Re: [JBoss-dev] MBean ClassLoader ?revisited? > > > > > > > I'd be glad to use the DeploymentInfo if an MBean had access to it. > The > > > startService() method has no parameters. The MBean only has access to > the > > > primitive values initialized from its XML attributes. So how would the > > > MBean get a hold of it? > > > > > > I do not understand why you feel that having a ClassLoader for the > MBean > > > would fail to solve my problem. Shouldn't the ClassLoader, in > conjunction > > > with the njar protocol, be able to resolve a relative "file:" protocol > > > address within an archive to a fully explicit "njar:" URL that could be > > > used to create an InputStream [ClassLoader.get*Resource*() > > > methods]. Please explain. And don't worry, I won't be making changes > > > unless a senior developer says go. I am definitely the new kid on the > > > block and nervous about modifying anything. My contribution was going > to > > > be to JBoss.net. On the other hand, we have to deliver an application > and > > > I'm trying to figure out how to make it work. > > > > > > Fred. > > > > > > At 07:46 AM 5/20/2002, you wrote: > > > >Please do not bring back a classloader/mbean. I don't think it will > do > > > >what you want anyway. > > > > > > > >What is wrong with using the DeploymentInfo for the package that has > the > > > >info you want in it? DeploymentInfo already has a reference to the > > > >classloader that loads everything in that package. > > > > > > > >david jencks > > > > > > > >_______________________________________________________________ > >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 > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
