6 Replies Latest reply on May 22, 2009 12:04 PM by Alessio Soldano

    JBossWS suffers NPE when OneWay messages employ a  WSA Reply

    Andrew Dinn Master

      I have come across a problem in the JBossWS/CXF (I am using 3.1.0 in AS 5.1.0.Beta1 but I think it also affects 3.1.1 and 5.1.0.CR1). It relates to the use of WSA headers with OneWay JaxWS based service requests.

      The problem only manifests when the ReplyTo header is non-null and is not the ANONYMOUS or NONE address. This may seem a strange situation (why should a one way message employ a ReplyTo at all) but the case in which it occurs is real -- the OASIS interoperability tests for Web Services transactions. The service which receives the one way request is expected to make a subsequent one way request to a related service using the value in the ReplyTo address as the service URL. I cannot avoid supplying ReplyTo because the spec demands it and other implementations will expect it.

      The actual problem is in the JBossWS code. At the servlet end of the CXF interceptor chain, before executing the interceptors, the WS code calls EndpointAssociation.setEndpoint() to stash the endpoint info into a thread local (this occurs in CXFServletExt at line 132). The final entry in the CXF interceptor chain which dispatches to the endpoint implementation bean calls EndpointAssociation.getEndpoint() to retrieve this stashed endpoint info (this happens in Abstractinvoker at line 134).

      Now the problem is that when CXF determines that

      i) a message is OneWay
      ii) it is using WSA and
      iii) the ReplyTo is neither null, NONE nor ANONYMOUS

      it decides to be clever. It spawns a separate thread to run the interceptor chain and allows the servlet handler thread to return early. Of course this means that the value stashed in the thread local is not available to AbstractInvoker which promptly falls over with an NPE at line 135.

      I don't know how to work around this.Perhaps the endpoint data could be hung off the request rather than off the thread?

        • 1. Re: JBossWS suffers NPE when OneWay messages employ a  WSA R
          Andrew Dinn Master

          I forgot to add that the sidestep to another thread happens in class MAPAggregator method mediate() at line 352 where a call is made to ContextUtils.rebaseResponse()

          • 2. Re: JBossWS suffers NPE when OneWay messages employ a  WSA R
            Alessio Soldano Master

            Thanks Adrew for the analisys; I'll take a look at this soon and let you know.

            • 3. Re: JBossWS suffers NPE when OneWay messages employ a  WSA R
              Richard Opalka Master

              Yes Andrew, ThreadLocals are real nightmare. I'm spending many hours fighting with them on CXF these days :(

              • 4. Re: JBossWS suffers NPE when OneWay messages employ a  WSA R
                Richard Opalka Master

                 

                "adinn" wrote:

                it decides to be clever. It spawns a separate thread to run the interceptor chain and allows the servlet handler thread to return early. Of course this means that the value stashed in the thread local is not available to AbstractInvoker which promptly falls over with an NPE at line 135.


                Hi Andrew,

                I think JBWS-2577 solves your issue. I'm talking about the following commit:

                [/home/opalka][/home/opalka/svn/jbossws/spi/trunk/src/main/java/org/jboss/wsf/spi/invocation]>svn log --limit=1 EndpointAssociation.java
                ------------------------------------------------------------------------
                r9645 | alessio.soldano@jboss.com | 2009-03-20 19:53:13 +0100 (Fri, 20 Mar 2009) | 2 lines

                [JBWS-2577] Using InheritableThreadLocal for EndpointAssociation as CXF now spans new thread when serving @OneWay requests

                ------------------------------------------------------------------------
                [/home/opalka][/home/opalka/svn/jbossws/spi/trunk/src/main/java/org/jboss/wsf/spi/invocation]>svn diff -r 9644:9645 EndpointAssociation.java
                Index: EndpointAssociation.java
                ===================================================================
                --- EndpointAssociation.java (revision 9644)
                +++ EndpointAssociation.java (revision 9645)
                @@ -31,7 +31,7 @@
                */
                public final class EndpointAssociation
                {
                - private static final ThreadLocal endpoint = new ThreadLocal();
                + private static final ThreadLocal endpoint = new InheritableThreadLocal();

                public static void setEndpoint(Endpoint ep)
                {


                Could you try JBossWS-CXF 3.1.1 against one of the supported target containers to verify my claim?

                • 5. Re: JBossWS suffers NPE when OneWay messages employ a  WSA R
                  Andrew Dinn Master

                   


                  Could you try JBossWS-CXF 3.1.1 against one of the supported target containers to verify my claim?


                  Hi Richard,

                  I tried this but it fails for other reasons. It appears that the version of CXF on which 3.1.1 is based does not include a patch I provided for CXF-2161

                  URL: https://issues.apache.org/jira/browse/CXF-2161

                  The CXF JIRA says this has been fixed in 2.1.1 but 3.1.1 appears to be based on 2.2(.0).

                  XTS also requires a fix for CXF-2167

                  URL: https://issues.apache.org/jira/browse/CXF-2167

                  which is also fixed in 2.2.1 but not in 2.2(.0).


                  • 6. Re: JBossWS suffers NPE when OneWay messages employ a  WSA R
                    Alessio Soldano Master

                    Hi Andrew.
                    yes, you're right, jbossws-cxf-3.1.1 uses CXF 2.2(.0).
                    You're fixes are in 2.2.1 which is currently installed in the 3.1.2-SNAPSHOT. We plan to update to 2.2.2 too before releasing jbossws-cxf.3.1.2.GA.