On Tue, Jun 2, 2009 at 8:07 AM, Luciano Resende <[email protected]> wrote: > On Mon, Jun 1, 2009 at 11:55 PM, ant elder <[email protected]> wrote: >> On Thu, May 28, 2009 at 10:18 PM, Luciano Resende <[email protected]> >> 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
