4 Replies Latest reply on Feb 15, 2010 4:24 AM by ropalka

    @Action annotation -- where does it come from?

    adinn

      I need to configure the WSA action associated with the response to an RPC style JaxWS call. I found that I can do this on the current trunk AS with JBossWS Native using the @Action annotation on my server endpoint implementation i.e.

       

      @WebService(targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", name = "RegistrationPortType",
              wsdlLocation = "/WEB-INF/wsdl/wscoor-registration-binding.wsdl",
              serviceName = "RegistrationService",
              portName = "RegistrationPortType"
              // endpointInterface = "org.oasis_open.docs.ws_tx.wscoor._2006._06.RegistrationPortType",
      )
      @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
      // @EndpointConfig(configName = "Standard WSAddressing Endpoint")
      @HandlerChain(file="/handlers.xml")
      @Addressing(required=true)
      public class RegistrationPortTypeImpl implements RegistrationPortType
      {
          @Resource private WebServiceContext webServiceCtx;

          @WebResult(targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters", name = "RegisterResponse")
          @WebMethod(operationName = "RegisterOperation", action = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register")
          @Action(input="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register", output="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/RegisterResponse")
          public org.oasis_open.docs.ws_tx.wscoor._2006._06.RegisterResponseType registerOperation(
              @WebParam(targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters", name = "Register")
              org.oasis_open.docs.ws_tx.wscoor._2006._06.RegisterType parameters
          )
          {
              MessageContext ctx = webServiceCtx.getMessageContext();
              HttpServletRequest request = (HttpServletRequest)ctx.get(MessageContext.SERVLET_REQUEST);
              . . .

      This works fine apart from one detail, the package from whihc @Action is imported. I tried first of all to use the annotation class defined in the JSR 261 JaxWSA specification i.e.

       

      import javax.xml.ws.addressing.Action;

       

      This had no effect. So, I checked the WS source and noticed that all occurences of @Action refer to this class:

       

      import javax.xml.ws.Action;

       

      This includes a WSA-specific test and also the WS metadata processing code. I tried this and it does indeed ensure that the correct action is installed in the response message. However, this is not in accordance with the JSR 261 JaxWSA spec. Should JBossWS native not be using the annotation from the ws.addressing package?

       

      I also need to know what  CXF does in response to either of these annotations? Whatever I implement needs to ensure the correct response action is used on both CFX and Native,

        • 1. Re: @Action annotation -- where does it come from?
          ropalka

          Hi Andrew,

           

             you should use annotations from JSR 224 spec (JAX-WS ). The problem you're dealing with is caused by the fact we claim to support

          withdrawn http://jcp.org/en/jsr/detail?id=261 specification:

           

          see:

           

          http://www.jboss.com/products/platforms/application/standards/

           

          line:

           

          Java API for XML Web Services Addressing (JAX-WSA)  [JSR-261]

           

             JSR-261 was first attempt to bring in WS-Addressing technology to J2EE. This failed and these days addressing is part of JSR-224 specification.

          I'm not yet sure what we'll do with JSR-261 we claim to support. I'll address this issue once I'll review addressing related sections of JSR-224 and TCK6.

             I'd like to ask you don't use anything from packages javax.xml.ws.addressing.* package (defined in JSR-261). It will be removed from JBossWS code base with high probability.

             Also let me know if JSR 261 has something you need and you're missing it in JSR 224 (JAX-WS spec). We could then escalate it to JAXWS EG Alessio is part of.

          • 2. Re: @Action annotation -- where does it come from?
            ropalka
            • 3. Re: @Action annotation -- where does it come from?
              adinn

              Hi Richard,

               

              Yes, I realise that Jax-WA has been dropped but I also know that our stack and the CXF stack support it (albeit not in a standard way). I guess what I am really concerned about is whether I can rely on  use of the @Action annotation in package javax.xml.ws to set the WSA action given that there is no WSA spec. It looks to me like CXF also uses the this annotation but even if it does that's a contingent fact rather than a specified requirement.  I would like my code to run on both CXF and Native now and in future releases.

               

              Perhaps Alessio can raise this issue with the EG. Really, it would be best to try to revive the whole WSA standard again (either in its current form or in some variatiopn of it) since the stated reason for dropping it -- that it was too complex and unnecessary -- was bogus as far as I am concerned. That action seemed to me to be more to do with Sun not having any resource to implement the spec than any argument based on its merits.

               

              Anyway, you can rest assured that I don't currently employ any of JSR 261 directly. Apart form this use of the  javax.xml.ws.Action annotation to derive the WSA action all other WSA configuration is via the MAP abstraction.


              • 4. Re: @Action annotation -- where does it come from?
                ropalka

                Hi Andrew,

                 

                   thanks for confirmation you're just using JAX-WS specification classes/annotations and the classes from jbossws-common as we talked last time. This is the correct way for you to go with JBossWS releases. If you will follow this route, you'll have no portability problems in the future

                 

                Richard