Hi Sandakith,

A few more comments based on your responses...

<sandakith>Actually when I debug the code for this scenario I found that Actually there is no need for this binding type missmatch check, since it was reached correctly upto that point and when this line executes the mismath check, as I saw it it's creating the same version mismatch faults as the existing JAX-WS.</sandakith>

Can you point me to where in the Axis2 code the mismatch fault is being generated? This code was added to the JAX-WS impl as a requirement of the CTS test suite. Without something concrete that shows a similar behavioral semantic, we need to revert the change and include this code. Leaving this as is would most likely break our JAX-WS compliance within Geronimo, which is a very bad thing as it then puts in jeopardy the JavaEE 5 certification.

Is the basic problem that this code was blowing up when an HTTP GET was sent? If so, then there's probably a way to fix the code so that it provides the existing functionality while enabling the HTTP GET.



Beyond that, it has been our opinion that the JAX-WS POJO style endpoints will not support an HTTP get, given the parameter restriction that I mentioned below. There are two different styles of endpoints in JAX-WS, the POJO style one that you're working with here, and also a Provider style endpoint (javax.xml.ws.Provider) which is a more generic messaging endpoint. If JAX-WS is going to support an HTTP GET, I believe it should only be for the Provider style endpoint.

Given that, these changes are made trying to support a scenario that's not intended for JAX-WS. I do understand that this is supported for the base Axis2 POJO endpoints, but that is completely different programming model.



If you agree with my comments above, my recommendation is that we revert the version mismatch changes. I need to look at the TCCL option that you mention a little more and see if we need to make other changes in the JAXWSMessageReceiver.

Regards,

-Nick

Inactive hide details for "Lahiru Sandakith" <sandakith@gmail.com>"Lahiru Sandakith" <sandakith@gmail.com>


          "Lahiru Sandakith" <sandakith@gmail.com>

          12/11/2007 07:34 AM
          Please respond to
          axis-dev@ws.apache.org


To

axis-dev@ws.apache.org

cc

sandakith@apache.org

Subject

Re: svn commit: r601617 - in /webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server: EndpointController.java JAXWSMessageReceiver.java

Hi Nick,

I missed the mail also, in my commit mails, so sorry for the late reply too.

On Dec 6, 2007 8:45 PM, Nicholas L Gallardo <nlgallar@us.ibm.com > wrote:


Ok, Cool Nick, Please forward them to me,
Actually when I debug the code for this scenario I found that Actually there is no need for this binding type missmatch check, since it was reached correctly upto that point and when this line executes the mismath check, as I saw it it's creating the same version mismatch faults as the existing JAX-WS.
With this fix the service works when invoking the target endpoint from codegenerated client and via a GET. I thought these are the basic axis2 needs.
I have to look in to this a bit more, I am also bit gray on this.
Ok.
ok, mee too found that in axis2.xml we can set a param called serviceTCCL, and we can set it to compond, this can be found at the AbstractMessageReceiver. Guess it do the same thing, Have you guys being using that with the JAXWS?

Thanks
Sandakith

To

axis2-cvs@ws.apache.org
cc
Subject

svn commit: r601617 - in /webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server: EndpointController.java JAXWSMessageReceiver.java



--
Thanks
Lahiru Sandakith

http://sandakith.wordpress.com/
GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F