On 1/3/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> I'm saying rather than spend our time refatoring common code
> for getBackChannel(), lets go straight to what the root of
> the issue is - namely the points in my previous email I bring
> up. By addressing #1, we effectively address #2 as well for
> the getBackChannel case.
Nope, by addressing #1 we'd at best *partially* address #2.
The point I was stressing in my previous mail is that there's a bunch of
*other* logic duplicated between the servlet and core HTTP transports,
that's totally unrelated to the decoupled case (e.g. the manipulation of
headers and setting properties on received messages).
We should eliminate *all* this duplication, which would not be achieved
by #1.
So we disagree on what the root issue actually is.
My comments were only addressed at the getBackChannel code. Of course I
agree that we should reuse the HttpConfigBean, make sure all the HTTP
properties are supported, etc across all the HTTP transports.
Remember that the creation/sending of the partial response and the
rebase on the decoupled response endpoint is already driven from within
the WS-A layer. No matter how we slice the dice the API used to achieve
this, we still need to interact with the transport, either by necessity
(e.g. as only the transport knows that the partial response should have
a "202 Accepted" status in the HTTP case), or for convenience (e.g. as
the transport knows what ConduitInitiator to use to create the decoupled
backchannel conduit, whereas WS-A would need to do some figuring to
relate a HTTP Destination to a HTTP ConduitInitiator).
So your concern is putting the HTTP 202 accepted on the partial response?
Other than that, the code in JettyHTTPDestination is a pretty simple if
statement:
if (replyToEPR == null) {
return httpBackChannel;
else {
if (partialResponse != null) return httpBackChannel;
else return newConduit(replyToEPR);
}
Seeing that the HTTP partial response stuff is an RM "feature" anyway which
is *specific* to HTTP, whats the harm in putting the message.put(RESPONSE_CODE,
HTTP_ACCEPTED) in RM code? We've already coded in a HTTP specific feature
into RM (partial responses), so we might as well finish it off and put in
the HTTP_ACCEPTED code there too IMO.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
