Order in which deployment files are processed

[bosschaert]

The OSGiFrameworkFactory class contains the following list of config files that are processed in the the order specified:

{code}bootstraps.add("jboss-osgi-bootstrap.xml"); // needed by standalone runtime
bootstraps.add("META-INF/jboss-osgi-bootstrap.xml");
bootstraps.add("META-INF/jboss-osgi-bootstrap-container.xml");
bootstraps.add("META-INF/jboss-osgi-bootstrap-system.xml");{code}

This means that the 'user' config file "jboss-osgi-bootstrap.xml" is always processed first.

I currently have a practical problem with this. The jboss-osgi-bootstrap-system.xml file declares a custom schema that I want users to be able to user in jboss-osgi-bootstrap.xml, but because it is processed afterwards it is not available when the user config file is parsed.

So I would propose to change the order of files here to:

{code}bootstraps.add("META-INF/jboss-osgi-bootstrap.xml");
bootstraps.add("META-INF/jboss-osgi-bootstrap-container.xml");
bootstraps.add("META-INF/jboss-osgi-bootstrap-system.xml");
bootstraps.add("jboss-osgi-bootstrap.xml");{code}

Not sure about "META-INF/jboss-osgi-bootstrap.xml". I think that one's only used for testing. Should it be moved down too?

Thoughts anyone?

[thomas.diesler]

The dependency between beans is handled by their <depends> clause - the order of descriptors should not matter when dependecies are configured correctly. Having said that, it is resonable to change the order to: system, container, bootstrap. Then you should not need to define additional dependency clauses.

[bosschaert]

Thanks - I don't think it's possible to use the <depends> clause for the custom namespace handlers...

[alesj]

The dependency between beans is handled by their <depends> clause - the order of descriptors should not matter when dependecies are configured correctly.

Sometimes even this cannot help.

As with xml parsing it can be like chicken'n'egg problem -- cannot parse custom stuff before they are defined.

Hence the proper split between basic bootstrap and custom osgi pojos is what we need if osgi2pojo schema is to be used.

[alesj]

I don't think it's possible to use the <depends> clause for the custom namespace handlers...

It depends which custom namespace you're using.

If somewhere in the metadata hierarchy / structure there is "depends" collection defined, it should work.

It's then up to the top element's metadata on how it turns this into proper BeanMetaData.

[bosschaert]

Ales Justin wrote:

I don't think it's possible to use the <depends> clause for the custom namespace handlers...

It depends which custom namespace you're using.

If somewhere in the metadata hierarchy / structure there is "depends" collection defined, it should work.

It's then up to the top element's metadata on how it turns this into proper BeanMetaData.

Hi Ales,

I don't fully follow this. Could you give me an example please?

[alesj]

I don't fully follow this. Could you give me an example please?

I think the osgi2pojo could handle this, as its metadata class extends AbstractBeanMetaData, which knows how to handle <depends>.

[bosschaert]

Ales Justin wrote:

I don't fully follow this. Could you give me an example please?

I think the osgi2pojo could handle this, as its metadata class extends AbstractBeanMetaData, which knows how to handle <depends>.

My StartLevelBeanDefinition also extends AbstractBeanMetaData and it's declared as follows

{code:xml}<bean name="StartLevelSchema">
  <constructor factoryMethod="getSchemaBindingResolver"><factory bean="OSGiSingletonSchemaResolverFactory" /></constructor>
  <install method="mapURIToClass">
    <parameter>urn:jboss:startlevel:1.0</parameter>
    <parameter>org.jboss.osgi.framework.service.internal.StartLevelBeanDefinition</parameter>
  </install>
  <uninstall method="removeURIToClassMapping">
    <parameter>urn:jboss:startlevel:1.0</parameter>
  </uninstall>
</bean>{code}

However if I use it in as follows in a file that is deployed before the above piece is deployed, even with a depends clause;

{code:xml}<start-level xmlns="urn:jboss:startlevel:1.0">
  <depends>StartLevelSchema</depends>
</start-level>{code}

I get the exception below. he XML parser simply doesn't seem to know about the namespace yet...

org.jboss.xb.binding.JBossXBRuntimeException: {urn:jboss:startlevel:1.0}start-level cannot appear in this position. Expected content of {urn:jboss:bean-deployer:2.0}deployment is 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}*
    at org.jboss.xb.binding.sunday.unmarshalling.ElementPosition.nextPosition(ElementPosition.java:193) [jbossxb.jar:2.0.2.Beta7]
    at org.jboss.xb.binding.sunday.unmarshalling.ElementPosition.startParticle(ElementPosition.java:475) [jbossxb.jar:2.0.2.Beta7]
    at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:203) [jbossxb.jar:2.0.2.Beta7]
    at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.startElement(SaxJBossXBParser.java:370) [jbossxb.jar:2.0.2.Beta7]
    at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) [xercesImpl.jar:6.0.0.20100429-M3]
    at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) [xercesImpl.jar:6.0.0.20100429-M3]
    at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) [xercesImpl.jar:6.0.0.20100429-M3]
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) [xercesImpl.jar:6.0.0.20100429-M3]
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) [xercesImpl.jar:6.0.0.20100429-M3]
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [xercesImpl.jar:6.0.0.20100429-M3]
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [xercesImpl.jar:6.0.0.20100429-M3]
    at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) [xercesImpl.jar:6.0.0.20100429-M3]
    at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) [xercesImpl.jar:6.0.0.20100429-M3]
    at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) [xercesImpl.jar:6.0.0.20100429-M3]
    at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:191) [jbossxb.jar:2.0.2.Beta7]
    ... 44 more

[aloubyansky]

You have to tell XB which classes to use for the namespace. See the defaults in deployers/metadata-deployer-jboss-beans.xml.

[bosschaert]

Thanks Alex!

Since I'm already using the MC to declare my namespace, is this something that MC could do? Ales, do you have any thoughts about that or is the only option to hardcode the schema in the file that Alex refers to, which means that I'm really declaring the schema in two places.

[alesj]

You have to tell XB which classes to use for the namespace. See the defaults in deployers/metadata-deployer-jboss-beans.xml.

I don't think that's really the issue, as he's already registering his namespace against XB.

It's probably that <depends> is then not transitively added to that namespace as well?

[alesj]

as he's already registering his namespace against XB.

See  StartLevelSchema bean.

[alesj]

<bean name="StartLevelSchema">
  <constructor factoryMethod="getSchemaBindingResolver"><factory bean="OSGiSingletonSchemaResolverFactory" /></constructor>
  <install method="mapURIToClass">
    <parameter>urn:jboss:startlevel:1.0</parameter>
    <parameter>org.jboss.osgi.framework.service.internal.StartLevelBeanDefinition</parameter>
  </install>
  <uninstall method="removeURIToClassMapping">
    <parameter>urn:jboss:startlevel:1.0</parameter>
  </uninstall>
</bean>

However if I use it in as follows in a file that is deployed before the above piece is deployed, even with a depends clause;

<start-level xmlns="urn:jboss:startlevel:1.0">
  <depends>StartLevelSchema</depends>
</start-level>

Ah, this won't work, as you're actually depending on the bean that knows how to recognize your new schema.

Think of it as chicken'n'egg problem. ;-)