[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tuscany-user
Subject:    Re: Problem binding an SDO component using JSON-RPC with SCA 2.0
From:       Francisco Quevedo <F.Quevedo.Fernandez () cs ! cardiff ! ac ! uk>
Date:       2010-11-08 13:07:18
Message-ID: 4CD7F606.4030904 () cs ! cardiff ! ac ! uk
[Download RAW message or body]

Hi Simon,

Thank you very much for your help. I really appreciate it.

After consider the alternatives (another one is create a "proxy 
component" that uses  JAXB classes and place it between the SDO and the 
Widget component but it's quite messy). I will use your recommendation 
of using JAXB classes instead of SDO. I've tried it and works fine. 
Although, I will have a look at how we can modify the JSON 
transformation in order to tell the difference between case sensitive 
methods.

Best wishes,
Fran


On 08/11/2010 10:53, Simon Laws wrote:
> Hi Fran
>
> I'm not making a huge amount of progress with this issue. I ported the
> sample to the latest 2.x code (and found a few issues with Tuscany for
> which I'll raise separate mails) but I confirmed that I still see the
> same error that you report on M5.1.
>
> As per the error the SDO ClassImpl class does provide two
> implementations of the getURI operation...
>
> getURI(0 params)
> getUri((0 params)
>
> Note the difference in case. The Jackson JSON parse complains about
> this as it's can't handle property names that differ only by case.
>
> Now I don't know why the SDO guys chose to provide these two different
> operations but they seem to have done it on purpose as one calls the
> other. Also any fix to correct that would be involved as it would
> require an SDO release.
>
> There are a couple of options I'm looking at
>
> - can we annotate the SDO in some way to get Jackson to ignore the URI
> attribute. I don't either like this option or hold out much hope. This
> is because the CallImpl is a attribute of a base class from which
> ProductImpl extends so not sure how to get round that. Also manually
> modifying generated classed is just a pain.
>
> - Can we configure Jackson to ignore it or can we look at alternatives
> to Jackson so see if we can configure our way round this.
>
> I note in the sample you're generating JAXB beans. Is it possible for
> you to use JAXB in place of SDO in the short term and see if we can
> get this working that way?
>
> Regards
>
> Simon
>

[prev in list] [next in list] [prev in thread] [next in thread]