8 Replies Latest reply on Mar 14, 2010 5:15 PM by Jan Uhlir

    How can I force a particular WS implementation? How to ensure Metro over Native?

    Jan Uhlir Newbie

      How particular web service implementation is selected? How can I force a particular WS implementation? How can I influence selection of let's say Metro over Native on JBoss?

       

      I cannot find this important piece of information in JBossWS documentation it is quite weird!

       

      What is the WS stack selection route? My naïve imagination how it can work:

      • During the deployment scan all classes in JAR or WAR for @WebService annotations (and WebServiceProvider?).
      • If at least one is detected, package is treated as web service containing. It is time to select the stack.
      • Look for WEB-INF directory (META-INF in some cases), if exists, look for implementation specific files.
      • If none found, use JBossWS Native implementation.
      • If sun-jaxws.xml is found and service class is defined there use SUN Metro implementation (at least for this service class)
      • If jbossws-cxf.xml is found and service class is defined there Apache CXF is used (at least for this service class).

       

      How can I verify for sure which stack is used when I call my web service?

       

      Can I mix web service implementations in one project WAR or JAR?  I am asking from curiosity rather then urgent need.

       

      Can someone clarify this for me?

      Thank you for any hint

      Espinosa

        • 1. Re: How can I force a particular WS implementation? How to ensure Metro over Native?
          Ian Ian Newbie

          I would like to know as well please. I would rather use the Metro stuff than the native stuff.

           

          Thanks,

           

          Ian

          • 2. Re: How can I force a particular WS implementation? How to ensure Metro over Native?
            Jim Ma Apprentice
            Actually you can not mix the web service implementation in the war or jar files.   JBossWS uses "ant deploy-jboss5.x.x" command to replace and install the new stack into jboss container .  There is only one soap stack can be deployed in jboss container. This wiki for your reference : http://community.jboss.org/wiki/JBossWS-Installation
            • 3. Re: How can I force a particular WS implementation? How to ensure Metro over Native?
              Jan Uhlir Newbie

              There is not mentioned there can be only one stack implementation at a time on the JBossWS-Installation wiki page I cannot see it.

               

              Do I even need to install an alternative stack like Metro?

              What happens if I simply bundle in all Metro libraries to my WAR file plus all generated java stuff (from wsgen) and  sun-jaxws.xml and web.xml to WEB-INF. The Metro stack should be used then shouldn't it?

               

              Content of sun-jaxws.xml:

              <endpoints xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime"
                  version="2.0">
                  <endpoint 
                      name="FooService" 
                      implementation="esp.home.wsarena.service.FooService"
                      url-pattern="/FooService"/>
              </endpoints>
              

               

              Content of web.xml:

              <web-app ...>
                  <listener>
                      <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class>
                  </listener>
                  <servlet>
                      <servlet-name>MyWebService</servlet-name>
                      <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class>
                  </servlet>
                  <servlet-mapping>
                      <servlet-name>MyWebService</servlet-name>
                      <url-pattern>/FooService</url-pattern>
                  </servlet-mapping>
              </web-app>
              

               

              I am just worried that deployer will scan classes for @WebService annotations and try to make JBossWS Native web services from them anyway. How to prevent class scanner to checking this particular application or WAR.

              How to get feedback that my service really uses Metro and not Native?

               

              Thank you.

              • 4. Re: How can I force a particular WS implementation? How to ensure Metro over Native?
                Jim Ma Apprentice
                You can see what the soap stack implementation in your jboss server from : 1. jboss start up log message :    14:47:17,780 INFO  [AbstractServerConfig] JBoss Web Services - Native Server    14:47:17,781 INFO  [AbstractServerConfig] 3.2.2-SNAPSHOT 2. jbossws web console : http://localhost:8080/jbossws/  I did not test deploy the ws with metro runtime libaraies into a native soap stack. I believe there is error happens, because the class conflicts or other things. Could you explain why you need to mix the two soap implementation?
                • 5. Re: How can I force a particular WS implementation? How to ensure Metro over Native?
                  Jan Uhlir Newbie

                  Yes it is definitively possible to deploy a Metro based web service to a JBoss with Native stack or without any WS support at all.

                   

                  Yes it is definitively possible to deploy a project using two or more WS stack implementations.

                   

                  I have just finished this example project proving it. You are more then welcome to test it:

                  http://gitorious.org/esp-home/wsarena3/trees/version1

                   

                  Steps to deploy Metro based web service to a hosting AS in a target implementation agnostic way:

                  • Package libraries      to WAR: sun-jaxws:jaxws-rt,      sun-jaxws:streambuffer, sun-jaxws:stax-ex (Maven naming)

                  • Generate WSDL and      server Java stubs (hosting AS will not do it for you) and bundle      them. Use CLI, Ant or Maven tools: wsgen.

                  • In web.xml define FooService servlet as a      com.sun.xml.ws.transport.http.servlet.WSServlet class. Also set      servlet/service URL pattern.

                  • In sun-jaxws.xml define a real implementation class for FooService, it is      esp.home.wsarena.service.FooService in my case, and define service      URL pattern (t is already defined in web.xml!? Rather keem them      same)

                   

                  There are 2 modules in my project - webservice-metro and webservice-native. One using SUN Metro stack (bundled in), other JBoss native stack (expected to be provided by server). Both deploy on the server at the same time successfully. I did not put them in one EAR, there should be no difference. Service implementation is in separate JAR module, the same identical JAR is included into both native and metro WAR packages. There is aslo a simple test client to prove functionality of both modules.

                   

                  You are welcome to try them as:

                  http://localhost:8080/wsarena3-metro/FooService?wsdl

                  http://localhost:8080/wsarena3-native/FooService?wsdl

                   

                  The question remains – how JBoss recognized that FooService in my webservice-metro module is intended to be run as Metro and not a Native? Why JBoss reacted on annotated FooService in webservice-metro modue and not on the very same class in my webservice-native module?

                  Possible answers:

                  A) it detects presence of jaxws libraries (how? Some specific class or a Jar name?)

                  B) it detects presence of jaxws configuration file the sun-jaxws.xml (is it a simple file detection? Or it does deepr context analysis looking for present class names?)

                  C) both above

                  I am very keen to know the answer.

                  • 6. Re: How can I force a particular WS implementation? How to ensure Metro over Native?
                    Alessio Soldano Master

                    What you example is doing is basically leveraging classloading isolation in the war; the Sun libraries you include in the web application take over to the corresponding ones installed in the server (the jaxws impl, etc.)

                    The application server "knows to use Metro" in that case just because of the web.xml you're providing:

                     

                    <listener>
                            <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class>
                    </listener>
                       
                    <servlet>
                            <servlet-name>MyWebService</servlet-name>
                            <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class>
                    </servlet>
                       
                    <servlet-mapping>
                            <servlet-name>MyWebService</servlet-name>
                            <url-pattern>/FooService</url-pattern>
                    </servlet-mapping>

                    As you can see there's no reference to a jaxws annotated class here above; on the countrary, you're refferring to the Metro's servlet and specifying it's servlet context listener. At that point, the Metro specific descriptor (sun-jaxws.xml) enter the game and the rest of the setup is up to the Sun libs.

                     

                    In the case above, the web app is like any other web app to JBoss.

                     

                    The problem with your solution is in the fact you need to bundle a stack implementation with your own application.

                     

                    When you install JBossWS-Metro (the same could be said about JBossWS-CXF, of course) to the application server, instead, you get a proper integration to the AS. For example, besides slimming down the size of you app archive, you no longer need to provide the proprietary sun-jaxws descriptor in your deployment (it's automatically generated by JBossWS-Metro), you get access to the common JBossWS features (centralized endpoint registry, for instance). Also, I did not try your sample (need to mangle with my maven repository setup ;-) to make it build), but can you use EJB3 endpoints with your solution? what about webservice context injection in ejb3 endpoints? what about webservicerefs?

                     

                    I'm not saying what you did is wrong, it's a nice way of having a single app running on Metro on a JBWS-Native configured application server. Unfortunately it's going to suffer from some issues, that's all ;-)

                    • 7. Re: How can I force a particular WS implementation? How to ensure Metro over Native?
                      Alessio Soldano Master

                      Also, if you're interested in the details of the webservice endpoint deployment process, you might want to delve into the deployers code of the AS.

                      There's an interesting series of posts on DZone on this topic by Ales Justin.

                      Btw, on a related topic, I've recently worked on having 2 stacks coexist on AS for providing jaxrpc functionalities with Metro / CXF; you can read about that here.

                      1 of 1 people found this helpful
                      • 8. Re: How can I force a particular WS implementation? How to ensure Metro over Native?
                        Jan Uhlir Newbie

                        Thank you for the very interesting links. The answer must lay in the details of deployment process. Shame that official docs/wiki is very vague on this topic. So far it seems to me that my assumption was correct, that deployment must be intelligent enough to spot Metro servlet configuration and recognize that Metro stack (bundled in stack) is to be used as WS implementation.

                         

                        I am just worried how much reliable is this way. Does new version of JBossWS, JBoss, or Metro breaks it?

                         

                        Yes, I perfectly aware of pros/cons of bundled in ws stack libraries inside EAR/WAR. My summary:

                        Pros:

                        - simple, simpler then in your blog, you don't have to know many details about JBoss internals

                        - target server agnostit, "hermeutic" solution.

                        - nearly any WS implementation, including old version, version supporting WS-RPC can be used

                        - combined with my empiric observation that "all-containing" EARs are common practice not only regarding WS

                        Cons:

                        - much bigger EAR/WAR, slower deploy

                        - is it really reliable solution?

                         

                        I definitively don't assume my way as ideal, suggested, or recommended! It was simply one that I found first, that I know it works. Something that could stir the discussion. Which in your case worked .

                         

                        My original reason was the very same. In some project we need to support two WS stacks, normal one and one "legacy" with support for WS-RPC (Apache Axis 1.x). The other reason was simple curiosity. Is it possible? How? And poor documentation coverage of this topic.