Hmm, surely there is always a version in the namespace?  Otherwise you have an issue where someone using Infinispan 4.0 attempts to configure an Infinispan 4.1 feature and the configuration parser considers this OK? I agree that as long as features are added and not removed, we could do something like: Configuration <-- base bean which holds all config elements.  This is what people use programmatically too. Config40 extends Configuration <-- annotated with urn:infinispan:config:4.0 and used to generate the 4.0 schema, parser, etc. Config41 extends Configuration <-- annotated with urn:infinispan:config:4.1 and used to generate the 4.1 schema, parser, etc. this would apply to other config beans too.  Would this work?  Or would this result in an unmanageable explosion of Xyz40, Xyz41, Xyz50, etc beans?  :)

Cheers Manik On 12 May 2010, at 18:33, Vladimir Blagojevic wrote: > More comments from Alexey. Should have kept him on the cc from the beginning. > On 2010-05-12, at 1:09 PM, Alexey Loubyansky wrote: > >> On 5/12/2010 5:18 PM, Vladimir Blagojevic wrote: >>> Thanks a lot Alexey. I think that we are going to follow the approach outlined below. Please have a quick look for my reasoning and see if it is flawed. >> >> It's alright. About the namespace, actually it's a matter of personal taste and reasoning. E.g. have a look at the following namespaces from other JBoss projects. They are not URL-based and some do include the version in the namespace. Users switching from one version to another will still have to just adjust the namespace. Or maybe even not doing that if your unmarshalling layer could recognize the previous configuration version by itself. >> >>     registerEntity("urn:jboss:aop-deployer", "aop-deployer_1_1.xsd"); >>     registerEntity("urn:jboss:aop-beans:1.0", "aop-beans_1_0.xsd"); >>     registerEntity("urn:jboss:bean-deployer", "bean-deployer_1_0.xsd"); >>     registerEntity("urn:jboss:bean-deployer:2.0", "bean-deployer_2_0.xsd"); >>     registerEntity("urn:jboss:javabean:1.0", "javabean_1_0.xsd"); >>     registerEntity("urn:jboss:javabean:2.0", "javabean_2_0.xsd"); >>     registerEntity("urn:jboss:spring-beans:2.0", "mc-spring-beans_2_0.xsd"); >>     registerEntity("urn:jboss:policy:1.0", "policy_1_0.xsd"); >>     registerEntity("urn:jboss:osgi-beans:1.0", "osgi-beans_1_0.xsd"); >>     registerEntity("urn:jboss:seam-components:1.0", "seam-components_1_0.xsd"); >>     registerEntity("urn:jboss:security-config:4.1", "security-config_4_1.xsd"); >>     registerEntity("urn:jboss:security-config:5.0", "security-config_5_0.xsd"); >>     registerEntity("urn:jboss:jndi-binding-service:1.0", "jndi-binding-service_1_0.xsd"); >>     registerEntity("urn:jboss:user-roles:1.0", "user-roles_1_0.xsd"); >> >> >>> If you are interested maybe we can collaborate on a project that we made for automatic configuration HTML reference file generation. We used annotated XML configuration pojos, along with a bit more additional metadata attached to each field to automatically generate configuration HTML references. Have a look at: >>> http://docs.jboss.org/infinispan/4.1/apidocs/config.html >> >> Not sure whether I'll get involved but I think it could be useful for other projects as well. Is it a separate standalone project? >> >> Thanks, >> Alexey >> >>> Best regards, >>> Vladimir >>> >>> >>> On 2010-05-12, at 11:11 AM, Vladimir Blagojevic wrote: >>> >>>> Hey all, >>>> >>>> After consultation with Alexey I think the following emerges as the best approach for management of xml schemas, configuration pojos and configuration file backward compatibility. >>>> >>>> We should remove references to schema version in namespace and we might even rename namespace to something like "http://infinispan.org/xml/ns/ispn" and use a prefix "ispn" rather than tns. We could roll this in 4.1 final release. We leave 4.0 schemas as is, but 4.1 signifies a break and a new schema name-spacing that we intend to keep. How do we treat customer who want to use their 4.0 configuration files in 4.1? We tell them to remove references to old namespace from their configuration files. Thanks to ISPN-431 they are not affected. >>>> >>>> Since we removed references to configuration version in schema, as far as our configuration beans go, we are fine as long as we add properties to elements and even adding new configuration elements in ok.  In essence, we are fine as long as we do not remove/rename existing attributes and elements from our configuration pojos. Adding new elements to configuration will still work. For example, lets say that 5.0 adds some configuration elements regarding JPA. Reading 4.1 configuration file in 5.0 is ok since we kept all those elements from 4.1 in 5.0, and for JPA element default configuration settings are initialized anyway. >>>> >>>> Let me know what you guys think. >>>> >>>> Vladimir >>>> >>>> >>>> >>>> On 2010-05-11, at 5:43 PM, Alexey Loubyansky wrote: >>>> >>>>> Hi Vladimir, >>>>> >>>>> yes, that's tricky. I can't say we have an elegant solution for that. >>>>> >>>>> I can't tell you what we do wrt EJB metadata (ejb-jar.xml/jboss.xml) as an example. >>>>> For jboss.xml we have common JBossMetaData. >>>>> http://anonsvn.jboss.org/repos/jbossas/projects/metadata/ejb/trunk/src/ma... >>>>> >>>>> It contains binding annotations but w/o the schema-level ones such namespace, etc. Then per schema version we create a top level class, e.g. >>>>> http://anonsvn.jboss.org/repos/jbossas/projects/metadata/ejb/trunk/src/ma... >>>>> http://anonsvn.jboss.org/repos/jbossas/projects/metadata/ejb/trunk/src/ma... >>>>> >>>>> There we specify the namespace and which properties we want to bind. So, actually, for some schemas common JBossMetaData contains more metadata than it is available in those schemas but those properties are just not bound for those schema versions. But the deployers regardless of the deployment descriptor version deployed use the same JBossMetaData API. >>>>> In this case, though, it's only for the top-level class (root element). Although, we could have some tricks for other classes/elements as well. >>>>> >>>>> Other metadata (sub)projects (web, ear, rar, etc) use the same approach. (There are also tests for consistency between XSD/DTD and Java bindings, i.e. structural equivalence) >>>>> >>>>> What is a bit different, we don't include schema version in the namespace. Schema versions are different but the namespace stays the same. The same is true for JEE spec schemas. >>>>> But even if we did, the current approach would still work. >>>>> >>>>> If you have some tricky cases/requirements then let's discuss them on the forums. It might be relevant to other projects as well. >>>>> >>>>> Best regards, >>>>> Alexey >>>>> >>>>> On 5/11/2010 9:46 PM, Vladimir Blagojevic wrote: >>>>>> Hi Alexey, >>>>>> >>>>>> Need an advice regarding best practices when it comes to XML schema management and references in configuration files. In infinispan project we have used JAXB annotated classes to annotate configuration pojos, automate manage configuration loading, and do schema creation. We have used the package-info.java files annotated with JAXB annotations to declare schema namespaces[1]. Then in turn we have generated XML schema file using JAXBContext#generateSchema. >>>>>> >>>>>> The current namespace is urn:infinispan:config:4.0, but this will change to urn:infinispan:config:4.1, urn:infinispan:config:5.0, etc in the future. What are our options for configuration file backward-compatibility? >>>>>> >>>>>> Best regards, >>>>>> Vladimir >>>>>> >>>>>> >>>>>> >>>>>> [1] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i... >>>> >>>> >>>> >>>> >>>> >>> > > Vladimir Blagojevic > JBoss Clustering Team > JBoss by Red Hat > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Hey, I don't think we need these xyz40, xyz41 version of beans. Well, it ultimately depends on requirements; what we want to do. If you take a look at related JIRA[1] I defined the following requirements: Backward compatibility Maintain minor version configuration file backward compatibility. We have to process any previous version configuration file from the same minor version. For example, Infinispan release 4.2 should process configuration file produced for version 4.1 without any configuration file changes or any other adjustments. For configuration options present in 4.2, but not in 4.1 assume default values. However, Infinispan version 5.0 is not required to process configuration files from previous major versions, i.e 4.0...4.x.

