10:11 a.m.
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...