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 Lahiru Sandakith <sa...@gmail.com> on 2008/01/07 00:40:53 UTC
Re: svn commit: r601617 - in /webservices/axis2/trunk/java/modules/jaxws/src/org/apache/axis2/jaxws/server: EndpointController.java JAXWSMessageReceiver.java
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