This is an interesting problem.
Your approach registering the service twice seemed reasonable to me. But I guess the fact that we only have the updated schema around is the real issue.
Conversion is certainly an option but I wonder if we should be looking for a solution that really can support both versions of the schema concurrently (without converting one to the other). This is one of the benefits that we note about OSGi (the ability to support multiple versions of a component concurrently) and so it would seem consistent if we can come up with a way to do that for things like these schema changes as well. I don't know quite what that would look like - I'm just wondering if it worth the effort to try to come up with something. One brute force method might be to create a two services - one for each version of the schema (each using a unique version of the schema) - but that seems very clumsy and not very extensible.
Joe On 8/2/10 1:40 PM, Lin Sun wrote:
Hi I wanted to give people an update on the blueprint transaction that I have been working on lately. I have added the support for bundle wide transaction configuration, in addition to the bean level transaction configuration that was supported with the 0.1 release. I also made some changes to the transaction.xsd schema file, as I added a new attribute and specified the transactionAttribute is required. With the schema changes, there is one issue. It seems right to me that I need to update the version of the schema to be 1.1.0 (instead of the previously 1.0.0). So I did the following in order to support the blueprint definition file that still uses the 1.0.0 version of the transaction name space. 1) update the version in transaction.xsd to 1.1.0 2) update the blueprint XML definition file for transaction-blueprint to register both http://aries.apache.org/xmlns/transactions/v1.0.0 and http://aries.apache.org/xmlns/transactions/v1.1.0 as the value for osgi.service.blueprint.namespace. However, this doesn't solve the prob. The javax.xml.Validator.validate() failed when being called by Parser. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'tx:transaction'. This seems a reasonable error to me. The above step 2 made sure that when the transaction element is detected, the transaction name space handler (1.1.0 version) is used. However, Parser is unable to validate the blueprint XML definition file that uses the 1.0.0 transaction name space with the 1.1.0 transaction schema. So I think the following needs to be done, in order for support blueprint definition file that uses the transaction 1.0.0 name space. 1) whenever blueprint parser detects a blueprint definition file that uses the older version of transaction name space, it will attempt to convert the blueprint definition file to use the latest version of the transaction name space. Thoughts? Thx Lin
-- Joe