Forward compatibility Not supported. We do not process any forward version configuration file. For example, Infinispan release 4.1, given configuration file input from any succeeding versions (i.e 4.2...4.x, 5.x) would simply fail outright with proper error message.

However, that said, even forward compatibility could be supported to an extent - as long as properties and elements from forward versions are not used in configuration file. As soon as at least one element or a property from a forward version file is used - xml schema validation will fail. If schema validation is turned off configuration file can be processed.

Now, if you agree with these requirements we are already good to go! We are allowed to introduce additional elements and attributes between minor version. We cannot remove existing elements and attributes. Finally, there can not be any structural changes in terms of already existing elements. For example, we can not reparent existing element to another node, i.e say locking element instead of being a child of <default> or <namedCache> suddenly becomes a child of transaction element.

What do you guys think? Vladimir [1] https://jira.jboss.org/jira/browse/ISPN-439 On 2010-05-13, at 6:06 PM, Sanne Grinovero wrote: > 2010/5/13 Manik Surtani <manik(a)jboss.org&gt;: >> Hmm, surely there is always a version in the namespace? Otherwise you have an issue where someone using Infinispan 4.0 attempts to configure an Infinispan 4.1 feature and the configuration parser considers this OK? >> >> I agree that as long as features are added and not removed, we could do something like: >> >> Configuration <-- base bean which holds all config elements. This is what people use programmatically too. >> Config40 extends Configuration <-- annotated with urn:infinispan:config:4.0 and used to generate the 4.0 schema, parser, etc. >> Config41 extends Configuration <-- annotated with urn:infinispan:config:4.1 and used to generate the 4.1 schema, parser, etc. >> >> this would apply to other config beans too. Would this work? Or would this result in an unmanageable explosion of Xyz40, Xyz41, Xyz50, etc beans? :) > > +1 > you only need to maintain e new bean as long as you seem fit (I > suppose a major version as a rule of thumb), and you can update older > configuration parsers to contain special code to "fix" old > incompatible configurations adapting to eventual new ones, add > implicit defaults, adapt to new interfaces, or throw / log appropriate > warnings. > > Cheers, > Sanne > >> >> Cheers >> Manik >> >> >> >> On 12 May 2010, at 18:33, Vladimir Blagojevic wrote: >> >>> More comments from Alexey. Should have kept him on the cc from the beginning. >>> On 2010-05-12, at 1:09 PM, Alexey Loubyansky wrote: >>> >>>> On 5/12/2010 5:18 PM, Vladimir Blagojevic wrote: >>>>> Thanks a lot Alexey. I think that we are going to follow the approach outlined below. Please have a quick look for my reasoning and see if it is flawed. >>>> >>>> It's alright. About the namespace, actually it's a matter of personal taste and reasoning. E.g. have a look at the following namespaces from other JBoss projects. They are not URL-based and some do include the version in the namespace. Users switching from one version to another will still have to just adjust the namespace. Or maybe even not doing that if your unmarshalling layer could recognize the previous configuration version by itself. >>>> >>>> registerEntity("urn:jboss:aop-deployer", "aop-deployer_1_1.xsd"); >>>> registerEntity("urn:jboss:aop-beans:1.0", "aop-beans_1_0.xsd"); >>>> registerEntity("urn:jboss:bean-deployer", "bean-deployer_1_0.xsd"); >>>> registerEntity("urn:jboss:bean-deployer:2.0", "bean-deployer_2_0.xsd"); >>>> registerEntity("urn:jboss:javabean:1.0", "javabean_1_0.xsd"); >>>> registerEntity("urn:jboss:javabean:2.0", "javabean_2_0.xsd"); >>>> registerEntity("urn:jboss:spring-beans:2.0", "mc-spring-beans_2_0.xsd"); >>>> registerEntity("urn:jboss:policy:1.0", "policy_1_0.xsd"); >>>> registerEntity("urn:jboss:osgi-beans:1.0", "osgi-beans_1_0.xsd"); >>>> registerEntity("urn:jboss:seam-components:1.0", "seam-components_1_0.xsd"); >>>> registerEntity("urn:jboss:security-config:4.1", "security-config_4_1.xsd"); >>>> registerEntity("urn:jboss:security-config:5.0", "security-config_5_0.xsd"); >>>> registerEntity("urn:jboss:jndi-binding-service:1.0", "jndi-binding-service_1_0.xsd"); >>>> registerEntity("urn:jboss:user-roles:1.0", "user-roles_1_0.xsd"); >>>> >>>> >>>>> If you are interested maybe we can collaborate on a project that we made for automatic configuration HTML reference file generation. We used annotated XML configuration pojos, along with a bit more additional metadata attached to each field to automatically generate configuration HTML references. Have a look at: >>>>> http://docs.jboss.org/infinispan/4.1/apidocs/config.html >>>> >>>> Not sure whether I'll get involved but I think it could be useful for other projects as well. Is it a separate standalone project? >>>> >>>> Thanks, >>>> Alexey >>>> >>>>> Best regards, >>>>> Vladimir >>>>> >>>>> >>>>> On 2010-05-12, at 11:11 AM, Vladimir Blagojevic wrote: >>>>> >>>>>> Hey all, >>>>>> >>>>>> After consultation with Alexey I think the following emerges as the best approach for management of xml schemas, configuration pojos and configuration file backward compatibility. >>>>>> >>>>>> We should remove references to schema version in namespace and we might even rename namespace to something like "http://infinispan.org/xml/ns/ispn" and use a prefix "ispn" rather than tns. We could roll this in 4.1 final release. We leave 4.0 schemas as is, but 4.1 signifies a break and a new schema name-spacing that we intend to keep. How do we treat customer who want to use their 4.0 configuration files in 4.1? We tell them to remove references to old namespace from their configuration files. Thanks to ISPN-431 they are not affected. >>>>>> >>>>>> Since we removed references to configuration version in schema, as far as our configuration beans go, we are fine as long as we add properties to elements and even adding new configuration elements in ok. In essence, we are fine as long as we do not remove/rename existing attributes and elements from our configuration pojos. Adding new elements to configuration will still work. For example, lets say that 5.0 adds some configuration elements regarding JPA. Reading 4.1 configuration file in 5.0 is ok since we kept all those elements from 4.1 in 5.0, and for JPA element default configuration settings are initialized anyway. >>>>>> >>>>>> Let me know what you guys think. >>>>>> >>>>>> Vladimir >>>>>> >>>>>> >>>>>> >>>>>> On 2010-05-11, at 5:43 PM, Alexey Loubyansky wrote: >>>>>> >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> yes, that's tricky. I can't say we have an elegant solution for that. >>>>>>> >>>>>>> I can't tell you what we do wrt EJB metadata (ejb-jar.xml/jboss.xml) as an example. >>>>>>> For jboss.xml we have common JBossMetaData. >>>>>>> http://anonsvn.jboss.org/repos/jbossas/projects/metadata/ejb/trunk/src/ma... >>>>>>> >>>>>>> It contains binding annotations but w/o the schema-level ones such namespace, etc. Then per schema version we create a top level class, e.g. >>>>>>> http://anonsvn.jboss.org/repos/jbossas/projects/metadata/ejb/trunk/src/ma... >>>>>>> http://anonsvn.jboss.org/repos/jbossas/projects/metadata/ejb/trunk/src/ma... >>>>>>> >>>>>>> There we specify the namespace and which properties we want to bind. So, actually, for some schemas common JBossMetaData contains more metadata than it is available in those schemas but those properties are just not bound for those schema versions. But the deployers regardless of the deployment descriptor version deployed use the same JBossMetaData API. >>>>>>> In this case, though, it's only for the top-level class (root element). Although, we could have some tricks for other classes/elements as well. >>>>>>> >>>>>>> Other metadata (sub)projects (web, ear, rar, etc) use the same approach. (There are also tests for consistency between XSD/DTD and Java bindings, i.e. structural equivalence) >>>>>>> >>>>>>> What is a bit different, we don't include schema version in the namespace. Schema versions are different but the namespace stays the same. The same is true for JEE spec schemas. >>>>>>> But even if we did, the current approach would still work. >>>>>>> >>>>>>> If you have some tricky cases/requirements then let's discuss them on the forums. It might be relevant to other projects as well. >>>>>>> >>>>>>> Best regards, >>>>>>> Alexey >>>>>>> >>>>>>> On 5/11/2010 9:46 PM, Vladimir Blagojevic wrote: >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> Need an advice regarding best practices when it comes to XML schema management and references in configuration files. In infinispan project we have used JAXB annotated classes to annotate configuration pojos, automate manage configuration loading, and do schema creation. We have used the package-info.java files annotated with JAXB annotations to declare schema namespaces[1]. Then in turn we have generated XML schema file using JAXBContext#generateSchema. >>>>>>>> >>>>>>>> The current namespace is urn:infinispan:config:4.0, but this will change to urn:infinispan:config:4.1, urn:infinispan:config:5.0, etc in the future. What are our options for configuration file backward-compatibility? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>> >>> Vladimir Blagojevic >>> JBoss Clustering Team >>> JBoss by Red Hat >>> >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Manik Surtani >> manik(a)jboss.org >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I'd say yes, unless the cost is prohibitively expensive in terms of hours needed to develop support for such backward compatibility (here we would definitely need xyz40, xyz50 beans), code maintenance, support for HTML configuration reference creation, testing etc etc. If you do not mind I'd like to push this to 5.0 if we decide such a feature is a must.