5 Replies Latest reply on Apr 16, 2010 11:46 AM by Andrew Rubinger

    Including other namespaces in jboss-beans.xml

    Andrew Rubinger Master

      I've got a simple Microcontainer deployment XML:

      <deployment xmlns="urn:jboss:bean-deployer:2.0">
      
        <!-- Deployment configuration for a VFS TempFileProvider -->
      
      
        <threads xmlns="urn:jboss:threads:2.0">
      
          <!--
            This will execute in the calling Thread. Probably better to use
            another, Single-threaded executor type, but this is fine for now
          -->
          <direct-executor name="org.jboss.reloaded.TempFileExecutorService" />
        </threads>
        
        <bean name="org.jboss.reloaded.TempFileProvider">
          <constructor factoryClass="org.jboss.vfs.TempFileProvider" factoryMethod="create">
          <parameter>shrinkwrap-</parameter>
          <parameter><inject bean="org.jboss.reloaded.TempFileExecutorService"/></parameter></constructor>
        </bean>
      
      </deployment>
      

       

      ...which yields error on deployment from XB.  I'm starting this outside of AS; is there anything I need to send along to configure JBossXB, or do we recognize this error?

      java.lang.Exception: Encountered exception in server startup
          at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:325)
          at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:257)
          at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:413)
          at java.lang.Thread.run(Thread.java:619)
      Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: {urn:jboss:threads:2.0}threads not found as a child of {urn:jboss:bean-deployer:2.0}deployment in unordered_sequence: {urn:jboss:bean-deployer:2.0}stop? {urn:jboss:bean-deployer:2.0}destroy? {urn:jboss:bean-deployer:2.0}annotation* {urn:jboss:bean-deployer:2.0}alias* {urn:jboss:bean-deployer:2.0}start? {urn:jboss:bean-deployer:2.0}classloader? {urn:jboss:bean-deployer:2.0}create? {choice}* {wildcard}*
          at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
          at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:183)
          at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:161)
          at org.jboss.bootstrap.impl.mc.deployer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:188)
          at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:310)
          ... 3 more
      Caused by: org.jboss.xb.binding.JBossXBRuntimeException: {urn:jboss:threads:2.0}threads not found as a child of {urn:jboss:bean-deployer:2.0}deployment in unordered_sequence: {urn:jboss:bean-deployer:2.0}stop? {urn:jboss:bean-deployer:2.0}destroy? {urn:jboss:bean-deployer:2.0}annotation* {urn:jboss:bean-deployer:2.0}alias* {urn:jboss:bean-deployer:2.0}start? {urn:jboss:bean-deployer:2.0}classloader? {urn:jboss:bean-deployer:2.0}create? {choice}* {wildcard}*
          at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:391)
          at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:401)
          at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
          at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
          at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
          at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
          at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
          at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
          at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
          at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
          at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
          at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
          at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:199)
          ... 7 more
      

       

      Thanks.

       

      S,

      ALR

        • 1. Re: Including other namespaces in jboss-beans.xml
          jaikiran pai Master

          Not completely sure, but I guess the classpath contains a (old version) of a jar (jboss-kernel.jar?) from where the bean-deployer_2_0.xsd is being picked up. TRACE level logging of jboss xb might show where it's coming from.

          • 2. Re: Including other namespaces in jboss-beans.xml
            Ales Justin Master

            The deployment element takes wildcards (see  {wildcard}*), hence threads should be easily picked up.

             

            How do you add threads namespace metadata to XB' SchemaResolver?

             

            In AS, I think this is done via deployer -- see threads-deployers-jboss-beans.xml or something similar.

            It's the SchemaResolverDeployer usage, which registers metadata's namespace against resolver singleton.

             

            Ideally I think for all JBoss namespaces we should pre-register them in the resolver singleton.

            Some of them already are, but looks like we're still missing some.

            • 3. Re: Including other namespaces in jboss-beans.xml
              Emanuel Muckenhuber Master

              Ales Justin wrote:

               

              In AS, I think this is done via deployer -- see threads-deployers-jboss-beans.xml or something similar.

              It's the SchemaResolverDeployer usage, which registers metadata's namespace against resolver singleton.

              Right, so either you deploy the threads.deployer first - or you have to register the ThreadsMetaData directly in XB using the correct namespace. This is basically what the deployer does.

               

              Ales Justin wrote:

               

              Ideally I think for all JBoss namespaces we should pre-register them in the resolver singleton.

              Some of them already are, but looks like we're still missing some.

               

              I don't really think that pre-registering should be done. This somehow contradicts modularity - since you need to register the class against the namespace. So it should be part of the deployer or module which handles threads or other BeanMetaDataFactories to take care of that.

              • 4. Re: Including other namespaces in jboss-beans.xml
                Ales Justin Master
                Ideally I think for all JBoss namespaces we should pre-register them in the resolver singleton.

                Some of them already are, but looks like we're still missing some.

                 

                I don't really think that pre-registering should be done. This somehow contradicts modularity - since you need to register the class against the namespace. So it should be part of the deployer or module which handles threads or other BeanMetaDataFactories to take care of that.

                True, although it simplifies things a lot if you do. :-)

                 

                Otoh, doing this outside deployers (*), would mean you would need to find a proper hook into XB.

                This introduces new potential issues:

                * you depend on XB api, instead of just XB annotations (which don't need to be there at runtime, if you don't need them ;-))

                * XB api must somehow be static -- which it is atm

                 

                (*) not all things need deployers; see this use case or <classloader> element

                • 5. Re: Including other namespaces in jboss-beans.xml
                  Andrew Rubinger Master

                  https://jira.jboss.org/jira/browse/RELOADED-15

                   

                  Thanks guys.

                   

                  I agree that each module (or an integration component for the module) should register itself w/ XB, so here I provide a bootstrap descriptor the user may add which accomplishes just that.

                   

                  Threads Deployer does the trick.

                   

                  S,

                  ALR