[starksm64]

I validated and resolved the JBXB-109 issue.

[starksm64]

Why does one need to specify the property order for these wildcard type bindings? Is it that the unknown elements need to come at the end of the type parsing?

Its going to make it tedious to have to specify all the elements in the larger metadata types like the ejb container.

[aloubyansky]

It's not because there wildcards but because the properties order doesn't match the elements order in the schema. If I don't specify the propOrder then the properties will be processed in the following sequence:
key; descriptions; proxyFactoryConfig; class; proxyFactory; name; wildcard; invokerProxyBindingName; id; invokerMBean;
And this will be the sequence of the elements in the schema.

Now elements are parsed in this sequence:
start: invoker-proxy-binding
start: description
end: description
start: description
end: description
start: description
end: description
start: invoker-proxy-binding-name
end: invoker-proxy-binding-name
start: invoker-mbean
end: invoker-mbean
start: proxy-factory
UNRESOLVED: proxy-factory
end: proxy-factory

Everything after invoker-mbean is going to be wildcard content because we reached the last element in the sequence.

[aloubyansky]

Is there anything else that should be done to resolve Update to JBossXB 2.0.0.CR5 http://jira.jboss.com/jira/browse/JBAS-4744

[starksm64]

See the current org.jboss.test.ejb.metadata.test.EjbJar3xUnitTestCase.testServiceRefs in the jbossxb project. A simple ejb-jar.xml with a session/service-ref is failing with:

Caused by: org.jboss.xb.binding.JBossXBRuntimeException: {http://java.sun.com/xml/ns/javaee}service-ref not found as a child of {http://java.sun.com/xml/ns/javaee}session
at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:370)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:402)
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:180)
... 23 more

[aloubyansky]

I fixed it. EnvironmentRefsGroupMetaData should have bound serviceReferences to service-ref element.
Now there is a different exception.

org.jboss.xb.binding.JBossXBRuntimeException: {http://java.sun.com/xml/ns/javaee}port-component-ref not found as a child of {http://java.sun.com/xml/ns/javaee}service-ref
 at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:370)

It seems like the implementation of the ServiceReferenceMetaData is incomplete.

[starksm64]

Ok, I added the org.jboss.javaee.metadata.spec.PortComponent and will continue with the testcase.

[starksm64]

Its parsing now. Now onto the real test to see if can treat the service-refs as a list of dom elements so I can create the org.jboss.wsf.spi.serviceref.ServiceRefMetaData from the ws spi.

[starksm64]

I'm having problems getting the service-ref as an Element. I can get all of the service-ref child elements as Elements, but not the service-ref element itself. Seems like the @JBossXmlModelGroup is not behaving the same as the @XmlType used with the InvokerProxyBindingMetaData that used wildcards.

I'll create an example test later. For now I'll take another approach to creating the org.jboss.wsf.spi.serviceref.ServiceRefMetaData.