Including other namespaces in jboss-beans.xml

[alrubinger]

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

[jaikiran]

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.

[alesj]

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.

[emuckenhuber]

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.

[alesj]

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

[alrubinger]

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