aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lin Sun <linsun....@gmail.com>
Subject Re: [blueprint transaction] schema issues
Date Tue, 03 Aug 2010 13:48:14 GMT
Hi Joe

Thanks for the comment.  I'd think having two namespace handlers both
installed and exposed as OSGi services would work, but like you say,
it'd be clumsy.

I think you are proposing 1 name space handler handles more than one
schema and I think it is possible to code that way, but I am not sure
if that is a good idea:

Conversion code:  no/little change to existing code, we can just
plugin in the conversion service if avail.  Conversion service can do
simply convert to just update the version of the target name space or
do things beyond that if it is needed, for example convert attribute
or element names.

Name space Handler handles & 1+ schemas:   having 1 name space handler
handles 1+ schemas would require lots of changes in name space handler
registry, parser and name space handler itself.  It only works if the
schemas are fully back ward compatible, as the name space handler is
only designed to parse the XML definition that is built on the latest
version of the schema.  The conversion service could convert the XML
definition to be compatible to the latest version of the schema which
is a more flexible approach imho.

Lin

On Mon, Aug 2, 2010 at 11:24 PM, Joe Bohn <joebohn@gmail.com> wrote:
>
> 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
>

Mime
View raw message