[infinispan-dev] Schema algorithm

Vladimir Blagojevic vblagoje at redhat.com
Fri Aug 14 04:42:30 EDT 2009


On 13/08/09 5:27 PM, Manik Surtani wrote:
>
> I've mentioned these in a previous email, reiterating here for the record:
>
> 1.  XSD should be generated before the test suite is run. Perhaps in 
> the pre-test or post-compile phase.
> 2.  The code should skip loading the schema if schema validation is 
> disabled, following this algorithm:
>
>> validating = system property "infinispan.config.validate", defaults 
>> to true.
>> schema file = system property "infinispan.config.schema", defaults to 
>> schemas/infinispan-config-4.0.xsd
>> schema URL = system property "infinispan.config.schema.url" defaults 
>> to http://www.jboss.org/infinispan/infinispan-config-4.0.xsd
>>
>> if (validating) {
>> 1.  try and load schema file from classpath
>> 2.  else, try and load schema file on file system
>> 3.  else, try and load from schema URL
>> 4.  else, throw an exception!
>> }
>
> 3.  The unit test suite should *not* attempt to skip schema 
> validation.  This will, on one level, test schema validation code, and 
> on another, ensure all sample cfg files we ship with are valid.
> 4.  We should document the above system properties.  Javadoc for 
> Configuration could be one place, but also on the wiki.
>
Ok let me get this right this time. We should keep both static factories 
in Infinispan configuration, right? The first one where only 
configuration file reference is provided and the other where both 
configuration and schema file reference are provided. Call them factory 
1 and factory 2 respectively.

Now, for factory 1, you are saying that even though schema reference is 
not provided the above mentioned schema lookup algorithm would be run? 
What about factory 2? Should only provided reference be looked up and/or 
if it fails should the default be looked up? Or should we just have a 
factory without possibility to provided reference for schema file?

Is there some JBoss standard to follow?

Let me know






More information about the infinispan-dev mailing list