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

"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:

Hi Sandakith,

Sorry I'm commenting on this a little late. A couple of points/questions. I'm wondering if what's going on here is still a mix of the JAX-WS and Axis2/181 POJO support. I know I still owe you my thoughts on how to resolve some of that. I'll try to get that out as soon as I can.

1) You mention in commenting out the code in the EndpointController that the check for a version mismatch is already happening at a higher level. Can you point me to where that code is run? Are you sure that it's creating the same version mismatch faults as the existing JAX-WS behavior?

Beyond that, it's unclear to me what the expectation is for invoking that target endpoint via a GET. If the service is a JAX-WS annotated Java bean and you point it to http://127.0.0.1:8080/axis2/services/CalculatorService/add?value1=1&value2=3 as was mentioned in the JIRA, how is that request data being unmarshalled and sent to the target endpoint?

Given that right now the JAX-WS runtime is only configured to umarshall data via JAXB, I can't see what portion of the code is grabbing those values out of the HTTP request params and passing them to the endpoint. If there is code to support that, how are you mapping that to JAXB? i.e., I can see putting simple params in the URL, but what about anything with a complex object structure?

I think there's value in supporting an HTTP GET for JAX-WS endpoint, but my intent has been to support it only for the JAXWS Provider (javax.xml.ws.Provider) style endpoints.

2) This change also concerns me because of the granularity. I couldn't tell from the JIRA what the original exception was that was happening here. Do you have that? Why would a different classloader be needed to run the ThreadContextMigrator cleanup after all of the processing has been done? Presumably, those migrators are run on the same thread and with the same classloader on the inbound flow when they're called the first time. Do you have any other info about this change?

Thanks,

-Nick


sandakith@apache.org

sandakith@apache.org 12/05/2007 11:15 PM

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

Author: sandakith
Date: Wed Dec  5 21:15:52 2007
New Revision: 601617

URL: http://svn.apache.org/viewvc?rev=601617&view=rev
Log:
Fixing https://issues.apache.org/jira/browse/AXIS2-3382, no objections from anyone. I have tested the build with tests and sample calculator, and confirmed its working

Modified:
  webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server/EndpointController.java
  webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server/JAXWSMessageReceiver.java

Modified: webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server/EndpointController.java
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server/EndpointController.java?rev=601617&r1=601616&r2=601617&view=diff
==============================================================================
--- webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server/EndpointController.java (original)
+++ webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server/EndpointController.java Wed Dec  5 21:15:52 2007
@@ -196,12 +196,13 @@
           eic.setHandlers(new HandlerResolverImpl(endpointDesc.getServiceDescription()).getHandlerChain(endpointDesc.getPortInfo()));
       }

-        if (!Utils.bindingTypesMatch(request, endpointDesc.getServiceDescription())) {
-            Protocol protocol = request.getMessage().getProtocol();
-            MessageContext faultContext = Utils.createVersionMismatchMessage(request, protocol);
-            eic.setResponseMessageContext(faultContext);
-            return false;
-        }
+        //Not needed since this is already handled when eic reaches this level
+        //if (!Utils.bindingTypesMatch(request, endpointDesc.getServiceDescription())) {
+        //    Protocol protocol = request.getMessage().getProtocol();
+        //    MessageContext faultContext = Utils.createVersionMismatchMessage(request, protocol);
+        //    eic.setResponseMessageContext(faultContext);
+        //    return false;
+        //}

       MessageContext responseMsgContext = null;


Modified: webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server/JAXWSMessageReceiver.java
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server/JAXWSMessageReceiver.java?rev=601617&r1=601616&r2=601617&view=diff
==============================================================================
--- webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server/JAXWSMessageReceiver.java (original)
+++ webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server/JAXWSMessageReceiver.java Wed Dec  5 21:15:52 2007
@@ -19,6 +19,9 @@

package org.apache.axis2.jaxws.server;

+import javax.xml.ws.Binding;
+import javax.xml.ws.WebServiceException;
+
import org.apache.axis2.AxisFault;
import org.apache.axis2.addressing.AddressingConstants;
import org.apache.axis2.context.OperationContext;
@@ -43,9 +46,6 @@
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

-import javax.xml.ws.Binding;
-import javax.xml.ws.WebServiceException;
-
/**
* The JAXWSMessageReceiver is the entry point, from the server's perspective, to the JAX-WS code.
* This will be called by the Axis Engine and is the end of the chain from an Axis2 perspective.
@@ -80,8 +80,12 @@

       org.apache.axis2.description.Parameter svcClassParam =
               service.getParameter(PARAM_SERVICE_CLASS);
-
+     ClassLoader prevCl = Thread.currentThread().getContextClassLoader();
       try {
+         //Set the service class loader
+            ClassLoader newCl = service.getClassLoader();
+         Thread.currentThread().setContextClassLoader(newCl);
+        
           if (svcClassParam == null) {
               throw new RuntimeException(
                       Messages.getMessage("JAXWSMessageReceiverNoServiceClass"));
@@ -176,6 +180,8 @@
                   ThreadContextMigratorUtil.performContextCleanup(
                           Constants.THREAD_CONTEXT_MIGRATOR_LIST_ID, axisResponseMsgCtx);
               }
+                //Revert back from service class loader to the previous class loader
+                Thread.currentThread().setContextClassLoader(prevCl);
           }

       } catch (Exception e) {
@@ -193,6 +199,9 @@
           // The AxisEngine expects an AxisFault
           throw AxisFault.makeFault(wse);

+        } finally {
+         // In a case of exception also swith from service cl to previous cl
+         Thread.currentThread().setContextClassLoader(prevCl);
       }

       //This assumes that we are on the ultimate execution thread



---------------------------------------------------------------------
To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-cvs-help@ws.apache.org