[blueprint transaction] schema issues

[Lin Sun <li...@gmail.com>]

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

Re: [blueprint transaction] schema issues

[Lin Sun <li...@gmail.com>]

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 <jo...@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
>

Re: [blueprint transaction] schema issues

[Joe Bohn <jo...@gmail.com>]

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