Hola, Apologies for the lag here. Too much traveling going on and I wanted to spend some time thinking through this some more.
Some comments inline. On 3/6/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
Hi Dan, Well if CXF is embedded in another product that *already* exposes an endpoint (e.g. a HTTP listsner) from the client process space, then CXF could use that to receive decoupled responses. All the app needs to do is to provide an appropriate EPR via AddressingProperties.setReplyTo (), set this on the request context, and the CXF WS-A layer won't over-write this with any decoupled response endpoint that may (or may not) have been configured on the Conduit. However, I don't think its reasonable to expect CXF to *actively* launch a decoupled response endpoint on the basis of a replyTo EPR provided by the application, for a number of reasons: 1. the replyTo EPR may not contain all the info that the transport needs to initiate receipt of incoming messages, e.g. JMS may need stuff like a username/password for the connection factory, maybe a JNDI provider etc. This sort of transport-specific stuff may not be suitable for shoe-horning into an EPR, and would probably need to be configured in a transport-specific way.
First, thats an edge case. Second, people are defining standards to shoe-horn JMS info into IRIs. Third, when the decoupled destination is being set up it can still pull configuration from xml files if people need to add extra configuration info. 2. there's no guarantee that the replyTo EPR specified by the app makes
any sense, e.g. it may be for a different transport to that used for the outbound request (and we discussed the undesirability of mixed transport within an MEP on this list a while back).
We should add checks to ensure that this is sane & valid then. Its not that hard to ensure that the ReplyTo transport is the same as the outgoing one. We simply need to match up the transport IDs or the protocol part of the URL. 3. its hard to see how to manage the lifecycle of a listener created on
demand by CXF on foot of an application-provided replyTo. What if the app specifies a different replyTo URI for each sucessive request, maybe intending that the listener is a one-shot deal (i.e. is only intended to accept a single decoupled response). There's no way for the app to communicate this intended lifecycle with CXF, so CXF wouldn't know when to shutdown the Destination.
Lets ignore the per request case a moment: How would this differ from how things currently are? Lets say I define a replyTo endpoint in my cxf.xmlfile. Its not going to get shut down until I specifically shut it down myself or until I shut the appserver down. So letting CXF create a destination automatically would not really be any different. It just makes it easier for the user to set up the decoupled endpoint via the API. Once they are done with the client they could call Client.getDestination().shutdown() and release any resources. (I also would not be opposed to establishing a client life cycle. I.e. a user can call Client.close() once they are done with everything. This would allow RM to terminate the sequence at the same time. But maybe that is a topic for another thread.) Regarding the per request use case, my initial reaction is that we should not do any automatic setup here. The main use case that I'm targeting is creating a standard way to create a decoupled endpoint. If the user is overriding it at a per request level they probably have a good reason for doing so and can manage the endpoint creation themselves. I don't see that as a very common case though. I don't think there is anything that evil about auto-creating a decoupled endpoint for the user if they specify it. But it does make it easy for anyone to do it in a standard way. Which simplifies configuration and documentation. Regards, - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
