cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: isGET in interceptors...
Date Thu, 30 Nov 2006 19:22:06 GMT
On 11/29/06, James Mao <james.mao@iona.com> wrote:
>
> Hi Dan,
>
> It's not just SoapHttp, it works for all the *Http Bindings, so
> currently it works for XMLBinding SOAP11 and SOAP12.
> If we do what you said,  there still will have several interceptors
> introduced, it  increase the complexity  in my mind.
> If we add new interceptors, and it's nothing to do with GET, we still
> need to add the interceptor to the exclude list, that cause the maintain
> cost.
> If we just add
> if (isGET()) {
> return;
> }
> That's more easier to understand how the GET works. the way just make
> more sense to me.


Not to me. Now we have 9 different references to isGET scattered throughout
the codebase. What happens when users write their own interceptors? They're
going to be surprised to find that their interceptor breaks GET usage. We've
just made things harder from a developer and user's perspective.


And I think to remove the interceptors dynamically also cause the
> performance issue.


I don't think it will be that much of a performance hit. Also, I don't
really care about the performance of the SOAP HTTP GET case. Its a secondary
concern of ours.

The isGet just boost the processing, it will return fast if it detect
> it's a GET method and the interceptor has nothing to do with GET.
> I didn't see any harm to do so, it's just a three check lines, the code
> is readable, and easy to maintain.
> And it's extremely fast  when you try SOAP GET, or XML GET, i have
> checked in a demo to show how it works with SOAP12
> it's in samples/soap12, but you can try other demos as well.
> Usage:
> > ant client.get
>
> You can even  use your favorite browser to GET the service
>
> I might think to check in a PHP demo or Ruby demo to show how other
> language can consume CXF  service through the HTTP GET.



I'm aware of how it works. And I like the feature. But I don't like the way
it was implemented as it has side effects all throughout the code base. This
is part of the reason the HTTP binding just synthesizes a document.

I think we need to come up with a better way. My preference would be to
unify the code in the HTTP binding and the current HTTP GET/POST for the XML
& SOAP bindings.

I think doing the document synthesis is the best way as you can leverage
your databinding layer then. It has the following advantages:
1. GET with the HTTP binding works with types beyond just the simple Java
types (i.e. it could work with Dates or enumerations)
2. It doesn't scatter HTTP code throughout our codebase
3. It doesn't force developers to know about isGET
4. It leverages the existing databinding to do work for us
5. It creates less code as we don't have two different HTTP GET mapping
mechanisms in the codebase

As I said I really don't care too much about HTTP GET performance. Have you
done performance tests? I doubt that creating a small small document really
creates too much of a hit anyway.

Regards
- Dan
>
>
>
>
> > Hi James,
> > I noticed you put isGET in several interceptors, including the
> > AbstractPhaseInterceptor to detect the HTTP get case. I don't think we
> > should be doing that as those interceptors shouldn't have to be aware of
> > whether or not it is a GET invocation or not. One way around this
> > might be
> > to add an interceptor which removes the unncessary interceptors from the
> > chain for the HTTP GET case...
> >
> > public classSoapHttpInterceptor {
> > public void handleMessage(Message m) {
> > if (isGET()) {
> >  message.getChain().remove(MultipartMessageInterceptor.class.getName
> ()));
> > ...
> > }
> > }
> > }
> >
> > There might be other ways as well - but I really don't think having
> isGET
> > everywhere is the right way to handle things
> >
> > Cheers,
> > - Dan
> >
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message