I am working on http://issues.apache.org/jira/browse/TUSCANY-2856, and I
notice a discrepancy in the way XML contributions are validated. This
particular problem shows up validating JMS binding XML elements, but I
imagine it might show up elsewhere as well.
In binding-jms JMSBindingProcessorTestCase we read JMS binding header
elements with properties with no validation issues. For example, this
type of input is accepted by JMSBindingProcessorTest:
<binding.jms uri=\"jms:testQueue\" >
<headers>
<property name="p1">bla</property>
</headers>
</binding.jms>
On the other hand, itest-jms PolicyHeadersTestCase attempts to read this
input, and runs into validation errors:
<binding.jms uri="jms:ServiceQueue">
<headers JMSType="myType" JMSCorrelationID="xyz"
JMSDeliveryMode="PERSISTENT" JMSTimeToLive="4321"
JMSPriority="7">
<property name="headP1">myHeadP1</property>
</headers>
</binding.jms>
The error comes from the ValidatingXMLStreamReader complaining about the
name attribute on the property element, which technically is not legal
according to the sca-binding-jms.xsd:
Feb 25, 2009 8:26:37 AM
org.apache.tuscany.sca.contribution.processor.ValidatingXMLStreamReader
SEVERE: XMLSchema validation error occured in: null ,line = 25, column =
19, Message = cvc-type.3.1.1: Element 'property' is a simple type, so it
cannot have attributes, excepting those whose namespace name is
identical to 'http://www.w3.org/2001/XMLSchema-instance' and whose
[local name] is one of 'type', 'nil', 'schemaLocation' or
'noNamespaceSchemaLocation'. However, the attribute, 'name' was found.
I notice that JMSBindingProcessorTestCase sets up its own
ExtensibleStAXArtifactProcessor. PolicyHeadersTestCase uses
SCADomain.newInstance to create a NodeImpl which sets up a
StAXArtifactProcessor.
Can anyone point me in a direction as to which StAX processor set up
method is correct or other insight as to how to validate these
composites properly?
--
Thanks, Dan Becker
