On Tue, Feb 3, 2009 at 5:20 PM, Scott Kurz <[email protected]> wrote:
> This might seem nit-picky... but where do are the possible values for the
> @type attribute of BindingProperty defined?
>
> I see in the OASIS JMS Binding spec simply this schema def:
>
> 776 <complexType name="BindingProperty">
> 777 <simpleContent>
> 778 <extension base="string">
> 779 <attribute name="name" type="NMTOKEN"/>
> 780 <attribute name="type" type="string" use="optional"
> 781 default="xs:string"/>
> 782 </extension>
> 783 </simpleContent>
> 784 </complexType>
>
> and our JMSBindingProcessor recognizes the types via code:
>
> private void parseProperty(XMLStreamReader reader, JMSBinding
> jmsBinding) throws XMLStreamException {
> String name = reader.getAttributeValue(null, "name");
> String type = reader.getAttributeValue(null, "type");
> if (name != null && name.length() > 0) {
> Object value = reader.getElementText();
> if ("boolean".equalsIgnoreCase(type)) {
> value = Boolean.parseBoolean((String)value);
> } else if ("byte".equalsIgnoreCase(type)) {
> value = Byte.parseByte(((String)value));
> ...
>
> But where do these values come from?
>
> Thanks,
> Scott
>
Hi Scott
I'm not sure although section 7.4 of the OASIS version of the JMS spec does
given an example of Destination properties being used where the type is
String. A couple of points here.
1/ we only seem to parse properties when they appear within the Headers
element. In this case I would expect us to be able to set any type that is
valid for a JMS user property. I don't know why we don't parse them for
other types we should raise a JIRA and get that fixed to populate the model.
Some wireFormat processing, for example, may want to look at the specified
properties.
2/ It's interesting that the pseudo schema in the spec says the type is an
NMTOKEN but in the schema it defines it as a String.
Simon
