You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Andrew Harrison <a....@cs.cardiff.ac.uk> on 2009/03/23 23:49:16 UTC
ContextUtils rebaseResponse
Hi,
I'm trying to use the WSA features in CXF, but am having real
problems. I'm sending some ReplyTo and FaultTo headers in a request
and I have some interceptors to look at these and set properties etc.
When I send a request/response message with these headers in,
MAPAggregator calls ContextUtils.rebaseResponse which has some weird
effects - the out chain on the server side is called with a partial
message. This usually ends in some exception because the interceptors
are not configured on out bound chain, or because the WSA To in the
outbound chain is not set up correctly yet.
I have struggled for a long time trying to work out where in the chain
to put my interceptors which rely on being able to examine the
contents of the AddressingProperties. I now have IN and OUT
interceptors in the PRE_LOGICAL phase with the IN added before
MAPAggregaor, and the OUT added after the MAPAggregator.
rebaseResponse kicks in on the IN chain at the server side if:
(isOneway || !ContextUtils.isGenericAddress(maps.getReplyTo()))
i.e., if the client has sent a ReplyTo to a request/response message
as far as I can see.
Can anyone explain what, why and how the ContextUtils.rebaseResponse
is supposed to do?
cheers,
Andrew
Re: ContextUtils rebaseResponse
Posted by Andrew Harrison <a....@cs.cardiff.ac.uk>.
>
>> is there an easy way (via the API) in CXF to associate a class with a
> service JAXB context?
>
> Do you mean, a way to add the package containing your class to the
> list of
> packages passed to JAXBContext.newInstance() used for marshalling the
> request?
>
yes
> Well, one way would be to use the JAX-WS Dispatch mechanism, which
> allows
> you to explicitly associate a JAXBContext via
> javax.xml.ws.Service.createDispatch() [2]
>
Thanks. Dispatch could be the answer. Typically, I want to create an
instance of something I can invoke given just an EPR, and also
configure the RequestContext. Looks like
public Dispatch<Object> createDispatch(EndpointReference
endpointReference,
JAXBContext context,
Mode mode,
WebServiceFeature...
features)
could be the number.
cheers,
Andrew
Re: ContextUtils rebaseResponse
Posted by Eoghan Glynn <eo...@gmail.com>.
>>> Have any tests been done on the impact of this with other transfer
>>> protocols?
>>
>> By other transfer protocols, do you mean HTTP versus FTP etc.?
>
> yes - protocols that do not support the concept of an Accept.
>I mean sending partial responses - not the asynch response.
Yes we considered this possibility, which is why the WS-* layer doesn't deal
with transport-specific concepts, such as a "202 Accepted" response code.
Instead it delegates to Destination.getBackChannel()[1]. Then the
transport-specific Destination.markPartialResponse() implementation handles
the details (setting the response code to 202 in the HTTP case, but doing
nothing much for JMS).
>> Not really, as HTTP is the primary target transport for WS-RM (why use RM
>> with the JMS transport for example, as this provides its own native
delivery
>> guarantees).
>
> Except this happens without WS-RM as well...
True.
CXF support for WS-A and WS-RM were sortta developed in tandem by myself and
another committer (who has since left the project). So the one influenced
the other.
We decided to use the partial response mechanism in all cases for
consistency. IIRC we were also influenced by some interoperability concerns,
for example with *Systinet.*
> is there an easy way (via the API) in CXF to associate a class with a
service JAXB context?
Do you mean, a way to add the package containing your class to the list of
packages passed to JAXBContext.newInstance() used for marshalling the
request?
Well, one way would be to use the JAX-WS Dispatch mechanism, which allows
you to explicitly associate a JAXBContext via
javax.xml.ws.Service.createDispatch() [2]
Cheers,
Eoghan
[1]
http://cxf.apache.org/javadoc/latest/org/apache/cxf/transport/Destination.html#getBackChannel(org.apache.cxf.message.Message,%20org.apache.cxf.message.Message,%20org.apache.cxf.ws.addressing.EndpointReferenceType)
[2]
http://java.sun.com/javase/6/docs/api/javax/xml/ws/Service.html#createDispatch(javax.xml.namespace.QName,%20javax.xml.bind.JAXBContext,%20javax.xml.ws.Service.Mode)
2009/3/24 Andrew Harrison <a....@cs.cardiff.ac.uk>
>
> On 24 Mar 2009, at 12:13, Eoghan Glynn wrote:
>
> It might be nice to be able to set this somewhere if the message protocol
>>>
>> considers that a 202 might be the best strategy.
>>
>> Shouldn't the <wsa:ReplyTo> header be set to anonymous in those cases?
>> You
>> could provide the callback/sink reference via some other header for
>> example,
>> or via an explicit parameter (say in the style of the <wsrm:AcksTo>)
>>
>
> You're right. ReplyTo implies an asynch response. For my particular
> situation there should either be no ReplyTo, or a controller service that
> receives the response and triggers the sink creation.
>
>>
>>
>> Have any tests been done on the impact of this with other transfer
>>>
>> protocols?
>>
>> By other transfer protocols, do you mean HTTP versus FTP etc.?
>>
>
> yes - protocols that do not support the concept of an Accept. I mean
> sending partial responses - not the asynch response.
>
>
>>
>> Not really, as HTTP is the primary target transport for WS-RM (why use RM
>> with the JMS transport for example, as this provides its own native
>> delivery
>> guarantees).
>>
>
> Except this happens without WS-RM as well...
>
>
>>
>> So when the 202 is sent, I presume the HTTP connection is closed?
>>>
>>
>> Depends on whether HTTP keep-alive was enabled.
>>
>> But assuming it wasn't, then the client will drop the outgoing connection
>> on
>> receiving the 202.
>>
>> Then another connection is opened to send the full response based on the
>>>
>> ReplyTo header?
>>
>> Yes.
>>
>> That's really the nub of it. One sets <wsa:ReplyTo> to a non-anonymous
>> address so as to cause this separate server->client connection to be
>> established when the response is ready for delivery.
>>
>> Cheers,
>> Eoghan
>>
>
> Thanks again.
>
> One slightly unrelated question - is there an easy way (via the API) in CXF
> to associate a class with a service JAXB context? I have a class that is
> modeled in wsdl as having an xsd:any. But I would like client code to be
> able to easily insert their own data structures into the any list and be
> picked up during (un)marshalling.
>
> cheers,
>
>
> Andrew
>
>
>
>>
>>
>> 2009/3/24 Andrew Harrison <a....@cs.cardiff.ac.uk>
>>
>> Hi Eoghan,
>>>
>>> Thanks for the quick response :-)
>>>
>>> This makes sense to me, although it seems potential overkill in some
>>> cases.
>>> It might be nice to be able to set this somewhere if the message protocol
>>> considers that a 202 might be the best strategy. I'm implementing
>>> WS-Eventing. At the moment there is no real need for a 202 because the
>>> messages are just control messages as opposed to application-specific
>>> exchanges (These obviously happen via notification in WSE). I suppose
>>> this
>>> could change.
>>>
>>> Have any tests been done on the impact of this with other transfer
>>> protocols?
>>>
>>> The isPartialResponse(message) was the incantation I was looking for to
>>> handle this in my interceptors - thanks for the clue.
>>>
>>> So when the 202 is sent, I presume the HTTP connection is closed? Then
>>> another connection is opened to send the full response based on the
>>> ReplyTo
>>> header?
>>>
>>> I presume this is the case because my sink service was not actually
>>> deployed until the response to the subscribe operation returned - which
>>> is
>>> where the exception was occurring. This is because you may not want to
>>> deploy a sink unless the source actually accepts your subscription. But
>>> this
>>> is an error on my part - you shouldn't include a replyTo to something
>>> that's
>>> not there yet!!
>>>
>>> I am getting other exceptions now, but I think I can work it out.
>>>
>>> Thanks for you help.
>>>
>>> cheers,
>>>
>>> Andrew
>>>
>>>
>>>
>>> On 24 Mar 2009, at 10:05, Eoghan Glynn wrote:
>>>
>>> Hi Andrew,
>>>
>>>>
>>>> The purpose of ContextUtils.rebaseResponse() is to cause a partial
>>>> response
>>>> to be sent from the server-side interceptor chain when an incoming
>>>> message
>>>> with a non-anonymous <wsa:ReplyTo> is encountered.
>>>>
>>>> A partial response may have some <soap:headers> but always has an empty
>>>> <soap:body/>. The purpose of sending this message is two-fold:
>>>>
>>>> (a) to unblock the client-side transport with a HTTP "202 Accepted"
>>>> response
>>>>
>>>> (b) to optionally allow for certain headers to be passed back to the
>>>> client
>>>> *at the earliest possible opportunity
>>>>
>>>> *The motivation for (a) is to avoid tieing up a connection for the
>>>> duration
>>>> of time required to process the request, given that the full reponse is
>>>> going to be sent on a separate server->client connection.
>>>>
>>>> The main motivation of (b) was the timely provision of WS-RM
>>>> acknowledgements.Any pending ACKs may be encoded in the partial response
>>>> to
>>>> avoid establishing a new server->client connection just to deliver these
>>>> ACKs. Waiting for the full response to be ready in order to send pending
>>>> ACKs may not be feasible as the request may take an indeterminate amount
>>>> of
>>>> time to process.
>>>>
>>>> Now where is the exception on the outgoing partial response actually
>>>> occurring?
>>>>
>>>> Is it in your own interceptor code? Do you need to actually do anything
>>>> specific with the partial response? If not, how about just ignoring it
>>>> and
>>>> allowing it to complete without interference? You can check if a message
>>>> is
>>>> a partial response via the
>>>> org.apache.cxf.message.MessageUtils.isPartialResponse() API.
>>>>
>>>> Cheers,
>>>> Eoghan
>>>>
>>>>
>>>
>>>
> School of Computer Science, Cardiff University,
> Queen's Buildings, 5 The Parade, Cardiff CF24 3AA, Wales, UK
> tel: +44(0)2920 879184
> email: a.b.harrison@cs.cf.ac.uk
>
>
>
>
>
Re: ContextUtils rebaseResponse
Posted by Andrew Harrison <a....@cs.cardiff.ac.uk>.
On 24 Mar 2009, at 12:13, Eoghan Glynn wrote:
>> It might be nice to be able to set this somewhere if the message
>> protocol
> considers that a 202 might be the best strategy.
>
> Shouldn't the <wsa:ReplyTo> header be set to anonymous in those
> cases? You
> could provide the callback/sink reference via some other header for
> example,
> or via an explicit parameter (say in the style of the <wsrm:AcksTo>)
You're right. ReplyTo implies an asynch response. For my particular
situation there should either be no ReplyTo, or a controller service
that receives the response and triggers the sink creation.
>
>
>> Have any tests been done on the impact of this with other transfer
> protocols?
>
> By other transfer protocols, do you mean HTTP versus FTP etc.?
yes - protocols that do not support the concept of an Accept. I mean
sending partial responses - not the asynch response.
>
>
> Not really, as HTTP is the primary target transport for WS-RM (why
> use RM
> with the JMS transport for example, as this provides its own native
> delivery
> guarantees).
Except this happens without WS-RM as well...
>
>
>> So when the 202 is sent, I presume the HTTP connection is closed?
>
> Depends on whether HTTP keep-alive was enabled.
>
> But assuming it wasn't, then the client will drop the outgoing
> connection on
> receiving the 202.
>
>> Then another connection is opened to send the full response based
>> on the
> ReplyTo header?
>
> Yes.
>
> That's really the nub of it. One sets <wsa:ReplyTo> to a non-anonymous
> address so as to cause this separate server->client connection to be
> established when the response is ready for delivery.
>
> Cheers,
> Eoghan
Thanks again.
One slightly unrelated question - is there an easy way (via the API)
in CXF to associate a class with a service JAXB context? I have a
class that is modeled in wsdl as having an xsd:any. But I would like
client code to be able to easily insert their own data structures into
the any list and be picked up during (un)marshalling.
cheers,
Andrew
>
>
>
> 2009/3/24 Andrew Harrison <a....@cs.cardiff.ac.uk>
>
>> Hi Eoghan,
>>
>> Thanks for the quick response :-)
>>
>> This makes sense to me, although it seems potential overkill in
>> some cases.
>> It might be nice to be able to set this somewhere if the message
>> protocol
>> considers that a 202 might be the best strategy. I'm implementing
>> WS-Eventing. At the moment there is no real need for a 202 because
>> the
>> messages are just control messages as opposed to application-specific
>> exchanges (These obviously happen via notification in WSE). I
>> suppose this
>> could change.
>>
>> Have any tests been done on the impact of this with other transfer
>> protocols?
>>
>> The isPartialResponse(message) was the incantation I was looking
>> for to
>> handle this in my interceptors - thanks for the clue.
>>
>> So when the 202 is sent, I presume the HTTP connection is closed?
>> Then
>> another connection is opened to send the full response based on the
>> ReplyTo
>> header?
>>
>> I presume this is the case because my sink service was not actually
>> deployed until the response to the subscribe operation returned -
>> which is
>> where the exception was occurring. This is because you may not want
>> to
>> deploy a sink unless the source actually accepts your subscription.
>> But this
>> is an error on my part - you shouldn't include a replyTo to
>> something that's
>> not there yet!!
>>
>> I am getting other exceptions now, but I think I can work it out.
>>
>> Thanks for you help.
>>
>> cheers,
>>
>> Andrew
>>
>>
>>
>> On 24 Mar 2009, at 10:05, Eoghan Glynn wrote:
>>
>> Hi Andrew,
>>>
>>> The purpose of ContextUtils.rebaseResponse() is to cause a partial
>>> response
>>> to be sent from the server-side interceptor chain when an incoming
>>> message
>>> with a non-anonymous <wsa:ReplyTo> is encountered.
>>>
>>> A partial response may have some <soap:headers> but always has an
>>> empty
>>> <soap:body/>. The purpose of sending this message is two-fold:
>>>
>>> (a) to unblock the client-side transport with a HTTP "202 Accepted"
>>> response
>>>
>>> (b) to optionally allow for certain headers to be passed back to the
>>> client
>>> *at the earliest possible opportunity
>>>
>>> *The motivation for (a) is to avoid tieing up a connection for the
>>> duration
>>> of time required to process the request, given that the full
>>> reponse is
>>> going to be sent on a separate server->client connection.
>>>
>>> The main motivation of (b) was the timely provision of WS-RM
>>> acknowledgements.Any pending ACKs may be encoded in the partial
>>> response
>>> to
>>> avoid establishing a new server->client connection just to deliver
>>> these
>>> ACKs. Waiting for the full response to be ready in order to send
>>> pending
>>> ACKs may not be feasible as the request may take an indeterminate
>>> amount
>>> of
>>> time to process.
>>>
>>> Now where is the exception on the outgoing partial response actually
>>> occurring?
>>>
>>> Is it in your own interceptor code? Do you need to actually do
>>> anything
>>> specific with the partial response? If not, how about just
>>> ignoring it and
>>> allowing it to complete without interference? You can check if a
>>> message
>>> is
>>> a partial response via the
>>> org.apache.cxf.message.MessageUtils.isPartialResponse() API.
>>>
>>> Cheers,
>>> Eoghan
>>>
>>
>>
School of Computer Science, Cardiff University,
Queen's Buildings, 5 The Parade, Cardiff CF24 3AA, Wales, UK
tel: +44(0)2920 879184
email: a.b.harrison@cs.cf.ac.uk
Re: ContextUtils rebaseResponse
Posted by Eoghan Glynn <eo...@gmail.com>.
> It might be nice to be able to set this somewhere if the message protocol
considers that a 202 might be the best strategy.
Shouldn't the <wsa:ReplyTo> header be set to anonymous in those cases? You
could provide the callback/sink reference via some other header for example,
or via an explicit parameter (say in the style of the <wsrm:AcksTo>)
> Have any tests been done on the impact of this with other transfer
protocols?
By other transfer protocols, do you mean HTTP versus FTP etc.?
Not really, as HTTP is the primary target transport for WS-RM (why use RM
with the JMS transport for example, as this provides its own native delivery
guarantees).
> So when the 202 is sent, I presume the HTTP connection is closed?
Depends on whether HTTP keep-alive was enabled.
But assuming it wasn't, then the client will drop the outgoing connection on
receiving the 202.
> Then another connection is opened to send the full response based on the
ReplyTo header?
Yes.
That's really the nub of it. One sets <wsa:ReplyTo> to a non-anonymous
address so as to cause this separate server->client connection to be
established when the response is ready for delivery.
Cheers,
Eoghan
2009/3/24 Andrew Harrison <a....@cs.cardiff.ac.uk>
> Hi Eoghan,
>
> Thanks for the quick response :-)
>
> This makes sense to me, although it seems potential overkill in some cases.
> It might be nice to be able to set this somewhere if the message protocol
> considers that a 202 might be the best strategy. I'm implementing
> WS-Eventing. At the moment there is no real need for a 202 because the
> messages are just control messages as opposed to application-specific
> exchanges (These obviously happen via notification in WSE). I suppose this
> could change.
>
> Have any tests been done on the impact of this with other transfer
> protocols?
>
> The isPartialResponse(message) was the incantation I was looking for to
> handle this in my interceptors - thanks for the clue.
>
> So when the 202 is sent, I presume the HTTP connection is closed? Then
> another connection is opened to send the full response based on the ReplyTo
> header?
>
> I presume this is the case because my sink service was not actually
> deployed until the response to the subscribe operation returned - which is
> where the exception was occurring. This is because you may not want to
> deploy a sink unless the source actually accepts your subscription. But this
> is an error on my part - you shouldn't include a replyTo to something that's
> not there yet!!
>
> I am getting other exceptions now, but I think I can work it out.
>
> Thanks for you help.
>
> cheers,
>
> Andrew
>
>
>
> On 24 Mar 2009, at 10:05, Eoghan Glynn wrote:
>
> Hi Andrew,
>>
>> The purpose of ContextUtils.rebaseResponse() is to cause a partial
>> response
>> to be sent from the server-side interceptor chain when an incoming message
>> with a non-anonymous <wsa:ReplyTo> is encountered.
>>
>> A partial response may have some <soap:headers> but always has an empty
>> <soap:body/>. The purpose of sending this message is two-fold:
>>
>> (a) to unblock the client-side transport with a HTTP "202 Accepted"
>> response
>>
>> (b) to optionally allow for certain headers to be passed back to the
>> client
>> *at the earliest possible opportunity
>>
>> *The motivation for (a) is to avoid tieing up a connection for the
>> duration
>> of time required to process the request, given that the full reponse is
>> going to be sent on a separate server->client connection.
>>
>> The main motivation of (b) was the timely provision of WS-RM
>> acknowledgements.Any pending ACKs may be encoded in the partial response
>> to
>> avoid establishing a new server->client connection just to deliver these
>> ACKs. Waiting for the full response to be ready in order to send pending
>> ACKs may not be feasible as the request may take an indeterminate amount
>> of
>> time to process.
>>
>> Now where is the exception on the outgoing partial response actually
>> occurring?
>>
>> Is it in your own interceptor code? Do you need to actually do anything
>> specific with the partial response? If not, how about just ignoring it and
>> allowing it to complete without interference? You can check if a message
>> is
>> a partial response via the
>> org.apache.cxf.message.MessageUtils.isPartialResponse() API.
>>
>> Cheers,
>> Eoghan
>>
>
>
Re: ContextUtils rebaseResponse
Posted by Andrew Harrison <a....@cs.cardiff.ac.uk>.
Hi Dan,
A one liner does it in ServiceWSDLBuilder in the buildPortType method:
addExtensibilityAttributes(portType, intf.getExtensionAttributes());
One other question re importing schema:
The ServiceWSDLBuilder class, when importing, creates a schema
location of:
String name = baseFileName + "_schema" + (++xsdCount) + ".xsd";
I'm just trying to work out how to reference these, but this line adds
a hard coded name.
I'm reading in the required xsds into XmlSchema objects and adding
these to the serviceInfo. Then the definition generates imports based
on the above.
Is there a more sensible way to import schema into the wsdl?
cheers,
Andrew
On 21 Sep 2009, at 15:15, Daniel Kulp wrote:
>
> Andrew,
>
> It's quite possibly a bug. While working on the WSPolicy
> annotations last
> month, I discovered a BUNCH of places in ServiceWSDLBuilder (the
> class that
> builds WSDL's from the service model) that were not calling the
> addExtensibilityElements to add the extensors or calling
> addDocumentation to
> add the documentation elements. It's quite probable that they
> aren't calling
> the addExtensibilityAttributes method in all the needed places
> either.
>
> Check in there for the place where the portTypes are created and see
> what it's
> doing. Log a bug with a patch if I'm right. ;-)
>
> Dan
>
>
>
> On Mon September 21 2009 8:30:19 am Andrew Harrison wrote:
>> Hi,
>>
>> A while back I threatened to implement WS-Eventing in CXF. I roughed
>> it in, but I have time to do it properly now.
>> So one thing I've noticed - I can't seem to set a WSDL portType
>> attribute from an InterfaceInfo object. I've tried:
>>
>> info.addExtensionAttribute(new QName("http://www.w3.org/2009/06/ws-
>> evt", "EventSource"), "true");
>>
>> but this doesn't get queried in
>> org.apache.cxf.wsdl11.ServiceWSDLBuilder so doesn't appear in the
>> WSDL.
>> Going from WSDL to an InterfaceInfo object works fine.
>>
>> I'm working off the svn code.
>>
>> cheers,
>>
>> Andrew
>>
>> On 24 Mar 2009, at 22:06, Andrew Harrison wrote:
>>>>> I'm
>>>>> implementing WS-Eventing.
>>>>
>>>> oooooo....... Is the WS-Eventing stuff you are working on
>>>> possibly a
>>>> candidate to submit to CXF? :-)
>>>>
>>>> Dan
>>>
>>> Sure. I'm actually hacking this together in a matter of days at the
>>> moment, so it's not very pretty at the moment. But I was hoping to
>>> revisit it in a few weeks and see what could be salvaged.
>>>
>>> cheers,
>>>
>>> Andrew
>>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
Re: ContextUtils rebaseResponse
Posted by Daniel Kulp <dk...@apache.org>.
Andrew,
It's quite possibly a bug. While working on the WSPolicy annotations last
month, I discovered a BUNCH of places in ServiceWSDLBuilder (the class that
builds WSDL's from the service model) that were not calling the
addExtensibilityElements to add the extensors or calling addDocumentation to
add the documentation elements. It's quite probable that they aren't calling
the addExtensibilityAttributes method in all the needed places either.
Check in there for the place where the portTypes are created and see what it's
doing. Log a bug with a patch if I'm right. ;-)
Dan
On Mon September 21 2009 8:30:19 am Andrew Harrison wrote:
> Hi,
>
> A while back I threatened to implement WS-Eventing in CXF. I roughed
> it in, but I have time to do it properly now.
> So one thing I've noticed - I can't seem to set a WSDL portType
> attribute from an InterfaceInfo object. I've tried:
>
> info.addExtensionAttribute(new QName("http://www.w3.org/2009/06/ws-
> evt", "EventSource"), "true");
>
> but this doesn't get queried in
> org.apache.cxf.wsdl11.ServiceWSDLBuilder so doesn't appear in the WSDL.
> Going from WSDL to an InterfaceInfo object works fine.
>
> I'm working off the svn code.
>
> cheers,
>
> Andrew
>
> On 24 Mar 2009, at 22:06, Andrew Harrison wrote:
> >>> I'm
> >>> implementing WS-Eventing.
> >>
> >> oooooo....... Is the WS-Eventing stuff you are working on
> >> possibly a
> >> candidate to submit to CXF? :-)
> >>
> >> Dan
> >
> > Sure. I'm actually hacking this together in a matter of days at the
> > moment, so it's not very pretty at the moment. But I was hoping to
> > revisit it in a few weeks and see what could be salvaged.
> >
> > cheers,
> >
> > Andrew
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: ContextUtils rebaseResponse
Posted by Andrew Harrison <a....@cs.cardiff.ac.uk>.
Hi,
A while back I threatened to implement WS-Eventing in CXF. I roughed
it in, but I have time to do it properly now.
So one thing I've noticed - I can't seem to set a WSDL portType
attribute from an InterfaceInfo object. I've tried:
info.addExtensionAttribute(new QName("http://www.w3.org/2009/06/ws-
evt", "EventSource"), "true");
but this doesn't get queried in
org.apache.cxf.wsdl11.ServiceWSDLBuilder so doesn't appear in the WSDL.
Going from WSDL to an InterfaceInfo object works fine.
I'm working off the svn code.
cheers,
Andrew
On 24 Mar 2009, at 22:06, Andrew Harrison wrote:
>>> I'm
>>> implementing WS-Eventing.
>>
>> oooooo....... Is the WS-Eventing stuff you are working on
>> possibly a
>> candidate to submit to CXF? :-)
>>
>> Dan
>>
>
>
> Sure. I'm actually hacking this together in a matter of days at the
> moment, so it's not very pretty at the moment. But I was hoping to
> revisit it in a few weeks and see what could be salvaged.
>
> cheers,
>
> Andrew
>
>
Re: ContextUtils rebaseResponse
Posted by Andrew Harrison <a....@cs.cardiff.ac.uk>.
>> I'm
>> implementing WS-Eventing.
>
> oooooo....... Is the WS-Eventing stuff you are working on
> possibly a
> candidate to submit to CXF? :-)
>
> Dan
>
Sure. I'm actually hacking this together in a matter of days at the
moment, so it's not very pretty at the moment. But I was hoping to
revisit it in a few weeks and see what could be salvaged.
cheers,
Andrew
Re: ContextUtils rebaseResponse
Posted by Daniel Kulp <dk...@apache.org>.
On Tue March 24 2009 6:57:56 am Andrew Harrison wrote:
> Hi Eoghan,
>
> Thanks for the quick response :-)
>
> This makes sense to me, although it seems potential overkill in some
> cases. It might be nice to be able to set this somewhere if the
> message protocol considers that a 202 might be the best strategy. I'm
> implementing WS-Eventing.
oooooo....... Is the WS-Eventing stuff you are working on possibly a
candidate to submit to CXF? :-)
Dan
> At the moment there is no real need for a
> 202 because the messages are just control messages as opposed to
> application-specific exchanges (These obviously happen via
> notification in WSE). I suppose this could change.
>
> Have any tests been done on the impact of this with other transfer
> protocols?
>
> The isPartialResponse(message) was the incantation I was looking for
> to handle this in my interceptors - thanks for the clue.
>
> So when the 202 is sent, I presume the HTTP connection is closed? Then
> another connection is opened to send the full response based on the
> ReplyTo header?
>
> I presume this is the case because my sink service was not actually
> deployed until the response to the subscribe operation returned -
> which is where the exception was occurring. This is because you may
> not want to deploy a sink unless the source actually accepts your
> subscription. But this is an error on my part - you shouldn't include
> a replyTo to something that's not there yet!!
>
> I am getting other exceptions now, but I think I can work it out.
>
> Thanks for you help.
>
> cheers,
>
> Andrew
>
> On 24 Mar 2009, at 10:05, Eoghan Glynn wrote:
> > Hi Andrew,
> >
> > The purpose of ContextUtils.rebaseResponse() is to cause a partial
> > response
> > to be sent from the server-side interceptor chain when an incoming
> > message
> > with a non-anonymous <wsa:ReplyTo> is encountered.
> >
> > A partial response may have some <soap:headers> but always has an
> > empty
> > <soap:body/>. The purpose of sending this message is two-fold:
> >
> > (a) to unblock the client-side transport with a HTTP "202 Accepted"
> > response
> >
> > (b) to optionally allow for certain headers to be passed back to the
> > client
> > *at the earliest possible opportunity
> >
> > *The motivation for (a) is to avoid tieing up a connection for the
> > duration
> > of time required to process the request, given that the full reponse
> > is
> > going to be sent on a separate server->client connection.
> >
> > The main motivation of (b) was the timely provision of WS-RM
> > acknowledgements.Any pending ACKs may be encoded in the partial
> > response to
> > avoid establishing a new server->client connection just to deliver
> > these
> > ACKs. Waiting for the full response to be ready in order to send
> > pending
> > ACKs may not be feasible as the request may take an indeterminate
> > amount of
> > time to process.
> >
> > Now where is the exception on the outgoing partial response actually
> > occurring?
> >
> > Is it in your own interceptor code? Do you need to actually do
> > anything
> > specific with the partial response? If not, how about just ignoring
> > it and
> > allowing it to complete without interference? You can check if a
> > message is
> > a partial response via the
> > org.apache.cxf.message.MessageUtils.isPartialResponse() API.
> >
> > Cheers,
> > Eoghan
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: ContextUtils rebaseResponse
Posted by Andrew Harrison <a....@cs.cardiff.ac.uk>.
Hi Eoghan,
Thanks for the quick response :-)
This makes sense to me, although it seems potential overkill in some
cases. It might be nice to be able to set this somewhere if the
message protocol considers that a 202 might be the best strategy. I'm
implementing WS-Eventing. At the moment there is no real need for a
202 because the messages are just control messages as opposed to
application-specific exchanges (These obviously happen via
notification in WSE). I suppose this could change.
Have any tests been done on the impact of this with other transfer
protocols?
The isPartialResponse(message) was the incantation I was looking for
to handle this in my interceptors - thanks for the clue.
So when the 202 is sent, I presume the HTTP connection is closed? Then
another connection is opened to send the full response based on the
ReplyTo header?
I presume this is the case because my sink service was not actually
deployed until the response to the subscribe operation returned -
which is where the exception was occurring. This is because you may
not want to deploy a sink unless the source actually accepts your
subscription. But this is an error on my part - you shouldn't include
a replyTo to something that's not there yet!!
I am getting other exceptions now, but I think I can work it out.
Thanks for you help.
cheers,
Andrew
On 24 Mar 2009, at 10:05, Eoghan Glynn wrote:
> Hi Andrew,
>
> The purpose of ContextUtils.rebaseResponse() is to cause a partial
> response
> to be sent from the server-side interceptor chain when an incoming
> message
> with a non-anonymous <wsa:ReplyTo> is encountered.
>
> A partial response may have some <soap:headers> but always has an
> empty
> <soap:body/>. The purpose of sending this message is two-fold:
>
> (a) to unblock the client-side transport with a HTTP "202 Accepted"
> response
>
> (b) to optionally allow for certain headers to be passed back to the
> client
> *at the earliest possible opportunity
>
> *The motivation for (a) is to avoid tieing up a connection for the
> duration
> of time required to process the request, given that the full reponse
> is
> going to be sent on a separate server->client connection.
>
> The main motivation of (b) was the timely provision of WS-RM
> acknowledgements.Any pending ACKs may be encoded in the partial
> response to
> avoid establishing a new server->client connection just to deliver
> these
> ACKs. Waiting for the full response to be ready in order to send
> pending
> ACKs may not be feasible as the request may take an indeterminate
> amount of
> time to process.
>
> Now where is the exception on the outgoing partial response actually
> occurring?
>
> Is it in your own interceptor code? Do you need to actually do
> anything
> specific with the partial response? If not, how about just ignoring
> it and
> allowing it to complete without interference? You can check if a
> message is
> a partial response via the
> org.apache.cxf.message.MessageUtils.isPartialResponse() API.
>
> Cheers,
> Eoghan
Re: ContextUtils rebaseResponse
Posted by Eoghan Glynn <eo...@gmail.com>.
Hi Andrew,
The purpose of ContextUtils.rebaseResponse() is to cause a partial response
to be sent from the server-side interceptor chain when an incoming message
with a non-anonymous <wsa:ReplyTo> is encountered.
A partial response may have some <soap:headers> but always has an empty
<soap:body/>. The purpose of sending this message is two-fold:
(a) to unblock the client-side transport with a HTTP "202 Accepted" response
(b) to optionally allow for certain headers to be passed back to the client
*at the earliest possible opportunity
*The motivation for (a) is to avoid tieing up a connection for the duration
of time required to process the request, given that the full reponse is
going to be sent on a separate server->client connection.
The main motivation of (b) was the timely provision of WS-RM
acknowledgements.Any pending ACKs may be encoded in the partial response to
avoid establishing a new server->client connection just to deliver these
ACKs. Waiting for the full response to be ready in order to send pending
ACKs may not be feasible as the request may take an indeterminate amount of
time to process.
Now where is the exception on the outgoing partial response actually
occurring?
Is it in your own interceptor code? Do you need to actually do anything
specific with the partial response? If not, how about just ignoring it and
allowing it to complete without interference? You can check if a message is
a partial response via the
org.apache.cxf.message.MessageUtils.isPartialResponse() API.
Cheers,
Eoghan
2009/3/23 Andrew Harrison <a....@cs.cardiff.ac.uk>
> Hi,
>
> I'm trying to use the WSA features in CXF, but am having real problems. I'm
> sending some ReplyTo and FaultTo headers in a request and I have some
> interceptors to look at these and set properties etc. When I send a
> request/response message with these headers in, MAPAggregator calls
> ContextUtils.rebaseResponse which has some weird effects - the out chain on
> the server side is called with a partial message. This usually ends in some
> exception because the interceptors are not configured on out bound chain, or
> because the WSA To in the outbound chain is not set up correctly yet.
>
> I have struggled for a long time trying to work out where in the chain to
> put my interceptors which rely on being able to examine the contents of the
> AddressingProperties. I now have IN and OUT interceptors in the PRE_LOGICAL
> phase with the IN added before MAPAggregaor, and the OUT added after the
> MAPAggregator.
>
> rebaseResponse kicks in on the IN chain at the server side if:
>
> (isOneway || !ContextUtils.isGenericAddress(maps.getReplyTo()))
>
> i.e., if the client has sent a ReplyTo to a request/response message
>
> as far as I can see.
>
> Can anyone explain what, why and how the ContextUtils.rebaseResponse is
> supposed to do?
>
> cheers,
>
> Andrew
>
>
>
>