1 2 Previous Next 19 Replies Latest reply on Jul 29, 2010 11:47 AM by adinn Go to original post
      • 15. Re: Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9
        adinn

        Hi Jim,

         

        Jim Ma wrote:


        When I use a ssl client running in another jvm to send oneway request, the server can always get the "https" schema without error.  Can you see if there any difference between my test setup with XTS test code and configuration here?

         

        Sorry for the delay in replying -- I have been very busy on other stuff. I'll see if I can isolate what happens in my case that makes it different from yours. If I cannot work out what is happening then I will provide instructions for running the specific XTS test(s) which manifests the problem.

         

        regards,

         

         

        Andrew Dinn

        • 16. Re: Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9
          adinn

          Hi Jim,

           

          I am not sure what is different in my code that makes request.getScheme() fail with an NPE while your code works ok but I think it is just luck.

           

          I traced execution through a test case and it appears that the incoming message relates to a valid request. Because this is a one way message there is a handover of control in ContextUtils at line 416

           

           

          416                     inMessage.getInterceptorChain().pause();

           

                                  // ... and resume on executor thread
                                  getExecutor(inMessage).execute(new Runnable() {
                                      public void run() {
          421                             inMessage.getInterceptorChain().resume();
                                      }

           

           

          I checked the request by stopping at 416 and looking up the stack to find the request. The HttpServletRequest object is actually a facade object which indirects to an underlying catalina connector request. It had a name like "Current Servlet stack for thread http-127.0.0.1-8080-1 [S] ActivationService [org.jboss.wsf.stack.cxf.CXFServletExt]". request.getScheme() worked on this object without a NPE.

           

          I picked control up again in the debugger at 421 but, of course, there was no servlet method up the stack where I coudl locate the request. So, I proceeded to step through the code until the ServiceInvokerInterceptor was called. In AbstractInvoker.invoke() the web service context is set up

           

          public Object invoke(Exchange exchange, Object o)
             {
                // set up the webservice request context
                WrappedMessageContext ctx = new WrappedMessageContext(exchange.getInMessage(), Scope.APPLICATION);

                Map<String, Object> handlerScopedStuff = removeHandlerProperties(ctx);

                WebServiceContextImpl.setMessageContext(ctx);

          101   Object retObj = null;

           

           

          At line 101 I evaluated ctx.get("HTTP.REQUEST") and got another facade hiding a catalina connector request with name "Current Servlet stack for thread default-workqueue-2". However all the fields of this catalina connector request appear to be uninitialised and getScheme() returns null. So, this looks to me like the request is coming out of a thread local and it is pot luck whether the object behind the facade has been initialised or not. IN your tests it may be that a previous call has set values in this object.

           

          regards,

           

           

          Andrew Dinn

          • 17. Re: Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9
            jim.ma

            Hi Andrew,

            Sorry for the late response . I was occupied with the TCK stuff last week.

            Thanks for your good analysis. After I added the @Addressing annotation in the service implementation class , I successfully reproduced this error . When I enabled WSA for this oneway operation , I  got null value from http request too.  This is another bug in CXF when run with Tomcat/JBossWeb.

             

            416                     inMessage.getInterceptorChain().pause();

                                    // ... and resume on executor thread
                                    getExecutor(inMessage).execute(new Runnable() {
                                        public void run() {
            421                             inMessage.getInterceptorChain().resume();
                                        }

             

             

            I debuged the 416 thread for the oneway and WSA enable operation. When  this line executed, this thread(http-127.0.0.1-8080-1) will continue to  do the left thing to set the http status code  and cleanup some thing.  The cleanup thing includes the Request.recycle() :

            package org.apache.coyote;
            public final class Request{
            public void recycle() {
                    bytesRead=0;

                    contentLength = -1;
                    contentTypeMB = null;
                    charEncoding = null;
                    headers.recycle();
                    serverNameMB.recycle();
                    serverPort=-1;
                    localPort = -1;
                    remotePort = -1;
                    available = 0;

                    cookies.recycle();
                    parameters.recycle();

                    unparsedURIMB.recycle();
                    uriMB.recycle();
                    decodedUriMB.recycle();
                    queryMB.recycle();
                    methodMB.recycle();
                    protoMB.recycle();

                    schemeMB.recycle();

                    instanceId.recycle();
                    remoteUser.recycle();
                    authType.recycle();
                    attributes.clear();
                }
            }

            After this executed, all the request information will be cleared.  So the interceptors running

            in 421 line thread gets the null value from Request.schemeMB.

             

            I created a JIRA in CXF https://issues.apache.org/jira/browse/CXF-2911 and looking at a fix.

             

            Thanks,

            Jim

            • 18. Re: Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9
              jim.ma

              Hi Andrew, I have fixed this issue in CXF code base . I will merge this fix to the branch for the next release later . It will be picked up in the next jbossws-cxf release.

              • 19. Re: Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9
                adinn

                Jim Ma wrote:

                 

                Hi Andrew, I have fixed this issue in CXF code base . I will merge this fix to the branch for the next release later . It will be picked up in the next jbossws-cxf release.

                Thanks Jim. Nice work :-)

                1 2 Previous Next