-
1. Re: Order in which deployment files are processed
thomas.diesler Jun 23, 2010 8:28 AM (in response to bosschaert)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.
-
2. Re: Order in which deployment files are processed
bosschaert Jun 23, 2010 8:31 AM (in response to thomas.diesler)Thanks - I don't think it's possible to use the <depends> clause for the custom namespace handlers...
-
3. Re: Order in which deployment files are processed
alesj Jun 24, 2010 2:05 AM (in response to thomas.diesler)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.
-
4. Re: Order in which deployment files are processed
alesj Jun 24, 2010 2:08 AM (in response to bosschaert)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.
-
5. Re: Order in which deployment files are processed
bosschaert Jun 24, 2010 4:41 AM (in response to alesj)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?
-
6. Re: Order in which deployment files are processed
alesj Jun 24, 2010 4:45 AM (in response to bosschaert)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>.
-
7. Re: Order in which deployment files are processed
bosschaert Jun 24, 2010 6:12 AM (in response to alesj)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 -
8. Re: Order in which deployment files are processed
aloubyansky Jun 24, 2010 9:01 AM (in response to bosschaert)You have to tell XB which classes to use for the namespace. See the defaults in deployers/metadata-deployer-jboss-beans.xml.
-
9. Re: Order in which deployment files are processed
bosschaert Jun 25, 2010 3:06 AM (in response to aloubyansky)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.
-
10. Re: Order in which deployment files are processed
alesj Jun 25, 2010 10:18 AM (in response to aloubyansky)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?
-
11. Re: Order in which deployment files are processed
alesj Jun 25, 2010 10:19 AM (in response to alesj)as he's already registering his namespace against XB.
See
StartLevelSchema bean.
-
12. Re: Order in which deployment files are processed
alesj Jun 25, 2010 10:22 AM (in response to bosschaert)<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. ;-)