Re: Async methods for JAX-RS WebClient
On 24/09/12 19:07, Daniel Kulp wrote:
On Sep 24, 2012, at 8:31 AM, Sergey Beryozkin wrote:
I went ahead and populated AsyncInvoker, as well as added another shortcut
directly to WebClient, to support an async post call.
Dan, have a look please,
That all looks great. Thanks for filling in all the other methods. :-)
Cool, thanks for making it easy to do that...
Sergey
Dan
One thing that I can have a look later is making sure the retry calls work in
case of async call failures, plus add few more minor enhancements, overall
though it seems it looks OK
Thanks, Sergey
On 23/09/12 18:56, Sergey Beryozkin wrote:
On 23/09/12 18:14, Sergey Beryozkin wrote:
Hi Dan
On 21/09/12 19:27, Daniel Kulp wrote:
Sergey, (and others)
I just committed some initial support for some async methods to the
WebClient. Can you take a look at that change and make sure it all
makes sense? I only have a "get" method in there right now, but it
should be fairly trivial now to add the others that would map to the
new doInvokeAsync method. Just want to make sure it looks ok first.
It is a very good start, thanks for starting to look into it. I think I
will push some of the code to AbstractClient once I get a better
understanding of what is going on, for proxies to get the async support
too.
Other than that, I wonder if we should introduce an "async()" method
which would return
http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/client/AsyncInvoker.html
that would let us support the async style of invocation completely in
line with the way JAX-RS 2.0 does it, example:
WebClient wc = WebClient.create("address");
wc.async().get(callback); // etc
(async() in JAX-RS 2.0 is in
http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/clisystests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRS20ClientServerBookTest.javaent/Invocation.Builder.html)
I added an empty AsyncInvoker implementation, with
async().get(InvocationCallback) also working for now :-).
Wow, it's really happening thanks to the addition of the HTTP async
transport :-)
Thanks, Sergey
In addition to that we can indeed add simple shortcuts, one per every
main method, or for those which are more likely to participate in async
flows, say for get/post/put, to let users 'save' on typing 'async()' for
few mainstream cases
I'm a little concerned about the "state" objects in the WebClient. I
assume WebClients aren't supposed to be thread safe (that's OK).
However, can a WebClient be used to make multiple calls? What would
you expect in the case where a WebClient makes multiple async calls?
By default WebClient is not thread safe, but the thread-safety can be
activated by a threadSafe flag, it can be set on the client factory
bean, or passed to a WebClient factory method. Have a look please at
JAXRSMultithreadedClientTest. A thread-local map is then used to keep a
per-invocation state.
WebClient keeps the state because it emulates the 'browsing' process, so
at any moment it (a single instance) can move back or forward - but that
requires an extra support for the thread safety. 2.0 client interface is
different, no 'browsing' style is there, so it may be much simpler to
deal with the thread safety, I'll fond out soon once I start
implementing it :-)
Cheers, Sergey
RE: Facing error on Weblogic 11g with Apache CXF |u sing POST IN REST |Need help
Support for wauth and whr is supported as a callbackhandler in the fediz plugin for the relying party (application). Also metadata support is provided in the plugin. It's not yet supported for the fediz idp. -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Cabrera Juan Manuel [juan-manuel.cabr...@atos.net] Sent: 04 September 2012 16:47 To: dev@cxf.apache.org Subject: RE: Facing error on Weblogic 11g with Apache CXF |u sing POST IN REST |Need help Hello everyone. I just dug out an old email about the Fediz roadmap (March, 29th 2012): http://mail-archives.apache.org/mod_mbox/cxf-dev/201203.mbox/%3c79ab4452999c844d9920e03635332731120...@s10be002.sh10.lan%3E#archives >> Roadmap >> - >> >> 1st release (end of april): >> - Move configuration code to fediz-core >> - Publish WS-Federation Metadata document >> - Move SignIn request creation to fediz-core >> - support callback handlers for federation parameters: wauth, whr, >> >> 2nd release (end of june): >> - Create CXF plugin for JAX-RS >> - Create Websphere plugin based on TAI >> - Support encrypted token >> - Support the role of relying party IDP in mock >> - Support SAML HoK: >> either use UseKey element in RST >> or collocate STS in IDP thus STS has access to underlying transport >> - add layer to support other protocols like SAML-P, OAuth >> >> 3rd release (end of september): >> - create JBoss plugin >> - create Jetty plugin Just to know if it is still correct (excepting the dates, obviously); I am very interested in the features about federation (wauth, whr, metadata, ...) Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité d'Atos ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
RE: Start 1.0.x_fixes branch for Fediz, trunk to 1.1.0?
I understand what you mean. The reason why I'd like to have to branches is to be able to provide a bug fix release even we are working on new features in parallel. Backporting fixes from trunk to 1.0.x-fixes branch should be fairly easy with git cherry-pick but I agree it's more effort. Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Glen Mazza [glen.ma...@gmail.com] Sent: 20 September 2012 16:34 To: dev@cxf.apache.org Subject: Re: Start 1.0.x_fixes branch for Fediz, trunk to 1.1.0? Hi Oli, I noticed you have a Fediz 1.1 in JIRA but not a Fediz 1.0.2 -- I created the latter thinking before I realized you already have Fediz 1.1 listed. Is your intention to remain with just one branch (but let it be 1.1 only, and no 1.0.2), or do you want both branches--1.0.2 and 1.1? (The former--or the latter--can be deleted if you don't want it) Thanks, Glen -- View this message in context: http://cxf.547215.n5.nabble.com/Start-1-0-x-fixes-branch-for-Fediz-trunk-to-1-1-0-tp5713753p5714320.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Async methods for JAX-RS WebClient
On Sep 24, 2012, at 8:31 AM, Sergey Beryozkin wrote:
> I went ahead and populated AsyncInvoker, as well as added another shortcut
> directly to WebClient, to support an async post call.
>
> Dan, have a look please,
That all looks great. Thanks for filling in all the other methods. :-)
Dan
>
> One thing that I can have a look later is making sure the retry calls work in
> case of async call failures, plus add few more minor enhancements, overall
> though it seems it looks OK
>
> Thanks, Sergey
>
>
>
> On 23/09/12 18:56, Sergey Beryozkin wrote:
>> On 23/09/12 18:14, Sergey Beryozkin wrote:
>>> Hi Dan
>>> On 21/09/12 19:27, Daniel Kulp wrote:
Sergey, (and others)
I just committed some initial support for some async methods to the
WebClient. Can you take a look at that change and make sure it all
makes sense? I only have a "get" method in there right now, but it
should be fairly trivial now to add the others that would map to the
new doInvokeAsync method. Just want to make sure it looks ok first.
>>> It is a very good start, thanks for starting to look into it. I think I
>>> will push some of the code to AbstractClient once I get a better
>>> understanding of what is going on, for proxies to get the async support
>>> too.
>>>
>>> Other than that, I wonder if we should introduce an "async()" method
>>> which would return
>>>
>>> http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/client/AsyncInvoker.html
>>>
>>>
>>>
>>> that would let us support the async style of invocation completely in
>>> line with the way JAX-RS 2.0 does it, example:
>>>
>>> WebClient wc = WebClient.create("address");
>>> wc.async().get(callback); // etc
>>>
>>> (async() in JAX-RS 2.0 is in
>>> http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/clisystests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRS20ClientServerBookTest.javaent/Invocation.Builder.html)
>>>
>>>
>>
>> I added an empty AsyncInvoker implementation, with
>> async().get(InvocationCallback) also working for now :-).
>>
>> Wow, it's really happening thanks to the addition of the HTTP async
>> transport :-)
>>
>> Thanks, Sergey
>>
>>>
>>> In addition to that we can indeed add simple shortcuts, one per every
>>> main method, or for those which are more likely to participate in async
>>> flows, say for get/post/put, to let users 'save' on typing 'async()' for
>>> few mainstream cases
>>>
I'm a little concerned about the "state" objects in the WebClient. I
assume WebClients aren't supposed to be thread safe (that's OK).
However, can a WebClient be used to make multiple calls? What would
you expect in the case where a WebClient makes multiple async calls?
>>> By default WebClient is not thread safe, but the thread-safety can be
>>> activated by a threadSafe flag, it can be set on the client factory
>>> bean, or passed to a WebClient factory method. Have a look please at
>>> JAXRSMultithreadedClientTest. A thread-local map is then used to keep a
>>> per-invocation state.
>>> WebClient keeps the state because it emulates the 'browsing' process, so
>>> at any moment it (a single instance) can move back or forward - but that
>>> requires an extra support for the thread safety. 2.0 client interface is
>>> different, no 'browsing' style is there, so it may be much simpler to
>>> deal with the thread safety, I'll fond out soon once I start
>>> implementing it :-)
>>>
>>> Cheers, Sergey
>>
>
>
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
2.7.0 coming soon….
October is just a week away which would represent 6 months since 2.6.0 was released. We have several new features now implemented (although I admit I need to spend some time documenting some of them this week) that would be good to get out into the hands of the users.Thus, I'm thinking about doing the 2.7.0 builds sometime next week. That said, we have a couple of snapshot dependencies we need to get released first. Also need to do a bit more testing in the various Karaf containers and such. However, things are definitely looking pretty good. Does anyone have any additional large blocks of work outstanding that they are trying to get in? I can likely help out a little (like for the async JAX-RS methods :-) ) if needed. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Async methods for JAX-RS WebClient
I went ahead and populated AsyncInvoker, as well as added another
shortcut directly to WebClient, to support an async post call.
Dan, have a look please,
One thing that I can have a look later is making sure the retry calls
work in case of async call failures, plus add few more minor
enhancements, overall though it seems it looks OK
Thanks, Sergey
On 23/09/12 18:56, Sergey Beryozkin wrote:
On 23/09/12 18:14, Sergey Beryozkin wrote:
Hi Dan
On 21/09/12 19:27, Daniel Kulp wrote:
Sergey, (and others)
I just committed some initial support for some async methods to the
WebClient. Can you take a look at that change and make sure it all
makes sense? I only have a "get" method in there right now, but it
should be fairly trivial now to add the others that would map to the
new doInvokeAsync method. Just want to make sure it looks ok first.
It is a very good start, thanks for starting to look into it. I think I
will push some of the code to AbstractClient once I get a better
understanding of what is going on, for proxies to get the async support
too.
Other than that, I wonder if we should introduce an "async()" method
which would return
http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/client/AsyncInvoker.html
that would let us support the async style of invocation completely in
line with the way JAX-RS 2.0 does it, example:
WebClient wc = WebClient.create("address");
wc.async().get(callback); // etc
(async() in JAX-RS 2.0 is in
http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/clisystests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRS20ClientServerBookTest.javaent/Invocation.Builder.html)
I added an empty AsyncInvoker implementation, with
async().get(InvocationCallback) also working for now :-).
Wow, it's really happening thanks to the addition of the HTTP async
transport :-)
Thanks, Sergey
In addition to that we can indeed add simple shortcuts, one per every
main method, or for those which are more likely to participate in async
flows, say for get/post/put, to let users 'save' on typing 'async()' for
few mainstream cases
I'm a little concerned about the "state" objects in the WebClient. I
assume WebClients aren't supposed to be thread safe (that's OK).
However, can a WebClient be used to make multiple calls? What would
you expect in the case where a WebClient makes multiple async calls?
By default WebClient is not thread safe, but the thread-safety can be
activated by a threadSafe flag, it can be set on the client factory
bean, or passed to a WebClient factory method. Have a look please at
JAXRSMultithreadedClientTest. A thread-local map is then used to keep a
per-invocation state.
WebClient keeps the state because it emulates the 'browsing' process, so
at any moment it (a single instance) can move back or forward - but that
requires an extra support for the thread safety. 2.0 client interface is
different, no 'browsing' style is there, so it may be much simpler to
deal with the thread safety, I'll fond out soon once I start
implementing it :-)
Cheers, Sergey
