[
https://issues.jboss.org/browse/ISPN-891?page=com.atlassian.jira.plugin.s...
]
Vladimir Blagojevic commented on ISPN-891:
------------------------------------------
In order to accommodate this I have to move properties field from
PluggableConfigurationComponent to AbstractCacheStoreConfig and then have properties in
ClusterCacheLoaderConfig as well. I would then remove PluggableConfigurationComponent
class altogether.
The trick is that we can not have @XmlElement annotated fields in hierarchy of
configuration classes and then not impose some order between those @XmlElement annotated
fields.
Pick your poison :-)
Generated schema uses xs:sequence even if not semantically required
-------------------------------------------------------------------
Key: ISPN-891
URL:
https://issues.jboss.org/browse/ISPN-891
Project: Infinispan
Issue Type: Feature Request
Components: Configuration
Affects Versions: 4.2.0.Final
Reporter: Mircea Markus
Assignee: Vladimir Blagojevic
Fix For: 5.0.0.Final
E.g. looking at AbstractCacheStoreConfig it has the following schema-generating
annotation:
@XmlType(propOrder= {"singletonStoreConfig", "asyncStoreConfig"})
In resulting schema this translates to:
<xs:complexType name="abstractCacheStoreConfig">
<xs:complexContent>
<xs:extension base="tns:abstractCacheLoaderConfig">
<xs:sequence>
<xs:element name="singletonStore"
type="tns:singletonStoreConfig" minOccurs="0"/>
<xs:element name="async" type="tns:asyncStoreConfig"
minOccurs="0"/>
</xs:sequence>
...
</xs:extension>
</xs:complexContent>
</xs:complexType>
The xs:sequence element enclosing "singletonStore" and "async"
enforces the ISPN xml configuration to have these cache loader elements defined in this
particular order.
In other words this would be a valid configuration snippet:
<loaders shared="true" preload="false">
<loader class="org.infinispan.loaders.file.FileCacheStore">
<properties>
<property name="location"
value="${java.io.tmpdir}"/>
</properties>
<singletonStore enabled="true"
pushStateWhenCoordinator="true" pushStateTimeout="20000" />
<async enabled="true" flushLockTimeout="15000"
threadPoolSize="10"/>
</loader>
</loaders>
Whilst for this one the validation would fail:
<loaders shared="true" preload="false">
<loader class="org.infinispan.loaders.file.FileCacheStore">
<properties>
<property name="location"
value="${java.io.tmpdir}"/>
</properties>
<async enabled="true" flushLockTimeout="15000"
threadPoolSize="10"/>
<singletonStore enabled="true"
pushStateWhenCoordinator="true" pushStateTimeout="20000" />
</loader>
</loaders>
The two configurations are semantically equivalent and there's no point in enforcing
this ordering constraint on users.
This is just an example of sequence enforcing, but the same thing appears in many places
in the generated schema.
A solution might be using the xs:all (vs xs:sequence) xs collection type (where
possible):
http://www.w3.org/2005/07/xml-schema-patterns.html#Collection
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira