TUSCANY-2939 - Supporting HTML Content Type when using Generic Collection with Atom Binding

[Luciano Resende <lu...@gmail.com>]

Tuscany currently supports two Collection interfaces for the Atom
Binding, one based on the Apache Abdera models, and another based on
generics that uses Tuscany Databinding to transform the atom content
to business objects. TUSCANY-2939 expose the scenario where you want
to use the generic collection and reference a regular atom feed with
html entries, which causes NPE exceptions due to databinding framework
trying to parse html as xml. For now, I have a fix/workaround that
checks the feed entry content type, and only uses the databinding
framework when the contents are XML and default back to a Item when
the content type is HTML, but wanted to hear from the databinding
experts if there is any better solution here...

Thoughts ?

-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: TUSCANY-2939 - Supporting HTML Content Type when using Generic Collection with Atom Binding

[Simon Laws <si...@googlemail.com>]

OperationSelectors would seem more appropriate for defining how
protocol messages map to service implementation operations. Wire
format seems more suited to transforming content types into the
arguments the implementation operations require.

Without a custom operation selector, i.e. in the default case, the
mapping between atom/http operations must be specified somehow.
Several approaches are floating around

- convention
    Assume that methods will be called get, put etc. I think we
already support this
- annotation
    As per JAX-RS. We would need some way of getting this information
into the binding
- a specific data interface
    As per our current data interface. I believe this can still be
used over other bindings

With customization of the operation selection we could either go with
something like Ant is suggesting

<operationselection.atomcustom userclass="some.pkg.SomeClass"/>

And/or something more declarative in a similar way that the JMS spec
deals with this

<operationselection.atomdefault>
    <operation name="GET" nativeOperation="myGet"/>
    etc
</operationselection.atomdefault>

With binding.atom is the uri of the binding always the path to a collection?

Simon

Re: TUSCANY-2939 - Supporting HTML Content Type when using Generic Collection with Atom Binding

[ant elder <an...@apache.org>]

On Tue, Jun 2, 2009 at 8:07 AM, Luciano Resende <lu...@gmail.com> wrote:
> On Mon, Jun 1, 2009 at 11:55 PM, ant elder <an...@gmail.com> wrote:
>> On Thu, May 28, 2009 at 10:18 PM, Luciano Resende <lu...@gmail.com> wrote:
>>> Tuscany currently supports two Collection interfaces for the Atom
>>> Binding, one based on the Apache Abdera models, and another based on
>>> generics that uses Tuscany Databinding to transform the atom content
>>> to business objects. TUSCANY-2939 expose the scenario where you want
>>> to use the generic collection and reference a regular atom feed with
>>> html entries, which causes NPE exceptions due to databinding framework
>>> trying to parse html as xml. For now, I have a fix/workaround that
>>> checks the feed entry content type, and only uses the databinding
>>> framework when the contents are XML and default back to a Item when
>>> the content type is HTML, but wanted to hear from the databinding
>>> experts if there is any better solution here...
>>>
>>> Thoughts ?
>>>
>>
>> Would the ideal solution be to avoid application code needing to use
>> those Collection interfaces? We can do that now that the Tuscany
>> runtime has the wireformat and operation selection mechanisms so all
>> this protocol specific code could be put into custom
>> wireformat/operation selectors.
>>
>
> I was hopping that JAX-RS would be the best solution here, but I'm
> open to ideas...
>
> Using wireformat/operation selectors, what would be the user
> experience to map HTTP operations to their implementation operations
> when developing a new SCA component; also, how to enforce that these
> operations follow a giving expected pattern ?
>

I guess it could be something like and atomdefault and atomcustom wireformats:

<binding.atom>
   <wireformat.atomdefault/>
</binding.atom>

and also support user application code with:

<binding.atom>
   <wireformat.atomcustom userclass="some.pkg.SomeClass"/>
</binding.atom>

The atomdefault would do something similar to what happens today doing
whatever generic transformation is possible, and the atomcustom
enables easily plugging in user code to to the protocol-to-application
transformation and thats probably what you'd use most often.

The idea being that SCA applications are supposed to be protocol
neutral so shouldn't be using any protocol specific code like the
Abdera Collections, so where thats not easy to do for a particular
protocol in a generic way the code that does that goes into a
wireformat not the application service or reference code. A problem
with what we have today is you can't really rewire things that are
written to use <binding.atom> or add <binding.atom> to an existing
service like our helloworld samples, if we had these wireformat
extensions you could.

   ...ant

Re: TUSCANY-2939 - Supporting HTML Content Type when using Generic Collection with Atom Binding

[Luciano Resende <lu...@gmail.com>]

On Mon, Jun 1, 2009 at 11:55 PM, ant elder <an...@gmail.com> wrote:
> On Thu, May 28, 2009 at 10:18 PM, Luciano Resende <lu...@gmail.com> wrote:
>> Tuscany currently supports two Collection interfaces for the Atom
>> Binding, one based on the Apache Abdera models, and another based on
>> generics that uses Tuscany Databinding to transform the atom content
>> to business objects. TUSCANY-2939 expose the scenario where you want
>> to use the generic collection and reference a regular atom feed with
>> html entries, which causes NPE exceptions due to databinding framework
>> trying to parse html as xml. For now, I have a fix/workaround that
>> checks the feed entry content type, and only uses the databinding
>> framework when the contents are XML and default back to a Item when
>> the content type is HTML, but wanted to hear from the databinding
>> experts if there is any better solution here...
>>
>> Thoughts ?
>>
>
> Would the ideal solution be to avoid application code needing to use
> those Collection interfaces? We can do that now that the Tuscany
> runtime has the wireformat and operation selection mechanisms so all
> this protocol specific code could be put into custom
> wireformat/operation selectors.
>

I was hopping that JAX-RS would be the best solution here, but I'm
open to ideas...

Using wireformat/operation selectors, what would be the user
experience to map HTTP operations to their implementation operations
when developing a new SCA component; also, how to enforce that these
operations follow a giving expected pattern ?

-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: TUSCANY-2939 - Supporting HTML Content Type when using Generic Collection with Atom Binding

[ant elder <an...@gmail.com>]

On Thu, May 28, 2009 at 10:18 PM, Luciano Resende <lu...@gmail.com> wrote:
> Tuscany currently supports two Collection interfaces for the Atom
> Binding, one based on the Apache Abdera models, and another based on
> generics that uses Tuscany Databinding to transform the atom content
> to business objects. TUSCANY-2939 expose the scenario where you want
> to use the generic collection and reference a regular atom feed with
> html entries, which causes NPE exceptions due to databinding framework
> trying to parse html as xml. For now, I have a fix/workaround that
> checks the feed entry content type, and only uses the databinding
> framework when the contents are XML and default back to a Item when
> the content type is HTML, but wanted to hear from the databinding
> experts if there is any better solution here...
>
> Thoughts ?
>

Would the ideal solution be to avoid application code needing to use
those Collection interfaces? We can do that now that the Tuscany
runtime has the wireformat and operation selection mechanisms so all
this protocol specific code could be put into custom
wireformat/operation selectors.

   ...ant