cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: isGET in interceptors...
Date Sat, 02 Dec 2006 22:03:10 GMT
Hi James,

On 11/30/06, James Mao <> wrote:
> Hi Dan,
> >
> > 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.
> User will not care about this, they got the feature, they gonna enjoy it.
> For a developer, they also like an easy way to do things, isGET is
> easier to understand than introduce another interceptor, and change the
> chain dynamically,
> that's harder to understand and and harder to debug, and harder to
> maintain

There are maintenance issues with both isGET and changing the chain
dynamically. After thinking about this today, I think its because you're
making things harder by combining two bindings into one. GET is really a
separate WSDL binding and I think we should treat it as so within CXF as
well. See my proposal on the mailing list about this, but I think its wrong
to mix the GET and POST bindings together.

> >
> > 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.
> I didn't say a *LOT*, what i said is *better*
> *Performance* definitely is a *feature* in my mind, don't need to put it
> in the first place, but if we have a good performance, there's no reason
> to change it back to a bad performance.

Performance of SOAP HTTP GET doesn't not trump maintainable and clean code

> >
> > 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.
> The HTTP GET we implemented and the HTTP binding are different things, i
> don't think we need to combine.
> If it's GET, there is no need to synthesizes a document, that will slow
> down the processing.

As I mentioned above, I don't really see squeezing out top performance of
SOAP HTTP GET a goal. I doubt this makes more than a 10% difference.

And I think that's two different use scenario, the HTTP binding require
> user to add extra annotation(extra learning curve, and need to know how
> the mapping works, then you will add documentation, explanations do have
> cost), in isGET way, they don't
> What user need to now is that he/she can use URLConnection invoke the
> service directly, that's *all* he/she need to know, simple, easy, and fast
> For a developer, there's nothing more he/she need to do, almost done for
> them, what he/she need to know is understand what isGET mean, that thing
> can understand in seconds, right?

I'm not saying that we should require annotations for SOAP+GET, I'm saying
that we could just reuse the code to synthesize the document from the URL
parameters and do a similar thing with SOAP+GET case.

So, all in all, the only thing in common is that they all used the GET,
> but that's not the reason we need to combine, they are really two
> different use scenario.
> If someone can not understand what isGET means, i'll be surprised.  Let
> me know if there's any problem of isGET that block your work or
> understanding.

I'm not saying that is hard to understand. I'm saying that IMO it isn't
clean code, it mixes concerns, and is bad for code maintainability.

All this debating isn't relevant if we make SOAP+GET a separate binding on
the service with its own interceptors. See my proposal on the mailing list
for how this might work. My other proposal is that we just make synthesize a
document like the HTTP Binding. I'm OK with either of those options, but I'm
really not OK with the current way for the reasons I mentioned above.

- Dan

Dan Diephouse
Envoi Solutions |

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