Axis2
  1. Axis2
  2. AXIS2-4611

JAX-WS services can no longer be deployed as AAR

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4, 1.4.1, 1.5, 1.5.1
    • Fix Version/s: 1.7.0
    • Component/s: jaxws
    • Labels:
      None

      Description

      The JAX-WS guide [1] makes the following statement:

      [quote]
      Axis2 provides two mechanisms for deploying JAX-WS services:

      • The service may be packaged and deployed as an AAR, just like any other service within Axis2. Like with all AARs, a services.xml file containing the relevant metadata is required for the service to deploy correctly.
      • The service may be packaged in a jar file and placed into the servicejars directory. The JAXWSDeployer will examine all jars within that directory and deploy those classes that have JAX-WS annotations which identify them as Web services.
        [/quote]

      This is no longer true. The support for the first scenario has been eliminated by the change in r646585 [2]. The commit comment explains the reason for this change as follows: "This is no longer needed now that JAXWS annotated endpoints can be deployed in Axis2." This argument is flawed because service.xml allows to configure the services in ways that are not supported by JAXWSDeployer. Here are some examples of valid use cases which could easily be satisfied if Axis2 supported JAX-WS services deployed as an AAR:

      Other people have complained about the missing AAR/service.xml support, but without explaining their use case:

      A closer look at r646585 reveals that the AAR support was actually considered experimental or at least not fit for production use. Therefore, simply rolling back that change is not an option. Analyzing the code in JAXWSDeployer and JAXWSMessageReceiver, it is also clear that a JAX-WS service can only work if the AxisService description has been created by org.apache.axis2.jaxws.description.DescriptionFactory. This is not the case if the service is deployed by ServiceDeployer (which is the component that deploys AAR files and parses service.xml). Interestingly, ServiceDeployer supports two approaches to build an AxisService:

      1. The AxisService object is entirely built from information in service.xml.
      2. The AxisService object is built from a WSDL, and this description is then completed with the information from the service.xml file.

      Maybe JAX-WS services can be supported using an approach similar to item 2, i.e. by letting DescriptionFactory build the initial AxisService description and then add the information from the service.xml to that description.

      [1] http://ws.apache.org/axis2/1_5_1/jaxws-guide.html
      [2] http://svn.apache.org/viewvc?rev=646585&view=rev

        Issue Links

          Activity

          Andreas Veithen created issue -
          Andreas Veithen made changes -
          Field Original Value New Value
          Description The JAX-WS guide [1] makes the following statement:

          [quote]
          Axis2 provides two mechanisms for deploying JAX-WS services:
          * The service may be packaged and deployed as an AAR, just like any other service within Axis2. Like with all AARs, a services.xml file containing the relevant metadata is required for the service to deploy correctly.
          * The service may be packaged in a jar file and placed into the servicejars directory. The JAXWSDeployer will examine all jars within that directory and deploy those classes that have JAX-WS annotations which identify them as Web services.
          [/quote]

          This is no longer true. The support for the first scenario has been eliminated by the change in r646585 [2]. The commit comment explains the reason for this change as follows: "This is no longer needed now that JAXWS annotated endpoints can be deployed in Axis2." This argument is flawed because service.xml allows to configure the services in ways that are not supported by JAXWSDeployer. Here are some examples of valid use cases which could easily be satisfied if Axis2 supported JAX-WS services deployed as an AAR:

          * AXIS2-4045
          * http://markmail.org/thread/icicgpq27xh2jtie
          * http://markmail.org/thread/oe43iqjzq27k2bnl
          * http://markmail.org/thread/3fbbmxs5llimhwzs

          Other people have complained about the missing AAR/service.xml support, but without explaining their use case:

          * http://markmail.org/thread/2eadng6lwhgpc4ml
          * http://stackoverflow.com/questions/339802/needed-tomcat-axis2-jax-ws-guide-for-dummies

          A closer look at r646585 reveals that the AAR support was actually considered experimental or at least not fit for production use. Therefore, simply rolling back that change is not an option. Analyzing the code in JAXWSDeployer and JAXWSMessageReceiver, it is also clear that a JAX-WS service can only work if the AxisService description has been created by org.apache.axis2.jaxws.description.DescriptionFactory. This is not the case if the service is deployed by ServiceDeployer (which is the component that deploys AAR files and parses service.xml). Interestingly, ServiceDeployer supports two approaches to build an AxisService:

          1. The AxisService object is entirely built from information in service.xml.
          2. The AxisService object is built from a WSDL, and this description is then completed with the information from the service.xml file.

          Maybe JAX-WS services can be supported using an approach similar to item 2, i.e. by letting DescriptionFactory build the initial AxisService description and then add the information from the service.xml to that description.

          [1] http://ws.apache.org/axis2/1_5_1/jaxws-guide.html
          [2] http://svn.apache.org/viewvc?rev=646585&view=rev
          The JAX-WS guide [1] makes the following statement:

          [quote]
          Axis2 provides two mechanisms for deploying JAX-WS services:
          * The service may be packaged and deployed as an AAR, just like any other service within Axis2. Like with all AARs, a services.xml file containing the relevant metadata is required for the service to deploy correctly.
          * The service may be packaged in a jar file and placed into the servicejars directory. The JAXWSDeployer will examine all jars within that directory and deploy those classes that have JAX-WS annotations which identify them as Web services.
          [/quote]

          This is no longer true. The support for the first scenario has been eliminated by the change in r646585 [2]. The commit comment explains the reason for this change as follows: "This is no longer needed now that JAXWS annotated endpoints can be deployed in Axis2." This argument is flawed because service.xml allows to configure the services in ways that are not supported by JAXWSDeployer. Here are some examples of valid use cases which could easily be satisfied if Axis2 supported JAX-WS services deployed as an AAR:

          * AXIS2-4045
          * http://markmail.org/thread/icicgpq27xh2jtie
          * http://markmail.org/thread/oe43iqjzq27k2bnl
          * http://markmail.org/thread/3fbbmxs5llimhwzs

          Other people have complained about the missing AAR/service.xml support, but without explaining their use case:

          * http://markmail.org/thread/2eadng6lwhgpc4ml
          * http://markmail.org/thread/xwld372rj76kara5
          * http://markmail.org/thread/hxfthujyv3ifvdod
          * http://stackoverflow.com/questions/339802/needed-tomcat-axis2-jax-ws-guide-for-dummies

          A closer look at r646585 reveals that the AAR support was actually considered experimental or at least not fit for production use. Therefore, simply rolling back that change is not an option. Analyzing the code in JAXWSDeployer and JAXWSMessageReceiver, it is also clear that a JAX-WS service can only work if the AxisService description has been created by org.apache.axis2.jaxws.description.DescriptionFactory. This is not the case if the service is deployed by ServiceDeployer (which is the component that deploys AAR files and parses service.xml). Interestingly, ServiceDeployer supports two approaches to build an AxisService:

          1. The AxisService object is entirely built from information in service.xml.
          2. The AxisService object is built from a WSDL, and this description is then completed with the information from the service.xml file.

          Maybe JAX-WS services can be supported using an approach similar to item 2, i.e. by letting DescriptionFactory build the initial AxisService description and then add the information from the service.xml to that description.

          [1] http://ws.apache.org/axis2/1_5_1/jaxws-guide.html
          [2] http://svn.apache.org/viewvc?rev=646585&view=rev
          Hide
          Afkham Azeez added a comment -

          Perhaps, what we could do is have a mechanism of associating different types of services with a services.xml file. So, the different deployers will create the base AxisService, and then call a utility passing in that AxisService (and perhaps the location of a services.xml file). That utility will parse that services.xml file, and populate more information into the AxisService. This utility should be called before the registered AxisObservers are called.

          Show
          Afkham Azeez added a comment - Perhaps, what we could do is have a mechanism of associating different types of services with a services.xml file. So, the different deployers will create the base AxisService, and then call a utility passing in that AxisService (and perhaps the location of a services.xml file). That utility will parse that services.xml file, and populate more information into the AxisService. This utility should be called before the registered AxisObservers are called.
          Hide
          Srinath Perera added a comment -

          +1 that would decouple the services.xml file parsing from the deployer, which will avoid repetition of code.

          Show
          Srinath Perera added a comment - +1 that would decouple the services.xml file parsing from the deployer, which will avoid repetition of code.
          Sagara Gunathunga made changes -
          Link This issue relates to AXIS2-5322 [ AXIS2-5322 ]
          Sagara Gunathunga made changes -
          Assignee Sagara Gunathunga [ sagara ]
          Hide
          Sagara Gunathunga added a comment -

          Fixed with AXIS2-5322 improvements.

          Show
          Sagara Gunathunga added a comment - Fixed with AXIS2-5322 improvements.
          Sagara Gunathunga made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 1.7.0 [ 12316136 ]
          Resolution Fixed [ 1 ]

            People

            • Assignee:
              Sagara Gunathunga
              Reporter:
              Andreas Veithen
            • Votes:
              6 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development