Thanks for replying Simon, So I see for 1), you opened: https://issues.apache.org/jira/browse/TUSCANY-2820
For 2), I see your point about the pseudo-schema being off.... As far as our code, I realize now we're just dealing with the (obvious) mapping between built-in XSD types and the standard JMS property types. The thing which threw me off was expecting to see some XML/XSD parsing here to account for the fact that the attr value could include a NS,e.g.: <property name="MyProp" type="xsd:string"..../> I thought maybe this was a side list of props somewhere and not the regular built-in XSD types. So is this just a bug then ? Or did I miss some ability of the XML APIs we're already using? Thanks, Scott On Wed, Feb 4, 2009 at 8:17 AM, Simon Laws <[email protected]>wrote: > > > 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 >
