cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <james....@iona.com>
Subject Re: isGET in interceptors...
Date Mon, 04 Dec 2006 02:45:46 GMT
Hi Dan
>
> There are maintenance issues with both isGET and changing the chain
> dynamically. 
Agreed
> 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.
I'm not quite understand why there's a problem of mixing the GET and 
POST together?
You mean when user want to use GET, he should configure the service as a 
GET serviceļ¼Œ
and configure the POST as POST service?
>
>> >
>> > 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.
I don't have a test result for this. but think about there is no 
marshall/unmarshall in the client side ,
and there is no unmarshall in the service side, there is only marshal 
happen in the service side.
If we synthesizes a document, there will have marshall/unmarshall in the 
client side, and there will have marshall/unmarshall in the service 
side. am i correct?
I mean, that's will degrade the performance, and i don't like it, as a 
GET i suppose it's quicker and simpler than normal invocation, and i 
think that the big benefit we use GET, right?
otherwise, why people select GET?
>
> 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.
>
As i said to synthesize a document is really not a good way to do this.
seems that change the chain dynamically better than synthesize a 
document, but as is said it's not that good too, for example, sometimes 
we want to use an interceptor, but we need to skip the interceptor in 
some cases.
And from a maintenance point view, i really didn't see any difference.

I'm open to change. and i think we can find a better solution. right?

And the most important thing is that we can keep the GET as fast as it 
could be. and make user easier to use the service, no extra learning curve.
Any implementation can achieve this goal, is a good implementation.
If we can improve the current implementation and also achieve the goal 
that's a correct thing to do.

Cheers,
James.




Mime
View raw message