You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by sa...@apache.org on 2007/12/06 06:15:53 UTC
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
Re: svn commit: r601617 - in /webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server: EndpointController.java JAXWSMessageReceiver.java
Posted by Lahiru Sandakith <sa...@gmail.com>.
Hi Nick,
I with my svn commit: r608797 I revert the code change done to the JAXWS
Class Loader, Since the svn commit: r604813 done to the Axis2 trunk resolve
the issue and it existed with the same time that I was doing the fix. So its
OK.
One other thing that I would like to get your feeedback is on
modules/jaxws/src/org/apache/axis2/jaxws/message/impl/XMLPartBase.java
of this part of the code at the rest invocation and on JAXWS side of the XML
part creation.
} else if (protocol == Protocol.rest) {
this.protocol = Protocol.rest;
// Axis2 stores XML/HTTP messages inside a soap11 envelope. We
will mimic this behavior
if (qName.getNamespaceURI().equals(
SOAP11Constants.SOAP_ENVELOPE_NAMESPACE_URI)) {
// Okay
} else
if (qName.getNamespaceURI().equals(
SOAP12Constants.SOAP_ENVELOPE_NAMESPACE_URI)) {
** throw ExceptionFactory.
** makeWebServiceException(Messages.getMessage
("restWithSOAPErr"));
} else {
content = _createSpine(Protocol.rest, Style.DOCUMENT, 0,
root);
contentType = SPINE;
}
If you remember the scenatio that I asked about getting a POJO deployed with
the basic annotations and with the current JAXWSMessageReceiver the rest
works if we do not have the SOAP12 restriction above. I have tested this. Is
there a particular reason that JAXWS that is do this SOAP version
restriction. Please give your feedback on this.
Thanks
Lahiru Sandakith
On Dec 12, 2007 2:01 PM, Lahiru Sandakith <sa...@gmail.com> wrote:
> Hi Nick ,
>
> This is really strange, when I get an update now and run all the build
> with test cases that include my fix, all the test passes and when it was
> removed these two tests fails,
>
> Failed tests:
> testLoadWSDLImpl(
> org.apache.axis2.jaxws.description.AnnotationServiceImplWithDBCTests)
> testLoadWSDLSEI(
> org.apache.axis2.jaxws.description.AnnotationServiceImplWithDBCTests)
>
> I am bit confused now, will look at the latest changes to find out what
> was the reason to happen this.
>
> Thanks
>
> Sandakith
>
>
>
> On Dec 12, 2007 12:06 PM, Lahiru Sandakith <sa...@gmail.com> wrote:
>
> > Hi Nick,
> >
> > Thanks for the reply.
> >
> > On Dec 11, 2007 8:08 PM, Nicholas L Gallardo <nl...@us.ibm.com>
> > wrote:
> >
> > > 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.
> > >
> > Ok, now got the requirement, I came to conclusion by inspecting the eic
> > and service description. And also found it in the SOAP 1.2 specification
> > under Appendix 'A'. I will fix this.
> >
> > >
> > >
> > > Is the basic problem that this code was blowing up when an HTTP GET
> > > was sent?
> > >
> > Yes it was,
> >
> > > If so, then there's probably a way to fix the code so that it
> > > provides the existing functionality while enabling the HTTP GET.
> > >
> >
> > Before that I attach the fix to this JIRA
> > https://issues.apache.org/jira/browse/AXIS2-3382 to review, I check in
> > the code with full build with tests. Sad that this gone pass those. Anyway
> > I will look more into way that it will handle the scenario inside the Utils
> > where is checks for the missmath. Please send your suggestions on this. Also
> > now we have the confirmation from the users that the sample also works
> > recently,
> > http://www.nabble.com/Re%3A--Axis2--Problem-Axis2-sample---jaxws-calculator-p14211643.html
> >
> > >
> > >
> > >
> > >
> > > 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.
> > >
> > Please explain a bit more, I am thinking on this as any service that is
> > exposed is governed by basic service rules no matter how it was deployed
> > etc.
> >
> > >
> > >
> > > 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.
> > >
> > Ok, but I was in the context that all the services that were deployed in
> > any kind of deployment will rule with generic rules.
> >
> > >
> > >
> > >
> > >
> > > 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.
> > >
> > Yeah, I think my other change was the same thing as setting this param
> > on Axis2.xml, which fixed the issues on JIRA. Please have a look.
> >
> > Thanks
> > Sandakith
> >
> > >
> > >
> > > Regards,
> > >
> > > -Nick
> > >
> > > [image: Inactive hide details for "Lahiru Sandakith"
> > > <sa...@gmail.com>]"Lahiru Sandakith" < sandakith@gmail.com>
> > >
> > >
> > >
> > > *"Lahiru Sandakith" <sa...@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 *<nl...@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.
> > >
> > >
> > > Ok, Cool Nick, Please forward them to me,
> > >
> > >
> > >
> > > 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?
> > >
> > >
> > > 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.
> > >
> > >
> > >
> > > 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
> > > *<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?
> > >
> > >
> > > 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.
> > >
> > > 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 have to look in to this a bit more, I am also bit gray on this.
> > >
> > >
> > >
> > > 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.
> > >
> > >
> > > Ok.
> > >
> > >
> > >
> > >
> > > 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?
> > >
> > >
> > > 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
> > >
> > >
> > >
> > > Thanks,
> > >
> > > -Nick
> > >
> > >
> > > [image: Inactive hide details for sandakith@apache.org]*sandakith@apache.org
> > > * <sa...@apache.org>
> > >
> > >
> > >
> > >
> > > *sandakith@apache.org* <sa...@apache.org>
> > >
> > > 12/05/2007 11:15 PM
> > >
> > > To
> > > *
> > > **axis2-cvs@ws.apache.org* <ax...@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*<http://svn.apache.org/viewvc?rev=601617&view=rev>
> > > Log:
> > > Fixing *https://issues.apache.org/jira/browse/AXIS2-3382*<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
> > > *<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
> > > *<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*<ax...@ws.apache.org>
> > > For additional commands, e-mail: *axis-cvs-help@ws.apache.org*<ax...@ws.apache.org>
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Thanks
> > > Lahiru Sandakith
> > > *
> > > **http://sandakith.wordpress.com/* <http://sandakith.wordpress.com/>
> > > GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01
> > > 9A0F
> > >
> >
> >
> >
> > --
> > Thanks
> > Lahiru Sandakith
> >
> > http://sandakith.wordpress.com/
> > GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F
> >
> >
>
>
>
> --
> Thanks
> Lahiru Sandakith
>
> http://sandakith.wordpress.com/
> GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F
>
--
Thanks
Lahiru Sandakith
http://sandakith.wordpress.com/
GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F
Re: svn commit: r601617 - in /webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server: EndpointController.java JAXWSMessageReceiver.java
Posted by Lahiru Sandakith <sa...@gmail.com>.
Hi Nick ,
This is really strange, when I get an update now and run all the build with
test cases that include my fix, all the test passes and when it was removed
these two tests fails,
Failed tests:
testLoadWSDLImpl(
org.apache.axis2.jaxws.description.AnnotationServiceImplWithDBCTests)
testLoadWSDLSEI(
org.apache.axis2.jaxws.description.AnnotationServiceImplWithDBCTests)
I am bit confused now, will look at the latest changes to find out what was
the reason to happen this.
Thanks
Sandakith
On Dec 12, 2007 12:06 PM, Lahiru Sandakith <sa...@gmail.com> wrote:
> Hi Nick,
>
> Thanks for the reply.
>
> On Dec 11, 2007 8:08 PM, Nicholas L Gallardo <nl...@us.ibm.com> wrote:
>
> > 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.
> >
> Ok, now got the requirement, I came to conclusion by inspecting the eic
> and service description. And also found it in the SOAP 1.2 specification
> under Appendix 'A'. I will fix this.
>
> >
> >
> > Is the basic problem that this code was blowing up when an HTTP GET was
> > sent?
> >
> Yes it was,
>
> > If so, then there's probably a way to fix the code so that it provides
> > the existing functionality while enabling the HTTP GET.
> >
>
> Before that I attach the fix to this JIRA
> https://issues.apache.org/jira/browse/AXIS2-3382 to review, I check in
> the code with full build with tests. Sad that this gone pass those. Anyway
> I will look more into way that it will handle the scenario inside the Utils
> where is checks for the missmath. Please send your suggestions on this. Also
> now we have the confirmation from the users that the sample also works
> recently,
> http://www.nabble.com/Re%3A--Axis2--Problem-Axis2-sample---jaxws-calculator-p14211643.html
>
> >
> >
> >
> >
> > 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.
> >
> Please explain a bit more, I am thinking on this as any service that is
> exposed is governed by basic service rules no matter how it was deployed
> etc.
>
> >
> >
> > 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.
> >
> Ok, but I was in the context that all the services that were deployed in
> any kind of deployment will rule with generic rules.
>
> >
> >
> >
> >
> > 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.
> >
> Yeah, I think my other change was the same thing as setting this param on
> Axis2.xml, which fixed the issues on JIRA. Please have a look.
>
> Thanks
> Sandakith
>
> >
> >
> > Regards,
> >
> > -Nick
> >
> > [image: Inactive hide details for "Lahiru Sandakith"
> > <sa...@gmail.com>]"Lahiru Sandakith" < sandakith@gmail.com>
> >
> >
> >
> > *"Lahiru Sandakith" <sa...@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 *<nl...@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.
> >
> >
> > Ok, Cool Nick, Please forward them to me,
> >
> >
> >
> > 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?
> >
> >
> > 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.
> >
> >
> >
> > 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
> > *<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?
> >
> >
> > 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.
> >
> > 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 have to look in to this a bit more, I am also bit gray on this.
> >
> >
> >
> > 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.
> >
> >
> > Ok.
> >
> >
> >
> >
> > 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?
> >
> >
> > 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
> >
> >
> >
> > Thanks,
> >
> > -Nick
> >
> >
> > [image: Inactive hide details for sandakith@apache.org]*sandakith@apache.org
> > * <sa...@apache.org>
> >
> >
> >
> >
> > *sandakith@apache.org* <sa...@apache.org>
> >
> > 12/05/2007 11:15 PM
> >
> > To
> > *
> > **axis2-cvs@ws.apache.org* <ax...@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*<http://svn.apache.org/viewvc?rev=601617&view=rev>
> > Log:
> > Fixing *https://issues.apache.org/jira/browse/AXIS2-3382*<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
> > *<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
> > *<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*<ax...@ws.apache.org>
> > For additional commands, e-mail: *axis-cvs-help@ws.apache.org*<ax...@ws.apache.org>
> >
> >
> >
> >
> >
> > --
> > Thanks
> > Lahiru Sandakith
> > *
> > **http://sandakith.wordpress.com/* <http://sandakith.wordpress.com/>
> > GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F
> >
>
>
>
> --
> Thanks
> Lahiru Sandakith
>
> http://sandakith.wordpress.com/
> GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F
>
--
Thanks
Lahiru Sandakith
http://sandakith.wordpress.com/
GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F
Re: svn commit: r601617 - in /webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server: EndpointController.java JAXWSMessageReceiver.java
Posted by Lahiru Sandakith <sa...@gmail.com>.
Hi Nick,
Thanks for the reply.
On Dec 11, 2007 8:08 PM, Nicholas L Gallardo <nl...@us.ibm.com> wrote:
> 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.
>
Ok, now got the requirement, I came to conclusion by inspecting the eic and
service description. And also found it in the SOAP 1.2 specification under
Appendix 'A'. I will fix this.
>
>
> Is the basic problem that this code was blowing up when an HTTP GET was
> sent?
>
Yes it was,
> If so, then there's probably a way to fix the code so that it provides the
> existing functionality while enabling the HTTP GET.
>
Before that I attach the fix to this JIRA
https://issues.apache.org/jira/browse/AXIS2-3382 to review, I check in the
code with full build with tests. Sad that this gone pass those. Anyway I
will look more into way that it will handle the scenario inside the Utils
where is checks for the missmath. Please send your suggestions on this. Also
now we have the confirmation from the users that the sample also works
recently,
http://www.nabble.com/Re%3A--Axis2--Problem-Axis2-sample---jaxws-calculator-p14211643.html
>
>
>
>
> 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.
>
Please explain a bit more, I am thinking on this as any service that is
exposed is governed by basic service rules no matter how it was deployed
etc.
>
>
> 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.
>
Ok, but I was in the context that all the services that were deployed in any
kind of deployment will rule with generic rules.
>
>
>
>
> 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.
>
Yeah, I think my other change was the same thing as setting this param on
Axis2.xml, which fixed the issues on JIRA. Please have a look.
Thanks
Sandakith
>
>
> Regards,
>
> -Nick
>
> [image: Inactive hide details for "Lahiru Sandakith"
> <sa...@gmail.com>]"Lahiru Sandakith" <sa...@gmail.com>
>
>
>
> *"Lahiru Sandakith" <sa...@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 *<nl...@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.
>
>
> Ok, Cool Nick, Please forward them to me,
>
>
>
> 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?
>
>
> 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.
>
>
>
> 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
> *<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?
>
>
> 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.
>
> 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 have to look in to this a bit more, I am also bit gray on this.
>
>
>
> 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.
>
>
> Ok.
>
>
>
>
> 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?
>
>
> 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
>
>
>
> Thanks,
>
> -Nick
>
>
> [image: Inactive hide details for sandakith@apache.org]*sandakith@apache.org
> * <sa...@apache.org>
>
>
>
>
> *sandakith@apache.org* <sa...@apache.org>
>
> 12/05/2007 11:15 PM
>
> To
> *
> **axis2-cvs@ws.apache.org* <ax...@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*<http://svn.apache.org/viewvc?rev=601617&view=rev>
> Log:
> Fixing *https://issues.apache.org/jira/browse/AXIS2-3382*<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
> *<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
> *<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*<ax...@ws.apache.org>
> For additional commands, e-mail: *axis-cvs-help@ws.apache.org*<ax...@ws.apache.org>
>
>
>
>
>
> --
> Thanks
> Lahiru Sandakith
> *
> **http://sandakith.wordpress.com/* <http://sandakith.wordpress.com/>
> GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F
>
--
Thanks
Lahiru Sandakith
http://sandakith.wordpress.com/
GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F
Re: svn commit: r601617 - in /webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server: EndpointController.java
JAXWSMessageReceiver.java
Posted by Nicholas L Gallardo <nl...@us.ibm.com>.
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. To
com> axis-dev@ws.apache.org
cc
12/11/2007 07:34 sandakith@apache.org
AM Subject
Re: svn commit: r601617 -
in /webservices/axis2/trunk/java/mo
Please respond to dules/jaxws/src/org/apache/axis2/ja
axis-dev@ws.apach xws/server: EndpointController.java
e.org 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.
Ok, Cool Nick, Please forward them to me,
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?
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.
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?
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.
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 have to look in to this a bit more, I am also bit gray on this.
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.
Ok.
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?
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
Thanks,
-Nick
Inactive hide details for sandakith@apache.orgsandakith@apache.org
sandakith@ap
ache.org
12/05/2007 To
11:15 PM
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.
--
Thanks
Lahiru Sandakith
http://sandakith.wordpress.com/
GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F
Re: svn commit: r601617 - in /webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server: EndpointController.java JAXWSMessageReceiver.java
Posted by Lahiru Sandakith <sa...@gmail.com>.
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 <nl...@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.
>
Ok, Cool Nick, Please forward them to me,
>
>
> 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?
>
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.
>
>
> 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
> *<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?
>
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.
> 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 have to look in to this a bit more, I am also bit gray on this.
>
>
> 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.
>
Ok.
>
>
>
> 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?
>
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
>
>
> Thanks,
>
> -Nick
>
>
> [image: Inactive hide details for sandakith@apache.org]
> 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
>
>
>
--
Thanks
Lahiru Sandakith
http://sandakith.wordpress.com/
GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F
Re: svn commit: r601617 - in /webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server: EndpointController.java
JAXWSMessageReceiver.java
Posted by Nicholas L Gallardo <nl...@us.ibm.com>.
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
To
12/05/2007 11:15 axis2-cvs@ws.apache.org
PM cc
Subject
svn commit: r601617 -
in /webservices/axis2/trunk/java/mo
dules/jaxws/src/org/apache/axis2/ja
xws/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