aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: [blueprint transaction] schema issues
Date Tue, 03 Aug 2010 03:24:28 GMT

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.


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 and
> 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


View raw message