[JBoss JIRA] Created: (ISPN-891) Generated schema uses xs:sequence even if not semantically required
4:35 a.m.
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: Manik Surtani
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
9:17 a.m.
New subject: [JBoss JIRA] Assigned: (ISPN-891) Generated schema uses xs:sequence even if not semantically required
[
https://issues.jboss.org/browse/ISPN-891?page=com.atlassian.jira.plugin.s...
]
Manik Surtani reassigned ISPN-891:
----------------------------------
Assignee: Vladimir Blagojevic (was: Manik Surtani)
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
10:01 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-891) Generated schema uses xs:sequence even if not semantically required
[
https://issues.jboss.org/browse/ISPN-891?page=com.atlassian.jira.plugin.s...
]
Vladimir Blagojevic commented on ISPN-891:
------------------------------------------
The reason I did this was that I could not mix xs:all with xs:sequence from
PluggableConfigurationComponent which is a superclass of AbstractCacheStoreConfig. The
only way I see to remove this constraint is to move properties from
PluggableConfigurationComponent to AbstractCacheStoreConfig. Investigating....
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
10:25 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-891) Generated schema uses xs:sequence even if not semantically required
[
https://issues.jboss.org/browse/ISPN-891?page=com.atlassian.jira.plugin.s...
]
Vladimir Blagojevic commented on ISPN-891:
------------------------------------------
Mircea, is ClusterCacheLoaderConfig bean only used programmatically? Does it need
properties?
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
3:27 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-891) Generated schema uses xs:sequence even if not semantically required
[
https://issues.jboss.org/browse/ISPN-891?page=com.atlassian.jira.plugin.s...
]
Mircea Markus commented on ISPN-891:
------------------------------------
@Vladimir yes. ClusterCacheLoaderConfig has a property named remoteCallTimeout.
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
8:56 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-891) Generated schema uses xs:sequence even if not semantically required
[
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
6:11 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-891) Generated schema uses xs:sequence even if not semantically required
[
https://issues.jboss.org/browse/ISPN-891?page=com.atlassian.jira.plugin.s...
]
Mircea Markus commented on ISPN-891:
------------------------------------
@Valdimir
Not sure I understand. The config is as follows:
<loaders preload="false">
<loader
class="org.infinispan.loaders.cluster.ClusterCacheLoader">
<properties>
<property name="remoteCallTimeout"
value="20000"/>
</properties>
</loader>
</loaders>
How does this impact the ordering between singletonStoreConfig and asyncStoreConfig
elements?
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
7:58 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-891) Generated schema uses xs:sequence even if not semantically required
[
https://issues.jboss.org/browse/ISPN-891?page=com.atlassian.jira.plugin.s...
]
Vladimir Blagojevic commented on ISPN-891:
------------------------------------------
It does not. It is just how we are going to implement properties. I'll need to have
properties field in AbstractCacheStoreConfig and ClusterCacheLoaderConfig as well. But
that is not the end of the world I guess.
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
9:16 a.m.
New subject: [JBoss JIRA] Resolved: (ISPN-891) Generated schema uses xs:sequence even if not semantically required
[
https://issues.jboss.org/browse/ISPN-891?page=com.atlassian.jira.plugin.s...
]
Vladimir Blagojevic resolved ISPN-891.
--------------------------------------
Fix Version/s: 4.2.1.Final
Resolution: Done
Fixed on both master and 4.2.x
https://github.com/infinispan/infinispan/pull/150
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: 4.2.1.Final, 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
11:57 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-891) Generated schema uses xs:sequence even if not semantically required
[
https://issues.jboss.org/browse/ISPN-891?page=com.atlassian.jira.plugin.s...
]
Galder Zamarreño updated ISPN-891:
----------------------------------
Fix Version/s: 4.2.1.CR2
5.0.0.ALPHA3
(was: 5.0.0.Final)
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: 4.2.1.CR2, 4.2.1.Final, 5.0.0.ALPHA3
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
5060
days inactive
5080
days old
infinispan-issues@lists.jboss.org
9 comments
4 participants
participants (4)
-
Galder Zamarreño (JIRA) -
Manik Surtani (JIRA)
-
Mircea Markus (JIRA)
-
Vladimir Blagojevic (JIRA)