You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2010/08/27 09:05:46 UTC
Fwd: tutorial - using binding.rest with non-jaxrs service?
Is binding.rest supposed to work with arbitrary services that don't
have any jaxrs annotations? And if so how do you configure it to do
that?
I'm trying it with the sample at:
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/hema/
The service interface is:
@Remotable
public interface HelloworldService {
String sayHello(String name);
}
And i've tried varrious binding configs such as:
<tuscany:binding.rest name="rest">
<tuscany:wireFormat.json />
<tuscany:operationSelector.rpc />
</tuscany:binding.rest>
but only get errors such as IllegalArgumentException: wrong number of arguments
Any comments?
...ant
---------- Forwarded message ----------
From: ant elder <an...@gmail.com>
Date: Thu, Aug 26, 2010 at 1:32 PM
Subject: Re: tutorial
To: user@tuscany.apache.org
On Thu, Aug 26, 2010 at 12:12 PM, ant elder <an...@gmail.com> wrote:
> On Thu, Aug 26, 2010 at 8:57 AM, Hemavathy S <he...@gmail.com> wrote:
>> Hi,
>>
>>> Thereare multiple examples on using embedded http in the test folder
>>> for the binding-http-runtime
>>
>> Can you please point one. I use ant to build and in 2.0-M5 samples I
>>
>> checked some webapps and could not find build.xml which builds the war with
>> lib folder.
>>
>> I only downloaded the binaries.
>>
>> I copied all the files from lib folder to WEB-INF\lib. Then also
>>
>> tomcat keeps giving "org.apache.catalina.core.StandardContext start SEVERE:
>> Error filter Start.
>>
>> So it doesnot recognize the tuscany filter.
>>
>> What do I do?
>>
>> Regards
>>
>> -Hema
>>
>
> Lets create a sample that does exactly what you need so we can show
> exactly what you need to do. I've started this at
>
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/hema/
>
> thats so far just a copy of the helloworld-jsp sample, i'll now go
> update it to have an Ant build script and to add binding-ws,
> binding-rmi, and binding-rest and try to get that working with the Ant
> build. I'll post back here as progress is made.
>
> The current Tuscany modules don't make it particularly easy to use
> non-Maven build systems so this could be a useful exercise to see just
> how hard it is or what we could do to help.
>
> ...ant
>
Ok there is now an Ant build script committed in that svn location
which works for binding.ws, binidng.rmi and the jsp.
It uses the single jar, tuscany-base-nodep, which includes everything
needed to run a simple tuscany application, its not in the m5 release
but you can find the jar at:
https://repository.apache.org/content/repositories/snapshots/org/apache/tuscany/sca/shades/tuscany-base-nodep/2.0-SNAPSHOT/tuscany-base-nodep-2.0-SNAPSHOT.jar
I'll also look at whats needed to do that using the individual tuscany
module jars instead of teh one base-nodep one.
The sample doesn't yet include the rest binding, looking at that now...
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@apache.org>.
On Fri, Aug 27, 2010 at 6:13 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Fri, Aug 27, 2010 at 12:05 AM, ant elder <an...@gmail.com> wrote:
>> Is binding.rest supposed to work with arbitrary services that don't
>> have any jaxrs annotations? And if so how do you configure it to do
>> that?
>>
>
> The REST Binding is a superset of the HTTP Binding,
This came up before, can you explain why you think that makes sense?
Surely rest should be a subset of whats possible over http?
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@gmail.com>.
On Fri, Aug 27, 2010 at 7:03 PM, Raymond Feng <en...@gmail.com> wrote:
> 2) The other perspective is that SCA doesn't want to reinvent all the
> wheels. IMO, using JAX-WS, JAX-RS annotations to provide the mapping in java
> for the certain metadata is beneficial to SCA.
Its fine for things like jaxws annotations in existing class be taken
into account by the ws binding, but it wouldn't be fine if the ws
binding didn't work unless you used jaxws annotations. The same
applies to jaxrs, so if binding.rest requires jaxrs annotations then
imho we should consider if it wouldn't be better as an implementation
instead like the existing implementation.jaxrs.
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Raymond Feng <en...@gmail.com>.
1) I have a set of slides describing the RESTfult services using Tuscany SCA. I can share it.
2) The other perspective is that SCA doesn't want to reinvent all the wheels. IMO, using JAX-WS, JAX-RS annotations to provide the mapping in java for the certain metadata is beneficial to SCA.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________
On Aug 27, 2010, at 10:44 AM, ant elder wrote:
> On Fri, Aug 27, 2010 at 6:40 PM, Luciano Resende <lu...@gmail.com> wrote:
>> On Fri, Aug 27, 2010 at 10:37 AM, ant elder <an...@apache.org> wrote:
>>> On Fri, Aug 27, 2010 at 6:13 PM, Luciano Resende <lu...@gmail.com> wrote:
>>>
>>>>
>>>> I'd try:
>>>>
>>>> <tuscany:binding.rest name="rest">
>>>> <tuscany:operationSelector.rpc />
>>>> <tuscany:response>
>>>> <tuscany:wireFormat.json />
>>>> </tuscany:response>
>>>> </tuscany:binding.rest>
>>>>
>>>> This would then be accessible via URL
>>>>
>>>> <base service URI> ?method=<operation name>&parm1=<value>&parm2=<value>
>>>>
>>>
>>> I've tried that and still get the IllegalArgumentException: wrong
>>> number of arguments. Looking in the code thats caused by the loop at
>>> line 113 of RPCOperationSelectorInterceptor which is only adding
>>> things to the message if the operation parameters have the jaxrs
>>> QueryParam annotation, which this service doesn't use. Whats the
>>> intention, should the binding work with arbitrary services or only for
>>> for jaxrs classes?
>>>
>>> ...ant
>>>
>>
>> Another option is to add support for declaratively add the mapping,
>> which is in my todo list, but not yet implemented. But, stepping back,
>> why not use the JAX-RS annotations ?
>>
>
> Because one of the big points of SCA is that the service
> implementations are protocol neutral?
>
> Can you say a bit about what you're thinking of for "support for
> declaratively add the mapping"?
>
> ...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Aug 27, 2010 at 10:44 AM, ant elder <an...@apache.org> wrote:
> Can you say a bit about what you're thinking of for "support for
> declaratively add the mapping"?
>
In summary, adding some of these configurations via composite file
(e.g http operation mapping, etc)
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@apache.org>.
On Fri, Aug 27, 2010 at 6:40 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Fri, Aug 27, 2010 at 10:37 AM, ant elder <an...@apache.org> wrote:
>> On Fri, Aug 27, 2010 at 6:13 PM, Luciano Resende <lu...@gmail.com> wrote:
>>
>>>
>>> I'd try:
>>>
>>> <tuscany:binding.rest name="rest">
>>> <tuscany:operationSelector.rpc />
>>> <tuscany:response>
>>> <tuscany:wireFormat.json />
>>> </tuscany:response>
>>> </tuscany:binding.rest>
>>>
>>> This would then be accessible via URL
>>>
>>> <base service URI> ?method=<operation name>&parm1=<value>&parm2=<value>
>>>
>>
>> I've tried that and still get the IllegalArgumentException: wrong
>> number of arguments. Looking in the code thats caused by the loop at
>> line 113 of RPCOperationSelectorInterceptor which is only adding
>> things to the message if the operation parameters have the jaxrs
>> QueryParam annotation, which this service doesn't use. Whats the
>> intention, should the binding work with arbitrary services or only for
>> for jaxrs classes?
>>
>> ...ant
>>
>
> Another option is to add support for declaratively add the mapping,
> which is in my todo list, but not yet implemented. But, stepping back,
> why not use the JAX-RS annotations ?
>
Because one of the big points of SCA is that the service
implementations are protocol neutral?
Can you say a bit about what you're thinking of for "support for
declaratively add the mapping"?
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Florian MOGA <mo...@gmail.com>.
Hi Simon,
I'm currently studying things for a major enhancement on the comet binding
and helping out with the samples when finding time. It's fine if you
estimate completing fixes on the json databinding this or the next week. Let
me know when you're done and I'll proceed with improving the sample.
On Wed, Sep 29, 2010 at 1:40 PM, Simon Laws <si...@googlemail.com>wrote:
> On Wed, Sep 29, 2010 at 11:20 AM, Florian MOGA <mo...@gmail.com> wrote:
> > I've seen Simon started fixing things on the json databinding and I would
> > like to update the jsonp sample as well to also use arrays and
> BigDecimal.
> > Are we keeping the current format for the scdl or switch to the wire
> > declaration? I can't estimate how much such a change would take but if it
> > needs some time I propose to deffer it as it looks like a nice
> enhancement
> > for the next releases after 2.0.
> >
>
> 1.x is a little odd at the moment in that I have JSONP working there
> with the JSON databinding from 2.x. Other binding that use this
> databinding, e.g. JSON-RPC don't work with the 2.x version but I'm not
> of a mind to fix that in 1.x as it should all work in 2.x.
>
> I 'm yet to port the array fix over to 2.x. I'll do that this week
> some time. Also I have a few local BigDecimal changes that I'm
> thinking about. I'll decide if they need committing this week if I get
> time.
>
> Having said this any samples in 2.x to test this stuff are very much
> appreciated. Even better if you want to help out porting the fixes.
>
> Re. the SCDL format. I'd like to try the HTTP wire format varient but
> haven't had time yet. I'd like to get the 2.0 beta out first.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Sep 29, 2010 at 11:20 AM, Florian MOGA <mo...@gmail.com> wrote:
> I've seen Simon started fixing things on the json databinding and I would
> like to update the jsonp sample as well to also use arrays and BigDecimal.
> Are we keeping the current format for the scdl or switch to the wire
> declaration? I can't estimate how much such a change would take but if it
> needs some time I propose to deffer it as it looks like a nice enhancement
> for the next releases after 2.0.
>
1.x is a little odd at the moment in that I have JSONP working there
with the JSON databinding from 2.x. Other binding that use this
databinding, e.g. JSON-RPC don't work with the 2.x version but I'm not
of a mind to fix that in 1.x as it should all work in 2.x.
I 'm yet to port the array fix over to 2.x. I'll do that this week
some time. Also I have a few local BigDecimal changes that I'm
thinking about. I'll decide if they need committing this week if I get
time.
Having said this any samples in 2.x to test this stuff are very much
appreciated. Even better if you want to help out porting the fixes.
Re. the SCDL format. I'd like to try the HTTP wire format varient but
haven't had time yet. I'd like to get the 2.0 beta out first.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@gmail.com>.
I think the current state is that although the binding.http has the
start of some support for this the tuscany-binding-jsonp-runtime still
works and will take prcidence if that jar is included. So for the time
being i think it should all be fine just using binding.jsonp and
binding-jsonp-runtime (Simon has been using that i think so can
correct me if thats wrong?).
The OASIS bindings TC has been actively looking at binding.http
recently, there is some doc on uses cases and there should be some
spec updates and draft binding.http schema quite soon so i was waiting
to see what that looked like before taking the tuscany impl much
further just now. See oasis email thread -
http://lists.oasis-open.org/archives/sca-bindings/201009/msg00030.html.
...ant
On Wed, Sep 29, 2010 at 11:20 AM, Florian MOGA <mo...@gmail.com> wrote:
> I've seen Simon started fixing things on the json databinding and I would
> like to update the jsonp sample as well to also use arrays and BigDecimal.
> Are we keeping the current format for the scdl or switch to the wire
> declaration? I can't estimate how much such a change would take but if it
> needs some time I propose to deffer it as it looks like a nice enhancement
> for the next releases after 2.0.
>
> On Mon, Sep 6, 2010 at 5:54 PM, Simon Laws <si...@googlemail.com>
> wrote:
>>
>> On Sat, Sep 4, 2010 at 7:06 AM, ant elder <an...@apache.org> wrote:
>> > On Tue, Aug 31, 2010 at 3:21 PM, ant elder <an...@apache.org> wrote:
>> >
>> >>
>> >> I don't think there is a single correct answer for how to arrange all
>> >> that. There is a good chance that the user that wanted
>> >> wireformat.jsonrpc instead of binding.jsonrpc will want the same in
>> >> 2.x. Conversely, it is simpler to type with individual bindings
>> >> instead of wireFormats, eg:
>> >>
>> >> <binding.jsonp>
>> >>
>> >> instead of:
>> >>
>> >> <binding.http>
>> >> <wireFormat.jsonp/>
>> >> </binding.http>
>> >>
>> >> Perhaps we should just support all the different approaches? It does
>> >> seem good if however we do it that there is minimal code duplication
>> >> so perhaps we should look at arranging the code so we can easily
>> >> support <binding.jsonp> scdl but that gets translated into a runtime
>> >> config thats shares all the code of the equivalent of binding.http
>> >> with wireFormat.jsonp.
>> >>
>> >> Comments?
>> >>
>> >
>> > No comments so i went ahead and tried that with the jsonp binding. The
>> > JSONPBinding class in its constructor configures an HTTPBinding [1]
>> > and the binding-http-runtime does all the work now so
>> > binding-jsonp-runtime is no longer needed.
>> >
>> > That looks good to me, and as function gets added to the http binding
>> > (eg support for basic auth, gzip encoding, etc) the jsonp binding
>> > could also pick that up.
>> >
>> > ...ant
>> >
>> > [1]
>> > https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/binding-jsonp/src/main/java/org/apache/tuscany/sca/binding/jsonp/JSONPBinding.java
>> >
>>
>> Sounds like a plan. It's messing up the tests in the old
>> binding-jsonp-runtime as there is some strange dependency on some of
>> the http runtime artifacts. Can we just remove this from the build
>> now?
>>
>> Simon
>>
>> --
>> Apache Tuscany committer: tuscany.apache.org
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
>
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Florian MOGA <mo...@gmail.com>.
I've seen Simon started fixing things on the json databinding and I would
like to update the jsonp sample as well to also use arrays and BigDecimal.
Are we keeping the current format for the scdl or switch to the wire
declaration? I can't estimate how much such a change would take but if it
needs some time I propose to deffer it as it looks like a nice enhancement
for the next releases after 2.0.
On Mon, Sep 6, 2010 at 5:54 PM, Simon Laws <si...@googlemail.com>wrote:
> On Sat, Sep 4, 2010 at 7:06 AM, ant elder <an...@apache.org> wrote:
> > On Tue, Aug 31, 2010 at 3:21 PM, ant elder <an...@apache.org> wrote:
> >
> >>
> >> I don't think there is a single correct answer for how to arrange all
> >> that. There is a good chance that the user that wanted
> >> wireformat.jsonrpc instead of binding.jsonrpc will want the same in
> >> 2.x. Conversely, it is simpler to type with individual bindings
> >> instead of wireFormats, eg:
> >>
> >> <binding.jsonp>
> >>
> >> instead of:
> >>
> >> <binding.http>
> >> <wireFormat.jsonp/>
> >> </binding.http>
> >>
> >> Perhaps we should just support all the different approaches? It does
> >> seem good if however we do it that there is minimal code duplication
> >> so perhaps we should look at arranging the code so we can easily
> >> support <binding.jsonp> scdl but that gets translated into a runtime
> >> config thats shares all the code of the equivalent of binding.http
> >> with wireFormat.jsonp.
> >>
> >> Comments?
> >>
> >
> > No comments so i went ahead and tried that with the jsonp binding. The
> > JSONPBinding class in its constructor configures an HTTPBinding [1]
> > and the binding-http-runtime does all the work now so
> > binding-jsonp-runtime is no longer needed.
> >
> > That looks good to me, and as function gets added to the http binding
> > (eg support for basic auth, gzip encoding, etc) the jsonp binding
> > could also pick that up.
> >
> > ...ant
> >
> > [1]
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/binding-jsonp/src/main/java/org/apache/tuscany/sca/binding/jsonp/JSONPBinding.java
> >
>
> Sounds like a plan. It's messing up the tests in the old
> binding-jsonp-runtime as there is some strange dependency on some of
> the http runtime artifacts. Can we just remove this from the build
> now?
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Simon Laws <si...@googlemail.com>.
On Sat, Sep 4, 2010 at 7:06 AM, ant elder <an...@apache.org> wrote:
> On Tue, Aug 31, 2010 at 3:21 PM, ant elder <an...@apache.org> wrote:
>
>>
>> I don't think there is a single correct answer for how to arrange all
>> that. There is a good chance that the user that wanted
>> wireformat.jsonrpc instead of binding.jsonrpc will want the same in
>> 2.x. Conversely, it is simpler to type with individual bindings
>> instead of wireFormats, eg:
>>
>> <binding.jsonp>
>>
>> instead of:
>>
>> <binding.http>
>> <wireFormat.jsonp/>
>> </binding.http>
>>
>> Perhaps we should just support all the different approaches? It does
>> seem good if however we do it that there is minimal code duplication
>> so perhaps we should look at arranging the code so we can easily
>> support <binding.jsonp> scdl but that gets translated into a runtime
>> config thats shares all the code of the equivalent of binding.http
>> with wireFormat.jsonp.
>>
>> Comments?
>>
>
> No comments so i went ahead and tried that with the jsonp binding. The
> JSONPBinding class in its constructor configures an HTTPBinding [1]
> and the binding-http-runtime does all the work now so
> binding-jsonp-runtime is no longer needed.
>
> That looks good to me, and as function gets added to the http binding
> (eg support for basic auth, gzip encoding, etc) the jsonp binding
> could also pick that up.
>
> ...ant
>
> [1] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/binding-jsonp/src/main/java/org/apache/tuscany/sca/binding/jsonp/JSONPBinding.java
>
Sounds like a plan. It's messing up the tests in the old
binding-jsonp-runtime as there is some strange dependency on some of
the http runtime artifacts. Can we just remove this from the build
now?
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@apache.org>.
On Tue, Aug 31, 2010 at 3:21 PM, ant elder <an...@apache.org> wrote:
>
> I don't think there is a single correct answer for how to arrange all
> that. There is a good chance that the user that wanted
> wireformat.jsonrpc instead of binding.jsonrpc will want the same in
> 2.x. Conversely, it is simpler to type with individual bindings
> instead of wireFormats, eg:
>
> <binding.jsonp>
>
> instead of:
>
> <binding.http>
> <wireFormat.jsonp/>
> </binding.http>
>
> Perhaps we should just support all the different approaches? It does
> seem good if however we do it that there is minimal code duplication
> so perhaps we should look at arranging the code so we can easily
> support <binding.jsonp> scdl but that gets translated into a runtime
> config thats shares all the code of the equivalent of binding.http
> with wireFormat.jsonp.
>
> Comments?
>
No comments so i went ahead and tried that with the jsonp binding. The
JSONPBinding class in its constructor configures an HTTPBinding [1]
and the binding-http-runtime does all the work now so
binding-jsonp-runtime is no longer needed.
That looks good to me, and as function gets added to the http binding
(eg support for basic auth, gzip encoding, etc) the jsonp binding
could also pick that up.
...ant
[1] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/binding-jsonp/src/main/java/org/apache/tuscany/sca/binding/jsonp/JSONPBinding.java
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@apache.org>.
On Tue, Aug 31, 2010 at 12:10 AM, Luciano Resende <lu...@gmail.com> wrote:
> On Mon, Aug 30, 2010 at 3:51 PM, ant elder <an...@apache.org> wrote:
>>
>> If you really want to have all this is in just a single binding then
>> why not call it binding.http? Merging this function into binding.rest
>> makes no sense at all. REST is not RPC.
>>
>> ...ant
>>
>
> I would like to have one binding, independent if we call it REST or
> HTTP... some approach to easily provide some transition to that path
> is also described in [1].
>
> [1] http://markmail.org/message/gooxl7dfaxahxr7h
>
Maybe we should think about what we really want this to look like,
what function binding.http supports, how those functions compare to
what other bindings do, and what wireFormats are supported.
Presently binding.http has a default wireformat that is really json,
or jsonp infact as it supports the same as what binding.jsonp does. In
1.x binding.http has a wireFormat.jsonrpc should we do that in 2.x
instead of or as well as the jsonrpc binding? There is also now a
wireformat.httpXml which supports sending and receive xml payloads.
And then there's also binding.rest which has all the JAX-RS functions.
I don't think there is a single correct answer for how to arrange all
that. There is a good chance that the user that wanted
wireformat.jsonrpc instead of binding.jsonrpc will want the same in
2.x. Conversely, it is simpler to type with individual bindings
instead of wireFormats, eg:
<binding.jsonp>
instead of:
<binding.http>
<wireFormat.jsonp/>
</binding.http>
Perhaps we should just support all the different approaches? It does
seem good if however we do it that there is minimal code duplication
so perhaps we should look at arranging the code so we can easily
support <binding.jsonp> scdl but that gets translated into a runtime
config thats shares all the code of the equivalent of binding.http
with wireFormat.jsonp.
Comments?
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Simon Laws <si...@googlemail.com>.
Ok, it doesn't seem to affect the build so I checked the simple fix in
at revision: 992281. Obviously Raymond feel free to amend if you see
more to do.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Raymond Feng <en...@gmail.com>.
It looks good on the surface. I'll take a look later in more details.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________
On Sep 2, 2010, at 6:53 AM, Simon Laws wrote:
> On Thu, Sep 2, 2010 at 1:38 PM, ant elder <an...@apache.org> wrote:
>> On Tue, Aug 31, 2010 at 9:01 PM, Luciano Resende <lu...@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 12:10 PM, ant elder <an...@apache.org> wrote:
>>>> Mmm, it looks like its a problem with the json data binding not being
>>>> able to convert an int response value into a json string.
>>>>
>>>
>>> It looks like we might be missing two things in the JSON databinding :
>>>
>>> - A SimpleType transformer (e.g SimpleType2JSON)
>>> - Properly configuring the transformer in the PullTransformer file
>>> (src/main/resources/META-INF/org.apache.tuscany.databinding.PullTransformer)
>>> with something like
>>>
>>> org.apache.tuscany.sca.databinding.json.jackson.SimpleType2JSON;source=java:simpleType,target=JSON,weight=90000,public=false
>>>
>>> What does the "Databinding Experts" think ?
>>>
>>
>> Raymond, I think that question was to you as you wrote the json data
>> binding and I'm not sure anyone else understands it any detail how it
>> works, so have you any comments?
>>
>> ...ant
>>
>
> I took a quick look at this. The error in Florian's sample is
> occurring when the runtime tries to convert the primitve type response
> back to JSON representation. It has code to pick up strings but not
> primitives. In both cases I think it should just return the value
> as-is and not try to do any conversion on it. In the JSONP servlet
> we'll wrap the returned value in the callback name and, in the error
> case, I believe we expect to see something like....
>
> shareAgeCallback(54);
>
> I.e the value returned by public int shareAge(int age); is just
> presented as an int.
>
> This needs an extra test to see if the response target type is a
> primitive alongside the test to see it it's a String.
>
> I've made the change locally and this allows the sample to run however
> I'm having trouble with lots of failures in the full build at the
> moment (anyone else seeing failures?) so I'll hold back from checking
> it in. If you want to try it this is the change:
>
> Index: src/main/java/org/apache/tuscany/sca/databinding/json/jackson/Object2JSON.java
> ===================================================================
> --- src/main/java/org/apache/tuscany/sca/databinding/json/jackson/Object2JSON.java (revision
> 991885)
> +++ src/main/java/org/apache/tuscany/sca/databinding/json/jackson/Object2JSON.java (working
> copy)
> @@ -54,7 +54,7 @@
> }
> try {
> String value = mapper.writeValueAsString(source);
> - if (targetType == String.class || targetType == Object.class) {
> + if (targetType == String.class || targetType ==
> Object.class || targetType.isPrimitive()) {
> return value;
> } else if (JsonNode.class.isAssignableFrom(targetType)) {
> return JacksonHelper.createJsonParser(value).readValueAsTree();
>
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Sep 2, 2010 at 1:38 PM, ant elder <an...@apache.org> wrote:
> On Tue, Aug 31, 2010 at 9:01 PM, Luciano Resende <lu...@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 12:10 PM, ant elder <an...@apache.org> wrote:
>>> Mmm, it looks like its a problem with the json data binding not being
>>> able to convert an int response value into a json string.
>>>
>>
>> It looks like we might be missing two things in the JSON databinding :
>>
>> - A SimpleType transformer (e.g SimpleType2JSON)
>> - Properly configuring the transformer in the PullTransformer file
>> (src/main/resources/META-INF/org.apache.tuscany.databinding.PullTransformer)
>> with something like
>>
>> org.apache.tuscany.sca.databinding.json.jackson.SimpleType2JSON;source=java:simpleType,target=JSON,weight=90000,public=false
>>
>> What does the "Databinding Experts" think ?
>>
>
> Raymond, I think that question was to you as you wrote the json data
> binding and I'm not sure anyone else understands it any detail how it
> works, so have you any comments?
>
> ...ant
>
I took a quick look at this. The error in Florian's sample is
occurring when the runtime tries to convert the primitve type response
back to JSON representation. It has code to pick up strings but not
primitives. In both cases I think it should just return the value
as-is and not try to do any conversion on it. In the JSONP servlet
we'll wrap the returned value in the callback name and, in the error
case, I believe we expect to see something like....
shareAgeCallback(54);
I.e the value returned by public int shareAge(int age); is just
presented as an int.
This needs an extra test to see if the response target type is a
primitive alongside the test to see it it's a String.
I've made the change locally and this allows the sample to run however
I'm having trouble with lots of failures in the full build at the
moment (anyone else seeing failures?) so I'll hold back from checking
it in. If you want to try it this is the change:
Index: src/main/java/org/apache/tuscany/sca/databinding/json/jackson/Object2JSON.java
===================================================================
--- src/main/java/org/apache/tuscany/sca/databinding/json/jackson/Object2JSON.java (revision
991885)
+++ src/main/java/org/apache/tuscany/sca/databinding/json/jackson/Object2JSON.java (working
copy)
@@ -54,7 +54,7 @@
}
try {
String value = mapper.writeValueAsString(source);
- if (targetType == String.class || targetType == Object.class) {
+ if (targetType == String.class || targetType ==
Object.class || targetType.isPrimitive()) {
return value;
} else if (JsonNode.class.isAssignableFrom(targetType)) {
return JacksonHelper.createJsonParser(value).readValueAsTree();
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@apache.org>.
On Tue, Aug 31, 2010 at 9:01 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 12:10 PM, ant elder <an...@apache.org> wrote:
>> Mmm, it looks like its a problem with the json data binding not being
>> able to convert an int response value into a json string.
>>
>
> It looks like we might be missing two things in the JSON databinding :
>
> - A SimpleType transformer (e.g SimpleType2JSON)
> - Properly configuring the transformer in the PullTransformer file
> (src/main/resources/META-INF/org.apache.tuscany.databinding.PullTransformer)
> with something like
>
> org.apache.tuscany.sca.databinding.json.jackson.SimpleType2JSON;source=java:simpleType,target=JSON,weight=90000,public=false
>
> What does the "Databinding Experts" think ?
>
Raymond, I think that question was to you as you wrote the json data
binding and I'm not sure anyone else understands it any detail how it
works, so have you any comments?
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Aug 31, 2010 at 12:10 PM, ant elder <an...@apache.org> wrote:
> Mmm, it looks like its a problem with the json data binding not being
> able to convert an int response value into a json string.
>
It looks like we might be missing two things in the JSON databinding :
- A SimpleType transformer (e.g SimpleType2JSON)
- Properly configuring the transformer in the PullTransformer file
(src/main/resources/META-INF/org.apache.tuscany.databinding.PullTransformer)
with something like
org.apache.tuscany.sca.databinding.json.jackson.SimpleType2JSON;source=java:simpleType,target=JSON,weight=90000,public=false
What does the "Databinding Experts" think ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@apache.org>.
Mmm, it looks like its a problem with the json data binding not being
able to convert an int response value into a json string.
...ant
On Tue, Aug 31, 2010 at 5:52 PM, Florian MOGA <mo...@gmail.com> wrote:
> Thanks Ant. Line 45 is self-explanatory. That's what I was referring to as
> in the previous version of the binding only the instance variables were
> initialized with the objects coming from the framework. This wouldn't have
> brought any differences from the target contract. Didn't expect for changes
> in the service binding provider so I didn't check it out for updates earlier
> but it is actually logical to have this kind of operation there.
> I've committed the jsonp webapp sample which you can find here [0]. It
> simulates an app where you enter your pesonal data and share it online. I've
> used the cases where you submit from html, from javascript, used $.getJSON
> from jQuery and multiple services with different parameter types. If you
> check it out, you can see that it successfully works with services having
> String and Object parameters. For other primitive parameters, it gets a JSON
> Exception saying:
>
> org.json.JSONException: A JSONObject text must begin with '{' at character 1
> of 54
> org.json.JSONTokener.syntaxError(JSONTokener.java:451)
> org.json.JSONObject.<init>(JSONObject.java:180)
> org.json.JSONObject.<init>(JSONObject.java:327)
> org.apache.tuscany.sca.databinding.json.JSONHelper.toJSON(JSONHelper.java:100)
> org.apache.tuscany.sca.databinding.json.jackson.Object2JSON.transform(Object2JSON.java:65)
> org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
> org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:116)
> org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:243)
> org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
> org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:116)
> org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateOutput(MediatorImpl.java:410)
> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:87)
> org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:91)
> org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:74)
> org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:63)
> org.apache.tuscany.sca.core.assembly.impl.RuntimeEndpointImpl.invoke(RuntimeEndpointImpl.java:282)
> org.apache.tuscany.sca.binding.jsonp.runtime.JSONPServlet.invokeService(JSONPServlet.java:218)
> org.apache.tuscany.sca.binding.jsonp.runtime.JSONPServlet.service(JSONPServlet.java:63)
> org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:110)
> org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.doFilter(TuscanyServletFilter.java:94)
>
> It seems there are some more special cases for conversion than initially
> planned... I tried adding quotes or parentheses for the integer argument but
> it didn't solve the problem...
> Florian
> [0] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/contrib/samples/jsonp-webapp/
>
> On Tue, Aug 31, 2010 at 4:00 PM, ant elder <an...@gmail.com> wrote:
>>
>> On Tue, Aug 31, 2010 at 11:49 AM, Florian MOGA <mo...@gmail.com> wrote:
>> > Hi Simon,
>> > Thanks for pointing where can I find more info. I've taken a look at
>> > the DatabindingRuntimeWireProcessor and the only thing I'm trying to
>> > clarify
>> > is how tuscany finds out that a String array is actually hiding behind
>> > the
>> > Object[] argument when invoking the wire and decides to use JSON (even
>> > in
>> > the case when other databindings are included). Considering that
>> > databinding
>> > occurs between the service invocation from the binding and the actual
>> > service, I believe source contract type, operation, data types are taken
>> > from:
>> >
>> > wire.invoke(operation, args);
>> >
>> > I don't see how operation can be different and I'm not aware of a
>> > mechanism
>> > for determining what types exactly hide under Object[].
>> > I'm currently building a jsonp sample that will include the various ways
>> > of
>> > calling jsonp services (json objects, jquery, etc.). It will be good for
>> > testing and if you consider it good enough, for the samples/ directory
>> > too.
>>
>> The Operation object does include the data binding type information,
>> see methods such as getInputType which return DataType objects.
>> Binding impls set the type of data they expect, in the jsonp binding
>> see that done at line 45 of JSONPServiceBindingProvider.
>>
>> (Not sure if that was the question you're asking, does that help?)
>>
>> ...ant
>
>
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Florian MOGA <mo...@gmail.com>.
Thanks Ant. Line 45 is self-explanatory. That's what I was referring to as
in the previous version of the binding only the instance variables were
initialized with the objects coming from the framework. This wouldn't have
brought any differences from the target contract. Didn't expect for changes
in the service binding provider so I didn't check it out for updates earlier
but it is actually logical to have this kind of operation there.
I've committed the jsonp webapp sample which you can find here [0]. It
simulates an app where you enter your pesonal data and share it online. I've
used the cases where you submit from html, from javascript, used $.getJSON
from jQuery and multiple services with different parameter types. If you
check it out, you can see that it successfully works with services having
String and Object parameters. For other primitive parameters, it gets a JSON
Exception saying:
org.json.JSONException: A JSONObject text must begin with '{' at
character 1 of 54
org.json.JSONTokener.syntaxError(JSONTokener.java:451)
org.json.JSONObject.<init>(JSONObject.java:180)
org.json.JSONObject.<init>(JSONObject.java:327)
org.apache.tuscany.sca.databinding.json.JSONHelper.toJSON(JSONHelper.java:100)
org.apache.tuscany.sca.databinding.json.jackson.Object2JSON.transform(Object2JSON.java:65)
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:116)
org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:243)
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:116)
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateOutput(MediatorImpl.java:410)
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:87)
org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:91)
org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:74)
org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:63)
org.apache.tuscany.sca.core.assembly.impl.RuntimeEndpointImpl.invoke(RuntimeEndpointImpl.java:282)
org.apache.tuscany.sca.binding.jsonp.runtime.JSONPServlet.invokeService(JSONPServlet.java:218)
org.apache.tuscany.sca.binding.jsonp.runtime.JSONPServlet.service(JSONPServlet.java:63)
org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:110)
org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.doFilter(TuscanyServletFilter.java:94)
It seems there are some more special cases for conversion than initially
planned... I tried adding quotes or parentheses for the integer argument but
it didn't solve the problem...
Florian
[0]
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/contrib/samples/jsonp-webapp/
On Tue, Aug 31, 2010 at 4:00 PM, ant elder <an...@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 11:49 AM, Florian MOGA <mo...@gmail.com> wrote:
> > Hi Simon,
> > Thanks for pointing where can I find more info. I've taken a look at
> > the DatabindingRuntimeWireProcessor and the only thing I'm trying to
> clarify
> > is how tuscany finds out that a String array is actually hiding behind
> the
> > Object[] argument when invoking the wire and decides to use JSON (even in
> > the case when other databindings are included). Considering that
> databinding
> > occurs between the service invocation from the binding and the actual
> > service, I believe source contract type, operation, data types are taken
> > from:
> >
> > wire.invoke(operation, args);
> >
> > I don't see how operation can be different and I'm not aware of a
> mechanism
> > for determining what types exactly hide under Object[].
> > I'm currently building a jsonp sample that will include the various ways
> of
> > calling jsonp services (json objects, jquery, etc.). It will be good for
> > testing and if you consider it good enough, for the samples/ directory
> too.
>
> The Operation object does include the data binding type information,
> see methods such as getInputType which return DataType objects.
> Binding impls set the type of data they expect, in the jsonp binding
> see that done at line 45 of JSONPServiceBindingProvider.
>
> (Not sure if that was the question you're asking, does that help?)
>
> ...ant
>
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@gmail.com>.
On Tue, Aug 31, 2010 at 11:49 AM, Florian MOGA <mo...@gmail.com> wrote:
> Hi Simon,
> Thanks for pointing where can I find more info. I've taken a look at
> the DatabindingRuntimeWireProcessor and the only thing I'm trying to clarify
> is how tuscany finds out that a String array is actually hiding behind the
> Object[] argument when invoking the wire and decides to use JSON (even in
> the case when other databindings are included). Considering that databinding
> occurs between the service invocation from the binding and the actual
> service, I believe source contract type, operation, data types are taken
> from:
>
> wire.invoke(operation, args);
>
> I don't see how operation can be different and I'm not aware of a mechanism
> for determining what types exactly hide under Object[].
> I'm currently building a jsonp sample that will include the various ways of
> calling jsonp services (json objects, jquery, etc.). It will be good for
> testing and if you consider it good enough, for the samples/ directory too.
The Operation object does include the data binding type information,
see methods such as getInputType which return DataType objects.
Binding impls set the type of data they expect, in the jsonp binding
see that done at line 45 of JSONPServiceBindingProvider.
(Not sure if that was the question you're asking, does that help?)
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Florian MOGA <mo...@gmail.com>.
Hi Simon,
Thanks for pointing where can I find more info. I've taken a look at
the DatabindingRuntimeWireProcessor
and the only thing I'm trying to clarify is how tuscany finds out that a
String array is actually hiding behind the Object[] argument when invoking
the wire and decides to use JSON (even in the case when other databindings
are included). Considering that databinding occurs between the service
invocation from the binding and the actual service, I believe source
contract type, operation, data types are taken from:
wire.invoke(operation, args);
I don't see how operation can be different and I'm not aware of a mechanism
for determining what types exactly hide under Object[].
I'm currently building a jsonp sample that will include the various ways of
calling jsonp services (json objects, jquery, etc.). It will be good for
testing and if you consider it good enough, for the samples/ directory too.
Florian
On Tue, Aug 31, 2010 at 12:25 PM, Simon Laws <si...@googlemail.com>wrote:
> Hi Florian
>
> On Tue, Aug 31, 2010 at 9:59 AM, Florian MOGA <mo...@gmail.com> wrote:
> > Hi Ant,
> > It seems I've missed Simon's commit and didn't update jsonp binding
> sources
> > at the time I was checking them out... That was the problem I wanted to
> > bring up. I've checked up the new getJSONRequestStringArray() method and
> > I've spotted that the typesIndex is never incrementing... Can't estimate
> > what's the impact of not having quotes for all string objects in JSON and
> if
> > this is handled the right way by the databinding layer, maybe Simon can
> give
> > us more details?
>
> It may just be an error. Let me take a look.
>
> > Looking at the code, I find the abstraction very useful and I would like
> to
> > use this databinding layer for the comet binding too so we can have
> > conversions done in one place. All that's required for parameters is to
> pass
> > the string array as a Object[] type and tuscany will take care of
> everything
> > else? How is it working actually? Are the objects passed through another
> > layer that takes care of conversions before making the service call?
>
> Yes, where the type of the interface contract at the binding and the
> implementation differ the Tuscany runtime (see
> DatabindingRuntimeWireProcessor in modules/core-databinding) adds a
> DataTrasnformationInterceptor to the wire. On the service side this
> interceptor converts the type of the data coming in from the binding
> into the data types expected by the implementation. If you look at the
> separate databindings you can see the individual transformers, for
> example, in databinding-json you can see a JSON2JavaBean transformer
> which, well, converts a JSON object into a JavaBean. The same thing
> can happen on references too but in the opposite direction of course.
>
> The configuration and processing of databindings is all a bit
> complicated as it's very flexible. It's also complicate as it deals
> with wrapping/unwrapping data types as appropriate depending on the
> style of WSDL that's used to describe an interface. The best way to
> understand it is to:
>
> - take a look at Raymond's presentation on the subject [1]
> - debug through a running example
>
> > I can also see that the tuscany-databinding-json artifact is used in
> > binding-jsonp-runtime only with test scope. Does this mean every project
> > using jsonp binding needs to declare tuscany-databinding-json as a
> > dependency as well or tuscany will fail json conversion? Wouldn't that
> try
> > to convert all the objects passed in the service calls made in the
> > composite?
>
> We should make this a runtime dependency
>
> ...snip
>
>
> [1]
> http://www.google.co.uk/url?sa=t&source=web&cd=5&ved=0CCgQFjAE&url=http%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Ftuscany%2Fsandbox%2Fold%2Fdoc%2Ftuscany.databinding.ppt&ei=Kcl8TJ2aEMyNjAeYte3TDg&usg=AFQjCNHXxhplX1P3r6OA8IoJXhWAsM39uA&sig2=1521aoFfCJ9FcWOMeydH_A
>
> I just found the above link via a Google search. I'm sure it's
> referenced from the web site but I can't find it. I'm hoping Raymond
> can point us at it.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Simon Laws <si...@googlemail.com>.
Hi Florian
On Tue, Aug 31, 2010 at 9:59 AM, Florian MOGA <mo...@gmail.com> wrote:
> Hi Ant,
> It seems I've missed Simon's commit and didn't update jsonp binding sources
> at the time I was checking them out... That was the problem I wanted to
> bring up. I've checked up the new getJSONRequestStringArray() method and
> I've spotted that the typesIndex is never incrementing... Can't estimate
> what's the impact of not having quotes for all string objects in JSON and if
> this is handled the right way by the databinding layer, maybe Simon can give
> us more details?
It may just be an error. Let me take a look.
> Looking at the code, I find the abstraction very useful and I would like to
> use this databinding layer for the comet binding too so we can have
> conversions done in one place. All that's required for parameters is to pass
> the string array as a Object[] type and tuscany will take care of everything
> else? How is it working actually? Are the objects passed through another
> layer that takes care of conversions before making the service call?
Yes, where the type of the interface contract at the binding and the
implementation differ the Tuscany runtime (see
DatabindingRuntimeWireProcessor in modules/core-databinding) adds a
DataTrasnformationInterceptor to the wire. On the service side this
interceptor converts the type of the data coming in from the binding
into the data types expected by the implementation. If you look at the
separate databindings you can see the individual transformers, for
example, in databinding-json you can see a JSON2JavaBean transformer
which, well, converts a JSON object into a JavaBean. The same thing
can happen on references too but in the opposite direction of course.
The configuration and processing of databindings is all a bit
complicated as it's very flexible. It's also complicate as it deals
with wrapping/unwrapping data types as appropriate depending on the
style of WSDL that's used to describe an interface. The best way to
understand it is to:
- take a look at Raymond's presentation on the subject [1]
- debug through a running example
> I can also see that the tuscany-databinding-json artifact is used in
> binding-jsonp-runtime only with test scope. Does this mean every project
> using jsonp binding needs to declare tuscany-databinding-json as a
> dependency as well or tuscany will fail json conversion? Wouldn't that try
> to convert all the objects passed in the service calls made in the
> composite?
We should make this a runtime dependency
...snip
[1] http://www.google.co.uk/url?sa=t&source=web&cd=5&ved=0CCgQFjAE&url=http%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Ftuscany%2Fsandbox%2Fold%2Fdoc%2Ftuscany.databinding.ppt&ei=Kcl8TJ2aEMyNjAeYte3TDg&usg=AFQjCNHXxhplX1P3r6OA8IoJXhWAsM39uA&sig2=1521aoFfCJ9FcWOMeydH_A
I just found the above link via a Google search. I'm sure it's
referenced from the web site but I can't find it. I'm hoping Raymond
can point us at it.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@gmail.com>.
On Tue, Aug 31, 2010 at 9:59 AM, Florian MOGA <mo...@gmail.com> wrote:
> Hi Ant,
> It seems I've missed Simon's commit and didn't update jsonp binding sources
> at the time I was checking them out... That was the problem I wanted to
> bring up. I've checked up the new getJSONRequestStringArray() method and
> I've spotted that the typesIndex is never incrementing... Can't estimate
> what's the impact of not having quotes for all string objects in JSON and if
> this is handled the right way by the databinding layer, maybe Simon can give
> us more details?
Thats a bug, i've fixed it now. What that code is doing is trying to
make it easier to enter string parameters in the url, eg so that
instead of:
http://localhost:8080/helloworld/sayHello?name="Florian"
also support doing
http://localhost:8080/helloworld/sayHello?name=Florian
Not sure how common that is but some things do seem to expect unquoted
strings to work.
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Florian MOGA <mo...@gmail.com>.
Hi Ant,
It seems I've missed Simon's commit and didn't update jsonp binding sources
at the time I was checking them out... That was the problem I wanted to
bring up. I've checked up the new getJSONRequestStringArray() method and
I've spotted that the typesIndex is never incrementing... Can't estimate
what's the impact of not having quotes for all string objects in JSON and if
this is handled the right way by the databinding layer, maybe Simon can give
us more details?
Looking at the code, I find the abstraction very useful and I would like to
use this databinding layer for the comet binding too so we can have
conversions done in one place. All that's required for parameters is to pass
the string array as a Object[] type and tuscany will take care of everything
else? How is it working actually? Are the objects passed through another
layer that takes care of conversions before making the service call?
I can also see that the tuscany-databinding-json artifact is used in
binding-jsonp-runtime only with test scope. Does this mean every project
using jsonp binding needs to declare tuscany-databinding-json as a
dependency as well or tuscany will fail json conversion? Wouldn't that try
to convert all the objects passed in the service calls made in the
composite?
On Tue, Aug 31, 2010 at 2:10 AM, Luciano Resende <lu...@gmail.com>wrote:
> On Mon, Aug 30, 2010 at 3:51 PM, ant elder <an...@apache.org> wrote:
> >
> > If you really want to have all this is in just a single binding then
> > why not call it binding.http? Merging this function into binding.rest
> > makes no sense at all. REST is not RPC.
> >
> > ...ant
> >
>
> I would like to have one binding, independent if we call it REST or
> HTTP... some approach to easily provide some transition to that path
> is also described in [1].
>
> [1] http://markmail.org/message/gooxl7dfaxahxr7h
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Aug 30, 2010 at 3:51 PM, ant elder <an...@apache.org> wrote:
>
> If you really want to have all this is in just a single binding then
> why not call it binding.http? Merging this function into binding.rest
> makes no sense at all. REST is not RPC.
>
> ...ant
>
I would like to have one binding, independent if we call it REST or
HTTP... some approach to easily provide some transition to that path
is also described in [1].
[1] http://markmail.org/message/gooxl7dfaxahxr7h
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@apache.org>.
On Mon, Aug 30, 2010 at 11:03 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Sat, Aug 28, 2010 at 1:50 AM, ant elder <an...@gmail.com> wrote:
>> On Sat, Aug 28, 2010 at 9:12 AM, Raymond Feng <en...@gmail.com> wrote:
>>> IMO, using HTTP/GET to access the RPC style services is just a poor-man's
>>> web service. Don't go deeper to support complex types, don't try to support
>>> POST, because that will reinvent the wheels that either WS-*, REST, or
>>> JSONRPC already handles.
>>
>> Support for http/get is certainly the one i'd like to see us
>> supporting first. The big reason why this is more useful than web
>> services or similar POX is it can use JSON so becomes more useful to
>> all the common browser tool kits. Its not jsonrpc as a lot of things
>> don't need or support that, and this also would work with jsonp so
>> would work cross domain.
>>
>>> If you don't like the JAX-RS annotations to provide the @name for the
>>> parameters, maybe we can just support arg0, arg1, ..., argN or being
>>> positional. Anyway, JAX-WS/JAXB seems to have the "arg" conventions.
>>
>> Ok that seems reasonable to also have in the default wireFormat. So
>> that wireFormat could do the parameter mapping as:
>>
>> First if the binding configuration contains a mapping from query
>> parameter name to operation parameter then use that. Otherwise if the
>> service interface or impl uses jaxrs annotations to name the
>> parameters then use that mapping, otherwise if the query parameters
>> are name arg0, arg1 etc than use those names for the mapping,
>> otherwise use the order in the query string.
>>
>> Sound ok?
>>
>> ...ant
>>
>
> Sounds good, BTW, as it seems that we are reaching consensus, and we
> are going to have things modularized as different
> operationSlectors/wireFormats, is there any reason why can't we
> collaborate on enhancing the RESt binding, instead of going into the
> direction where we have to maintain two very similar bindings (REST
> and HTTP ) ? Anyway, I'm going to look into merging this functionality
> in the REST binding in the next couple days.
>
If you really want to have all this is in just a single binding then
why not call it binding.http? Merging this function into binding.rest
makes no sense at all. REST is not RPC.
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Luciano Resende <lu...@gmail.com>.
On Sat, Aug 28, 2010 at 1:50 AM, ant elder <an...@gmail.com> wrote:
> On Sat, Aug 28, 2010 at 9:12 AM, Raymond Feng <en...@gmail.com> wrote:
>> IMO, using HTTP/GET to access the RPC style services is just a poor-man's
>> web service. Don't go deeper to support complex types, don't try to support
>> POST, because that will reinvent the wheels that either WS-*, REST, or
>> JSONRPC already handles.
>
> Support for http/get is certainly the one i'd like to see us
> supporting first. The big reason why this is more useful than web
> services or similar POX is it can use JSON so becomes more useful to
> all the common browser tool kits. Its not jsonrpc as a lot of things
> don't need or support that, and this also would work with jsonp so
> would work cross domain.
>
>> If you don't like the JAX-RS annotations to provide the @name for the
>> parameters, maybe we can just support arg0, arg1, ..., argN or being
>> positional. Anyway, JAX-WS/JAXB seems to have the "arg" conventions.
>
> Ok that seems reasonable to also have in the default wireFormat. So
> that wireFormat could do the parameter mapping as:
>
> First if the binding configuration contains a mapping from query
> parameter name to operation parameter then use that. Otherwise if the
> service interface or impl uses jaxrs annotations to name the
> parameters then use that mapping, otherwise if the query parameters
> are name arg0, arg1 etc than use those names for the mapping,
> otherwise use the order in the query string.
>
> Sound ok?
>
> ...ant
>
Sounds good, BTW, as it seems that we are reaching consensus, and we
are going to have things modularized as different
operationSlectors/wireFormats, is there any reason why can't we
collaborate on enhancing the RESt binding, instead of going into the
direction where we have to maintain two very similar bindings (REST
and HTTP ) ? Anyway, I'm going to look into merging this functionality
in the REST binding in the next couple days.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@apache.org>.
On Sat, Aug 28, 2010 at 10:37 AM, Florian MOGA <mo...@gmail.com> wrote:
> The thing is, the JSONP binding
> can't handle any other types other than String... not even primitives like
> int. This means services exposed through jsonp should all have String
> parameters... If i'm not wrong with the above statement, that might be a bit
> too restrictive... I was going to ask if this type of feature is needed or
> intended for jsonp. I could implement it.
Do you know if that is still the case after the changes Simon made a
little while ago? Now it uses the databinding frameworks and it looks
like the method getJSONRequestStringArray in JSONPServlet should mean
it works with non-string types. Or are there bugs and that doesn't
work?
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Florian MOGA <mo...@gmail.com>.
I was going to open up a separate topic for this but I think at this point
of discussion, this might be a good place to bring it up. For the comet
binding i used the jsonp binding as an example. I was passing parameters for
the service as a JSON array and had the surprise that converting JSON arrays
to Object[] doesn't work that well because when performing the target
invocation types don't match - due to impossible downcast probably. My
solution was to parse the JSON array and for each parameter I converted it
to the specific type it was. Something like this:
for (final DataType<?> dataType :
operation.getInputType().getLogical()) {
args[index] = this.gson.fromJson(json[index],
dataType.getPhysical());
index++;
}
So, supporting complex types wouldn't be that complicated and it's as easy
to do with Jackson as well (i used Gson). The thing is, the JSONP binding
can't handle any other types other than String... not even primitives like
int. This means services exposed through jsonp should all have String
parameters... If i'm not wrong with the above statement, that might be a bit
too restrictive... I was going to ask if this type of feature is needed or
intended for jsonp. I could implement it.
>From the comet binding perspective, I found having this kind of support is
very comfortable in javascript as it is using javascript extensively. I
believe the jsonp binding is also built having in mind it's usage with a
jquery function like $.getJSON so returning JSON objects can't hurt. I don't
know how the rest binding is destined to be used (more from Java or
Javascript) but if we're hitting the same JSON conversion problem it might
be a good thing to have a global helper for this operations in the tuscany
core and all json-related bindings can use it.
About the parameter order, I've avoided this as I generated the javascript
proxies so parameters were given in the right order but in this case it
feels right being able to get the parameter names at runtime. How complex
and risky (in affecting other things) would be this kind of change? Would it
be doable?
Florian
On Sat, Aug 28, 2010 at 11:50 AM, ant elder <an...@gmail.com> wrote:
> On Sat, Aug 28, 2010 at 9:12 AM, Raymond Feng <en...@gmail.com> wrote:
> > IMO, using HTTP/GET to access the RPC style services is just a poor-man's
> > web service. Don't go deeper to support complex types, don't try to
> support
> > POST, because that will reinvent the wheels that either WS-*, REST, or
> > JSONRPC already handles.
>
> Support for http/get is certainly the one i'd like to see us
> supporting first. The big reason why this is more useful than web
> services or similar POX is it can use JSON so becomes more useful to
> all the common browser tool kits. Its not jsonrpc as a lot of things
> don't need or support that, and this also would work with jsonp so
> would work cross domain.
>
> > If you don't like the JAX-RS annotations to provide the @name for the
> > parameters, maybe we can just support arg0, arg1, ..., argN or being
> > positional. Anyway, JAX-WS/JAXB seems to have the "arg" conventions.
>
> Ok that seems reasonable to also have in the default wireFormat. So
> that wireFormat could do the parameter mapping as:
>
> First if the binding configuration contains a mapping from query
> parameter name to operation parameter then use that. Otherwise if the
> service interface or impl uses jaxrs annotations to name the
> parameters then use that mapping, otherwise if the query parameters
> are name arg0, arg1 etc than use those names for the mapping,
> otherwise use the order in the query string.
>
> Sound ok?
>
> ...ant
>
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@gmail.com>.
On Sat, Aug 28, 2010 at 9:12 AM, Raymond Feng <en...@gmail.com> wrote:
> IMO, using HTTP/GET to access the RPC style services is just a poor-man's
> web service. Don't go deeper to support complex types, don't try to support
> POST, because that will reinvent the wheels that either WS-*, REST, or
> JSONRPC already handles.
Support for http/get is certainly the one i'd like to see us
supporting first. The big reason why this is more useful than web
services or similar POX is it can use JSON so becomes more useful to
all the common browser tool kits. Its not jsonrpc as a lot of things
don't need or support that, and this also would work with jsonp so
would work cross domain.
> If you don't like the JAX-RS annotations to provide the @name for the
> parameters, maybe we can just support arg0, arg1, ..., argN or being
> positional. Anyway, JAX-WS/JAXB seems to have the "arg" conventions.
Ok that seems reasonable to also have in the default wireFormat. So
that wireFormat could do the parameter mapping as:
First if the binding configuration contains a mapping from query
parameter name to operation parameter then use that. Otherwise if the
service interface or impl uses jaxrs annotations to name the
parameters then use that mapping, otherwise if the query parameters
are name arg0, arg1 etc than use those names for the mapping,
otherwise use the order in the query string.
Sound ok?
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Raymond Feng <en...@gmail.com>.
IMO, using HTTP/GET to access the RPC style services is just a poor-man's web service. Don't go deeper to support complex types, don't try to support POST, because that will reinvent the wheels that either WS-*, REST, or JSONRPC already handles.
If you don't like the JAX-RS annotations to provide the @name for the parameters, maybe we can just support arg0, arg1, ..., argN or being positional. Anyway, JAX-WS/JAXB seems to have the "arg" conventions.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________
On Aug 28, 2010, at 12:48 AM, ant elder wrote:
> On Sat, Aug 28, 2010 at 12:15 AM, Luciano Resende <lu...@gmail.com> wrote:
>> On Fri, Aug 27, 2010 at 3:45 PM, ant elder <an...@apache.org> wrote:
>>> On Fri, Aug 27, 2010 at 11:08 PM, Luciano Resende <lu...@gmail.com> wrote:
>>>> On Fri, Aug 27, 2010 at 2:34 PM, ant elder <an...@apache.org> wrote:
>>>>> On Fri, Aug 27, 2010 at 6:40 PM, Luciano Resende <lu...@gmail.com> wrote:
>>>>>
>>>>>> But, stepping back,
>>>>>
>>>>> Ok lets do that, so we've got the composite at
>>>>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/hema/src/main/webapp/WEB-INF/web.composite
>>>>> with component service HelloworldComponent/HelloworldService and the
>>>>> service interface is:
>>>>>
>>>>> @Remotable
>>>>> public interface HelloworldService {
>>>>> String sayHello(String name);
>>>>> }
>>>>>
>>>>> That works for bindings like sca, ws, rmi, etc, and now we want to
>>>>> expose it as an http endpoint. We shouldn't need to add any
>>>>> annotations or modify the service interface or impl. We need to encode
>>>>> the operation name, the parameters, and perhaps the format to get the
>>>>> response back in (eg xml or json perhaps). The operation name could be
>>>>> part of the url, in this example theres a single string parameter so
>>>>> using the url query parameters seems useful but if the parameters were
>>>>> more complex you might want to use xml or json with an http post
>>>>> request.
>>>>>
>>>>
>>>> +1, if you have a good solution for mapping HTTP Verbs to Service
>>>> operations without any type of configuration, or convetion as in the
>>>> Collection itnerface, please feel free to share.
>>>>
>>>
>>> This wouldn't have any mapping from http verbs to service operations,
>>> its not trying to be restful just expose an sca service as an http
>>> endpoint. All the service operations just use get and/or post.
>>>
>>
>> Are you assuming this scenario in particular ? Or limiting services to
>> have only one operation ? In real life examples, we usually want to
>> expose existent services, which has multiple operations, in a restful
>> way. In this case, how would you say that, when you are doing a HTTP
>> GET, on a giving resource (or resource pattern), you want it to map to
>> a given operation ? If you look in the JAX-RS specifications, you
>> would see several examples of these patterns, and I'm just using
>> JAX-RS as an example as the spec samples would be applicable outside
>> of the scope of JAX-RS.
>>
>
> This approach works fine with multiple service opperations:
>
> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello
> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayGoodbye
> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/doSomethingElse
>
> Whats the problem?
>
> This is not REST, its not doing a get on a resource its just exposing
> a service operation as an http endpoint.
>
>>
>>>>> So that would be things like an http get
>>>>> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello?name=petra,
>>>>
>>>> The problem with this is that there isn't a good way to find the
>>>> parameter name at runtime, and that's why JAX-RS created such
>>>> annotations to do the map (e.g QueryParam, etc)
>>>>
>>>
>>> The http get format is really only useful for trivial request
>>> parameters so it can be simple - just use the order the parameters
>>> appear in the query string, so for java method parameter mapping the
>>> query parameter name could be ignored.
>>>
>>
>> If you look into various APIs that use this pattern to leverage the
>> power of HTTP GET Cache (e.g multiple google apis, flickr, etc), you
>> will note that usage of GET can become complex, and I really don't
>> like the idea of failing the user request because a user didn't send
>> name as the second parameter... also, how would you handle arrays,
>> which you don't know how many entries will be sent to the invocation ?
>>
>
> Arrays would work fine and there are a lot of those API calls that
> would work fine too. For the more complex or esoteric ones we can add
> more config to the binding as you're already suggesting with extra
> wireFormat/operationSelectors that could map query parameters to
> operationParameters.
>
>>>>> or an http post
>>>>> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello
>>>>> with a json or xml request body. And perhaps an accept header could
>>>>> define the default for what type or response is returned eg xml or
>>>>> json (or javascript too and then we wouldn't need the jsonp binding).
>>>>>
>>>>
>>>> You mean, content-type on the post identifying that you are providing
>>>> json or xml. Agree, but I think we should support both scenarios, a
>>>> dynamic one and a "hard coded" one where the service will only output
>>>> what is specified on the wireFormat. We probably need some
>>>> enhancements on our databinding framework to better support mime
>>>> types, and our rest binding does provide most of this trough the wink
>>>> integration.
>>>>
>>>
>>> Sure ok but we could start with the one wireFormat and
>>> operationSelector that do all whats described above, and then later
>>> add others to restrict the format to xml or json etc. So if this was
>>> added to the existing rest binding then if these were called foo it
>>> would be:
>>>
>>> <binding.rest>
>>> <wireFormat.foo/>
>>> <operationSelector.foo/>
>>> </binding.rest>
>>>
>>> or if it was the http binding perhaps
>>>
>>> <binding.http>
>>> <wireFormat.httpDefault/>
>>> <operationSelector.httpDefault/>
>>> </binding.foo>
>>>
>>
>> Please take a look for some of the previous discussions on this subject
>>
>> http://www.mail-archive.com/dev@tuscany.apache.org/msg11988.html
>>
>
> I have, this is the same as i was suggesting back in those previous discussions.
>
>>> and as those are default wireFormat and operationSelector that would
>>> be the same as just <binding.http/>
>>>
>>>>> Does that all sound reasonable so far, if so we can then map that in
>>>>> to what sca binding, wireformat and operationSelector elements could
>>>>> look like.
>>>>>
>>>>
>>>> Are you mostly concerned with extra extensions to these elements to
>>>> provide additional configuration in a declarative fashion without
>>>> requiring the pollution of the business interface with jax-rs
>>>> annotations ?
>>>>
>>>
>>> Certainly requiring the use of jaxrs annotations for it to work
>>> doesn't seem right to me.
>>>
>>
>> Well, it's not that it's required...
>
> Well it looks like it _is_ required presently, the current
> binding.rest doesn't work with this simple helloworld service!
>
>> users have the option to use
>> convention over configuration such as using the Collection interface,
>> but I heard lots of complaints about it before, particularly when
>> users were trying to reuse existing components. I believe JAX-RS
>> annotations is better then Collection interface in this case (and they
>> are a standard), but declarative mapping would be the ideal.
>>
>
> Sure there are scenarios where we'll want more control and JAX-RS
> gives us that, and we do already support that with
> <implementation.jaxrx> and this <binding.rest>. In this example though
> we're not looking to create restful endpoints, arbitrary sca services
> usually are not restful so we just want a way to expose the service
> operations over http.
>
> ...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@apache.org>.
On Sat, Aug 28, 2010 at 12:15 AM, Luciano Resende <lu...@gmail.com> wrote:
> On Fri, Aug 27, 2010 at 3:45 PM, ant elder <an...@apache.org> wrote:
>> On Fri, Aug 27, 2010 at 11:08 PM, Luciano Resende <lu...@gmail.com> wrote:
>>> On Fri, Aug 27, 2010 at 2:34 PM, ant elder <an...@apache.org> wrote:
>>>> On Fri, Aug 27, 2010 at 6:40 PM, Luciano Resende <lu...@gmail.com> wrote:
>>>>
>>>>> But, stepping back,
>>>>
>>>> Ok lets do that, so we've got the composite at
>>>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/hema/src/main/webapp/WEB-INF/web.composite
>>>> with component service HelloworldComponent/HelloworldService and the
>>>> service interface is:
>>>>
>>>> @Remotable
>>>> public interface HelloworldService {
>>>> String sayHello(String name);
>>>> }
>>>>
>>>> That works for bindings like sca, ws, rmi, etc, and now we want to
>>>> expose it as an http endpoint. We shouldn't need to add any
>>>> annotations or modify the service interface or impl. We need to encode
>>>> the operation name, the parameters, and perhaps the format to get the
>>>> response back in (eg xml or json perhaps). The operation name could be
>>>> part of the url, in this example theres a single string parameter so
>>>> using the url query parameters seems useful but if the parameters were
>>>> more complex you might want to use xml or json with an http post
>>>> request.
>>>>
>>>
>>> +1, if you have a good solution for mapping HTTP Verbs to Service
>>> operations without any type of configuration, or convetion as in the
>>> Collection itnerface, please feel free to share.
>>>
>>
>> This wouldn't have any mapping from http verbs to service operations,
>> its not trying to be restful just expose an sca service as an http
>> endpoint. All the service operations just use get and/or post.
>>
>
> Are you assuming this scenario in particular ? Or limiting services to
> have only one operation ? In real life examples, we usually want to
> expose existent services, which has multiple operations, in a restful
> way. In this case, how would you say that, when you are doing a HTTP
> GET, on a giving resource (or resource pattern), you want it to map to
> a given operation ? If you look in the JAX-RS specifications, you
> would see several examples of these patterns, and I'm just using
> JAX-RS as an example as the spec samples would be applicable outside
> of the scope of JAX-RS.
>
This approach works fine with multiple service opperations:
http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello
http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayGoodbye
http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/doSomethingElse
Whats the problem?
This is not REST, its not doing a get on a resource its just exposing
a service operation as an http endpoint.
>
>>>> So that would be things like an http get
>>>> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello?name=petra,
>>>
>>> The problem with this is that there isn't a good way to find the
>>> parameter name at runtime, and that's why JAX-RS created such
>>> annotations to do the map (e.g QueryParam, etc)
>>>
>>
>> The http get format is really only useful for trivial request
>> parameters so it can be simple - just use the order the parameters
>> appear in the query string, so for java method parameter mapping the
>> query parameter name could be ignored.
>>
>
> If you look into various APIs that use this pattern to leverage the
> power of HTTP GET Cache (e.g multiple google apis, flickr, etc), you
> will note that usage of GET can become complex, and I really don't
> like the idea of failing the user request because a user didn't send
> name as the second parameter... also, how would you handle arrays,
> which you don't know how many entries will be sent to the invocation ?
>
Arrays would work fine and there are a lot of those API calls that
would work fine too. For the more complex or esoteric ones we can add
more config to the binding as you're already suggesting with extra
wireFormat/operationSelectors that could map query parameters to
operationParameters.
>>>> or an http post
>>>> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello
>>>> with a json or xml request body. And perhaps an accept header could
>>>> define the default for what type or response is returned eg xml or
>>>> json (or javascript too and then we wouldn't need the jsonp binding).
>>>>
>>>
>>> You mean, content-type on the post identifying that you are providing
>>> json or xml. Agree, but I think we should support both scenarios, a
>>> dynamic one and a "hard coded" one where the service will only output
>>> what is specified on the wireFormat. We probably need some
>>> enhancements on our databinding framework to better support mime
>>> types, and our rest binding does provide most of this trough the wink
>>> integration.
>>>
>>
>> Sure ok but we could start with the one wireFormat and
>> operationSelector that do all whats described above, and then later
>> add others to restrict the format to xml or json etc. So if this was
>> added to the existing rest binding then if these were called foo it
>> would be:
>>
>> <binding.rest>
>> <wireFormat.foo/>
>> <operationSelector.foo/>
>> </binding.rest>
>>
>> or if it was the http binding perhaps
>>
>> <binding.http>
>> <wireFormat.httpDefault/>
>> <operationSelector.httpDefault/>
>> </binding.foo>
>>
>
> Please take a look for some of the previous discussions on this subject
>
> http://www.mail-archive.com/dev@tuscany.apache.org/msg11988.html
>
I have, this is the same as i was suggesting back in those previous discussions.
>> and as those are default wireFormat and operationSelector that would
>> be the same as just <binding.http/>
>>
>>>> Does that all sound reasonable so far, if so we can then map that in
>>>> to what sca binding, wireformat and operationSelector elements could
>>>> look like.
>>>>
>>>
>>> Are you mostly concerned with extra extensions to these elements to
>>> provide additional configuration in a declarative fashion without
>>> requiring the pollution of the business interface with jax-rs
>>> annotations ?
>>>
>>
>> Certainly requiring the use of jaxrs annotations for it to work
>> doesn't seem right to me.
>>
>
> Well, it's not that it's required...
Well it looks like it _is_ required presently, the current
binding.rest doesn't work with this simple helloworld service!
> users have the option to use
> convention over configuration such as using the Collection interface,
> but I heard lots of complaints about it before, particularly when
> users were trying to reuse existing components. I believe JAX-RS
> annotations is better then Collection interface in this case (and they
> are a standard), but declarative mapping would be the ideal.
>
Sure there are scenarios where we'll want more control and JAX-RS
gives us that, and we do already support that with
<implementation.jaxrx> and this <binding.rest>. In this example though
we're not looking to create restful endpoints, arbitrary sca services
usually are not restful so we just want a way to expose the service
operations over http.
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Aug 27, 2010 at 3:45 PM, ant elder <an...@apache.org> wrote:
> On Fri, Aug 27, 2010 at 11:08 PM, Luciano Resende <lu...@gmail.com> wrote:
>> On Fri, Aug 27, 2010 at 2:34 PM, ant elder <an...@apache.org> wrote:
>>> On Fri, Aug 27, 2010 at 6:40 PM, Luciano Resende <lu...@gmail.com> wrote:
>>>
>>>> But, stepping back,
>>>
>>> Ok lets do that, so we've got the composite at
>>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/hema/src/main/webapp/WEB-INF/web.composite
>>> with component service HelloworldComponent/HelloworldService and the
>>> service interface is:
>>>
>>> @Remotable
>>> public interface HelloworldService {
>>> String sayHello(String name);
>>> }
>>>
>>> That works for bindings like sca, ws, rmi, etc, and now we want to
>>> expose it as an http endpoint. We shouldn't need to add any
>>> annotations or modify the service interface or impl. We need to encode
>>> the operation name, the parameters, and perhaps the format to get the
>>> response back in (eg xml or json perhaps). The operation name could be
>>> part of the url, in this example theres a single string parameter so
>>> using the url query parameters seems useful but if the parameters were
>>> more complex you might want to use xml or json with an http post
>>> request.
>>>
>>
>> +1, if you have a good solution for mapping HTTP Verbs to Service
>> operations without any type of configuration, or convetion as in the
>> Collection itnerface, please feel free to share.
>>
>
> This wouldn't have any mapping from http verbs to service operations,
> its not trying to be restful just expose an sca service as an http
> endpoint. All the service operations just use get and/or post.
>
Are you assuming this scenario in particular ? Or limiting services to
have only one operation ? In real life examples, we usually want to
expose existent services, which has multiple operations, in a restful
way. In this case, how would you say that, when you are doing a HTTP
GET, on a giving resource (or resource pattern), you want it to map to
a given operation ? If you look in the JAX-RS specifications, you
would see several examples of these patterns, and I'm just using
JAX-RS as an example as the spec samples would be applicable outside
of the scope of JAX-RS.
>>> So that would be things like an http get
>>> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello?name=petra,
>>
>> The problem with this is that there isn't a good way to find the
>> parameter name at runtime, and that's why JAX-RS created such
>> annotations to do the map (e.g QueryParam, etc)
>>
>
> The http get format is really only useful for trivial request
> parameters so it can be simple - just use the order the parameters
> appear in the query string, so for java method parameter mapping the
> query parameter name could be ignored.
>
If you look into various APIs that use this pattern to leverage the
power of HTTP GET Cache (e.g multiple google apis, flickr, etc), you
will note that usage of GET can become complex, and I really don't
like the idea of failing the user request because a user didn't send
name as the second parameter... also, how would you handle arrays,
which you don't know how many entries will be sent to the invocation ?
>>> or an http post
>>> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello
>>> with a json or xml request body. And perhaps an accept header could
>>> define the default for what type or response is returned eg xml or
>>> json (or javascript too and then we wouldn't need the jsonp binding).
>>>
>>
>> You mean, content-type on the post identifying that you are providing
>> json or xml. Agree, but I think we should support both scenarios, a
>> dynamic one and a "hard coded" one where the service will only output
>> what is specified on the wireFormat. We probably need some
>> enhancements on our databinding framework to better support mime
>> types, and our rest binding does provide most of this trough the wink
>> integration.
>>
>
> Sure ok but we could start with the one wireFormat and
> operationSelector that do all whats described above, and then later
> add others to restrict the format to xml or json etc. So if this was
> added to the existing rest binding then if these were called foo it
> would be:
>
> <binding.rest>
> <wireFormat.foo/>
> <operationSelector.foo/>
> </binding.rest>
>
> or if it was the http binding perhaps
>
> <binding.http>
> <wireFormat.httpDefault/>
> <operationSelector.httpDefault/>
> </binding.foo>
>
Please take a look for some of the previous discussions on this subject
http://www.mail-archive.com/dev@tuscany.apache.org/msg11988.html
> and as those are default wireFormat and operationSelector that would
> be the same as just <binding.http/>
>
>>> Does that all sound reasonable so far, if so we can then map that in
>>> to what sca binding, wireformat and operationSelector elements could
>>> look like.
>>>
>>
>> Are you mostly concerned with extra extensions to these elements to
>> provide additional configuration in a declarative fashion without
>> requiring the pollution of the business interface with jax-rs
>> annotations ?
>>
>
> Certainly requiring the use of jaxrs annotations for it to work
> doesn't seem right to me.
>
Well, it's not that it's required... users have the option to use
convention over configuration such as using the Collection interface,
but I heard lots of complaints about it before, particularly when
users were trying to reuse existing components. I believe JAX-RS
annotations is better then Collection interface in this case (and they
are a standard), but declarative mapping would be the ideal.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@apache.org>.
On Fri, Aug 27, 2010 at 11:08 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Fri, Aug 27, 2010 at 2:34 PM, ant elder <an...@apache.org> wrote:
>> On Fri, Aug 27, 2010 at 6:40 PM, Luciano Resende <lu...@gmail.com> wrote:
>>
>>> But, stepping back,
>>
>> Ok lets do that, so we've got the composite at
>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/hema/src/main/webapp/WEB-INF/web.composite
>> with component service HelloworldComponent/HelloworldService and the
>> service interface is:
>>
>> @Remotable
>> public interface HelloworldService {
>> String sayHello(String name);
>> }
>>
>> That works for bindings like sca, ws, rmi, etc, and now we want to
>> expose it as an http endpoint. We shouldn't need to add any
>> annotations or modify the service interface or impl. We need to encode
>> the operation name, the parameters, and perhaps the format to get the
>> response back in (eg xml or json perhaps). The operation name could be
>> part of the url, in this example theres a single string parameter so
>> using the url query parameters seems useful but if the parameters were
>> more complex you might want to use xml or json with an http post
>> request.
>>
>
> +1, if you have a good solution for mapping HTTP Verbs to Service
> operations without any type of configuration, or convetion as in the
> Collection itnerface, please feel free to share.
>
This wouldn't have any mapping from http verbs to service operations,
its not trying to be restful just expose an sca service as an http
endpoint. All the service operations just use get and/or post.
>> So that would be things like an http get
>> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello?name=petra,
>
> The problem with this is that there isn't a good way to find the
> parameter name at runtime, and that's why JAX-RS created such
> annotations to do the map (e.g QueryParam, etc)
>
The http get format is really only useful for trivial request
parameters so it can be simple - just use the order the parameters
appear in the query string, so for java method parameter mapping the
query parameter name could be ignored.
>> or an http post
>> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello
>> with a json or xml request body. And perhaps an accept header could
>> define the default for what type or response is returned eg xml or
>> json (or javascript too and then we wouldn't need the jsonp binding).
>>
>
> You mean, content-type on the post identifying that you are providing
> json or xml. Agree, but I think we should support both scenarios, a
> dynamic one and a "hard coded" one where the service will only output
> what is specified on the wireFormat. We probably need some
> enhancements on our databinding framework to better support mime
> types, and our rest binding does provide most of this trough the wink
> integration.
>
Sure ok but we could start with the one wireFormat and
operationSelector that do all whats described above, and then later
add others to restrict the format to xml or json etc. So if this was
added to the existing rest binding then if these were called foo it
would be:
<binding.rest>
<wireFormat.foo/>
<operationSelector.foo/>
</binding.rest>
or if it was the http binding perhaps
<binding.http>
<wireFormat.httpDefault/>
<operationSelector.httpDefault/>
</binding.foo>
and as those are default wireFormat and operationSelector that would
be the same as just <binding.http/>
>> Does that all sound reasonable so far, if so we can then map that in
>> to what sca binding, wireformat and operationSelector elements could
>> look like.
>>
>
> Are you mostly concerned with extra extensions to these elements to
> provide additional configuration in a declarative fashion without
> requiring the pollution of the business interface with jax-rs
> annotations ?
>
Certainly requiring the use of jaxrs annotations for it to work
doesn't seem right to me.
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Aug 27, 2010 at 2:34 PM, ant elder <an...@apache.org> wrote:
> On Fri, Aug 27, 2010 at 6:40 PM, Luciano Resende <lu...@gmail.com> wrote:
>
>> But, stepping back,
>
> Ok lets do that, so we've got the composite at
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/hema/src/main/webapp/WEB-INF/web.composite
> with component service HelloworldComponent/HelloworldService and the
> service interface is:
>
> @Remotable
> public interface HelloworldService {
> String sayHello(String name);
> }
>
> That works for bindings like sca, ws, rmi, etc, and now we want to
> expose it as an http endpoint. We shouldn't need to add any
> annotations or modify the service interface or impl. We need to encode
> the operation name, the parameters, and perhaps the format to get the
> response back in (eg xml or json perhaps). The operation name could be
> part of the url, in this example theres a single string parameter so
> using the url query parameters seems useful but if the parameters were
> more complex you might want to use xml or json with an http post
> request.
>
+1, if you have a good solution for mapping HTTP Verbs to Service
operations without any type of configuration, or convetion as in the
Collection itnerface, please feel free to share.
> So that would be things like an http get
> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello?name=petra,
The problem with this is that there isn't a good way to find the
parameter name at runtime, and that's why JAX-RS created such
annotations to do the map (e.g QueryParam, etc)
> or an http post
> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello
> with a json or xml request body. And perhaps an accept header could
> define the default for what type or response is returned eg xml or
> json (or javascript too and then we wouldn't need the jsonp binding).
>
You mean, content-type on the post identifying that you are providing
json or xml. Agree, but I think we should support both scenarios, a
dynamic one and a "hard coded" one where the service will only output
what is specified on the wireFormat. We probably need some
enhancements on our databinding framework to better support mime
types, and our rest binding does provide most of this trough the wink
integration.
> Does that all sound reasonable so far, if so we can then map that in
> to what sca binding, wireformat and operationSelector elements could
> look like.
>
Are you mostly concerned with extra extensions to these elements to
provide additional configuration in a declarative fashion without
requiring the pollution of the business interface with jax-rs
annotations ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@apache.org>.
On Fri, Aug 27, 2010 at 6:40 PM, Luciano Resende <lu...@gmail.com> wrote:
> But, stepping back,
Ok lets do that, so we've got the composite at
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/hema/src/main/webapp/WEB-INF/web.composite
with component service HelloworldComponent/HelloworldService and the
service interface is:
@Remotable
public interface HelloworldService {
String sayHello(String name);
}
That works for bindings like sca, ws, rmi, etc, and now we want to
expose it as an http endpoint. We shouldn't need to add any
annotations or modify the service interface or impl. We need to encode
the operation name, the parameters, and perhaps the format to get the
response back in (eg xml or json perhaps). The operation name could be
part of the url, in this example theres a single string parameter so
using the url query parameters seems useful but if the parameters were
more complex you might want to use xml or json with an http post
request.
So that would be things like an http get
http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello?name=petra,
or an http post
http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello
with a json or xml request body. And perhaps an accept header could
define the default for what type or response is returned eg xml or
json (or javascript too and then we wouldn't need the jsonp binding).
Does that all sound reasonable so far, if so we can then map that in
to what sca binding, wireformat and operationSelector elements could
look like.
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Aug 27, 2010 at 10:37 AM, ant elder <an...@apache.org> wrote:
> On Fri, Aug 27, 2010 at 6:13 PM, Luciano Resende <lu...@gmail.com> wrote:
>
>>
>> I'd try:
>>
>> <tuscany:binding.rest name="rest">
>> <tuscany:operationSelector.rpc />
>> <tuscany:response>
>> <tuscany:wireFormat.json />
>> </tuscany:response>
>> </tuscany:binding.rest>
>>
>> This would then be accessible via URL
>>
>> <base service URI> ?method=<operation name>&parm1=<value>&parm2=<value>
>>
>
> I've tried that and still get the IllegalArgumentException: wrong
> number of arguments. Looking in the code thats caused by the loop at
> line 113 of RPCOperationSelectorInterceptor which is only adding
> things to the message if the operation parameters have the jaxrs
> QueryParam annotation, which this service doesn't use. Whats the
> intention, should the binding work with arbitrary services or only for
> for jaxrs classes?
>
> ...ant
>
Another option is to add support for declaratively add the mapping,
which is in my todo list, but not yet implemented. But, stepping back,
why not use the JAX-RS annotations ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by ant elder <an...@apache.org>.
On Fri, Aug 27, 2010 at 6:13 PM, Luciano Resende <lu...@gmail.com> wrote:
>
> I'd try:
>
> <tuscany:binding.rest name="rest">
> <tuscany:operationSelector.rpc />
> <tuscany:response>
> <tuscany:wireFormat.json />
> </tuscany:response>
> </tuscany:binding.rest>
>
> This would then be accessible via URL
>
> <base service URI> ?method=<operation name>&parm1=<value>&parm2=<value>
>
I've tried that and still get the IllegalArgumentException: wrong
number of arguments. Looking in the code thats caused by the loop at
line 113 of RPCOperationSelectorInterceptor which is only adding
things to the message if the operation parameters have the jaxrs
QueryParam annotation, which this service doesn't use. Whats the
intention, should the binding work with arbitrary services or only for
for jaxrs classes?
...ant
Re: tutorial - using binding.rest with non-jaxrs service?
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Aug 27, 2010 at 12:05 AM, ant elder <an...@gmail.com> wrote:
> Is binding.rest supposed to work with arbitrary services that don't
> have any jaxrs annotations? And if so how do you configure it to do
> that?
>
The REST Binding is a superset of the HTTP Binding, so other then the
regular support for Collection interface that would do the HTTP
Operation mapping to Collection operations and Servlet interface
support, you can also use JAX-RS Annotations for the mapping or use
RPC style invocation over HTTP Get. Note that full support for
references, particular in some configurations (e.g rpc over get) , is
not yet available. A JavaScript proxy client is being integrated to
Implementation Widget,
> I'm trying it with the sample at:
>
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/hema/
>
> The service interface is:
>
> @Remotable
> public interface HelloworldService {
> String sayHello(String name);
> }
>
> And i've tried varrious binding configs such as:
>
> <tuscany:binding.rest name="rest">
> <tuscany:wireFormat.json />
> <tuscany:operationSelector.rpc />
> </tuscany:binding.rest>
>
> but only get errors such as IllegalArgumentException: wrong number of arguments
>
I'd try:
<tuscany:binding.rest name="rest">
<tuscany:operationSelector.rpc />
<tuscany:response>
<tuscany:wireFormat.json />
</tuscany:response>
</tuscany:binding.rest>
This would then be accessible via URL
<base service URI> ?method=<operation name>&parm1=<value>&parm2=<value>
More details at
http://tuscany.apache.org/documentation-2x/sca-java-bindingrest.html
> Any comments?
>
> ...ant
>
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/