Bug 1039069

Summary: NMTOKEN type in XSD prevents using of properties in switchyard.xml
Product: [JBoss] JBoss Fuse Service Works 6 Reporter: Tomas Rohovsky <trohovsk>
Component: SwitchYardAssignee: Tomohisa Igarashi <toigaras>
Status: MODIFIED --- QA Contact: Matej Melko <mmelko>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.0.0CC: atangrin, ldimaggi, oskutka, rcernich, soa-p-jira
Target Milestone: DR4   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
The NMTOKEN type in XSD prevents the use of properties in the switchyard.xml file, because NMTOKEN does not allow you to use certain character symbols that are needed for properties. If you do try to use them, you will encounter an error during compilation.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Tomas Rohovsky 2013-12-06 14:21:48 UTC
NMTOKEN type in XSD prevents using of properties in switchyard.xml, because NMTOKEN does not allow using of $, {, } that are needed for properties, see http://www.schemacentral.com/sc/xsd/t-xsd_NMTOKEN.html. 

I have found this in JCA binding, but core module also contains some XSDs, DTDs containing NMTOKEN. See ResourceAdapter and Endpoint in http://goo.gl/EmTdKn. NMTOKEN should be replaced with something else or properties should be evaluated before XSD validation.

Comment 2 Keith Babo 2013-12-06 14:35:47 UTC
To clarify here, you are saying that property substitution does not work for attributes with a type of NMTOKEN, correct?  NMTOKEN in the schema doesn't prevent a user from using a property in other attributes or elements.  The exposure here is very small, so giving dev nack for FSW 6.  We should evaluate the use of NMTOKEN in the future though to determine if fields which use it should support property substitution.

Comment 3 Tomas Rohovsky 2013-12-06 14:54:35 UTC
If I define the property in resourceAdapter element:

<jca:resourceAdapter name="${resourceAdapter:hornetq-ra.rar}"/>

then during compilation this error occurs:

[ERROR] Failed to execute goal org.switchyard:switchyard-plugin:1.1.0.M3-redhat-2:configure (default) on project jca-bean-service-test: SWITCHYARD011602: Model [org.switchyard.config.model.switchyard.v1.V1SwitchYardModel] is invalid: cvc-datatype-valid.1.2.1: '${resourceAdapter:hornetq-ra.rar}' is not a valid value for 'NMTOKEN'. -> [Help 1]

I think that the exposure is not very small since changing of JCA resource adapter (hornetq, activemq, etc.) is quite real use case.

Comment 5 Tomohisa Igarashi 2014-10-22 00:26:57 UTC
grep shows following schemas are using NMTOKEN in SY core/components:
core/sca-binding-jms-1.1-csd05.xsd
core/sca-binding-jca-1.1-cd04-rev2.xsd
components/jca/jca_1_0.xsd, jca_1_1.xsd, jca_2_0.xsd

I believe sca-binding-{jms,jca} is not used for actual SwitchYard configuration, and JCA is using NMTOKEN without strong reason (just because it is copied from sca-binding-jca). Following 3 attributes are NMTOKEN in JCA schema:
binding.jca/inboundConnection/resourceAdapter/@name - RAR archive name
binding.jca/inboundInteraction/endpoint/@type - endpoint class name
binding.jca/outboundInteraction/processor/@type - processor class name

I don't think there's any problem to relax those 3 from NMTOKEN to String.