13 Replies Latest reply on Feb 8, 2007 8:15 AM by Jason Greene

    wsimport API, SPI, command line tool, and ant task

    Jason Greene Master

      I checked in a wsimport API, SPI, command line tool and ant task into trunk.

      The WebServiceImporter API is available here:
      http://labs.jboss.com/file-access/default/members/jbossws/downloads/api-docs/org/jboss/ws/tools/jaxws/api/WebServiceImporter.html

      The WebServiceImporterProvider SPI is here:
      http://labs.jboss.com/file-access/default/members/jbossws/downloads/api-docs/org/jboss/ws/tools/jaxws/spi/WebServiceImporterProvider.html

      The custom provider can be specified using the "org.jboss.ws.tools.jaxws.webServiceImporterProvider" system property, or the static field on WebServiceImporter.class.

      The initial provider is based off of a modified version of the sun wsimport implementation, although this is not directly exposed.

      The command line tool documentation is available here:
      http://labs.jboss.com/file-access/default/members/jbossws/downloads/api-docs/org/jboss/ws/tools/jaxws/WSImport.html

      The ant task documentation is available here:
      http://labs.jboss.com/file-access/default/members/jbossws/downloads/api-docs/org/jboss/ws/tools/jaxws/ant/WSImport.html

      -Jason

        • 1. Re: wsimport API, SPI, command line tool, and ant task
          Ole Matzura Novice

          Great!

          We are just preparing soapui 1.7 and related plugins, I can add support for this tool right away.. ok?

          regards!

          /Ole
          eviware.com

          • 2. Re: wsimport API, SPI, command line tool, and ant task
            Jason Greene Master

            Excellent Ole!

            Did you see the thread I posted about WebServiceGenerate?:
            http://www.jboss.com/index.html?module=bb&op=viewtopic&t=100066

            If you want to start integrating with this API, I would like to get your feedback, so we can make any necessary changes (although I expect none) before 2.0.0 release. After that point, this should be a stable backwords compatble API that you and other integrators can rely on.

            Since your project integrates with other WS stacks, I made sure the design can accomidate various classloading strategies. So for example, you might want to create a classloader just for interfacing with jbossws, and then pass this loader to the API, and it won't pollute your main soapui loader. In the case of importing there is also an setAdditionalCompilerClasspath that you would need to use if the jbossws jars are not on the starting classpath.

            Also the API offers you the ability to hook in a printstream so that you can render output into a dialog.

            Let me know if you run into any issues or have any questions.

            Thanks,
            -Jason

            • 3. Re: wsimport API, SPI, command line tool, and ant task
              Ole Matzura Novice

              Thanks Jason!

              I missed that one.. Obviously we should integrate with WSGenerate as well.. to make my life easier, integrated tools in soapui are launced by spawning a seperate process and running the command-line versions.. maybe not the best from a resource-perspective, but it keeps the code clean from "linking"/class-loaders/etc.. I'll try to go with this strategy for these 2 as well (unless there is some reason to do otherwise..)

              Do I "just" need the latest jbossws 2.0 sources to build/run these?

              Also, have there been any changes to the wstools command-line options/config since 1.0.3 that I should support in our dialogs? (just point me to the docs and I can look at the details myself..)

              regards!

              /Ole
              eviware.com

              • 4. Re: wsimport API, SPI, command line tool, and ant task
                Jason Greene Master

                 

                "omatzura" wrote:

                to make my life easier, integrated tools in soapui are launced by spawning a seperate process and running the command-line versions.. maybe not the best from a resource-perspective, but it keeps the code clean from "linking"/class-loaders/etc.. I'll try to go with this strategy for these 2 as well (unless there is some reason to do otherwise..)


                OK, however you like to do it. One thing I was thinking of doing to help integrators concerned with dependencies is to provide a tiny jar (with no dependencies) that contains just the JAX-WS tools API and SPI. An integrator could then include this tiny jar in their classpath. The code would something like:

                WebServiceGenerator generator = WebServiceGenerator.newInstance(new URLClassLoader(impljars));
                generator.setGenerateSource(true);
                generator.setGenerateWsdl(true);
                generator.setOutputDirectory(new File("output"));
                generator.setMessageStream(stream);
                generator.generate(TestMe.class);
                



                Do I "just" need the latest jbossws 2.0 sources to build/run these?


                The least amount of steps would be to checkout and build jbossas/trunk. The wsgen.sh and wsimport.sh scripts are in the bin directory, you can extract the needed jars from those scripte.


                Also, have there been any changes to the wstools command-line options/config since 1.0.3 that I should support in our dialogs? (just point me to the docs and I can look at the details myself..)


                Just a small change:
                http://fisheye.jboss.com/browse/JBossWS/trunk/jbossws-core/src/main/resources/schema/jbossws-tool_1_0.xsd?r1=807&r2=HEAD

                -Jason

                • 5. Re: wsimport API, SPI, command line tool, and ant task
                  Thomas Diesler Master

                  Hey, Jason this is excellent work - well done.


                  The custom provider can be specified using the "org.jboss.ws.tools.jaxws.webServiceImporterProvider" system property, or the static field on WebServiceImporter.class.


                  Please have a look at javax.xml.soap.FactoryLoader

                   /**
                   * Load a factory using this ordered lookup procedure
                   *
                   * 1. Use the system property
                   * 2. Use the properties file "lib/jaxm.properties" in the JRE directory
                   * 3. Use the Services API (as detailed in the JAR specification), if available, to determine the classname
                   * 4. Use the default factory implementation class
                   *
                   * @return the factory impl, or null
                   */
                   public static Object loadFactory(String propertyName, String defaultFactory)
                  


                  This is the lookup we use thrughout the jaxws impl.

                  Now that we have wsgen + wsimport functionality I believe we should make it available in jbossws-1.2.0. This would give us the much needed community QA before 2.0.0

                  Could you please merge your work to jbossws-1.2.0

                  For sake of clarity I suggest we do not refer to wsgen + wsimport when we talk about our tool set. How about: wswsdl, wsjava?

                  cheers

                  • 6. Re: wsimport API, SPI, command line tool, and ant task
                    Jason Greene Master

                     

                    "thomas.diesler@jboss.com" wrote:
                    Hey, Jason this is excellent work - well done.


                    Thanks!


                    Please have a look at javax.xml.soap.FactoryLoader
                    This is the lookup we use throughout the jaxws impl.


                    This shouldn't be used like this for several reasons
                    1. We are not allowed to alter javax.* beyond the specification, so we can't make FactoryLoader public.
                    2. This loader is SAAJ specific and refers to "jaxm.properties", therefore having APIs outside of SAAJ use it will make them non comformant. (e.g javax.xml.ws.spi.Provider)
                    3. It introduces a dependency on our implementation of the API, which is wrong. Our code has to work with any compliant API jar.
                    4. In the case of javax.xml.ws.spi.Provider, it introduces a dependency between differing API jars. So jboss-jaxws.jar can only be used with jboss-saaj.jar.

                    Regardless, in order to allow for the tools API to be standalone (easy for integrators), it needs it's own discovery mechanism. The reason I didn't implement the same number of options is because this API is not a Java spec, so I don't expect that many people will actually want to provide an alternative implementation.


                    Now that we have wsgen + wsimport functionality I believe we should make it available in jbossws-1.2.0. This would give us the much needed community QA before 2.0.0

                    Could you please merge your work to jbossws-1.2.0


                    Sure.


                    For sake of clarity I suggest we do not refer to wsgen + wsimport when we talk about our tool set. How about: wswsdl, wsjava?


                    Personally I think that generate and import are more intuitive names, and they also reflect the API and ant task. Also unlike JAX-RPC tools, wsgen is not the direct opposite of wsimport. It's primary purpose is to generate wrapper classes, so wsdl generation is off by default. So I don't think this particular tool will get a lot of usage on our stack since we generate this dynamically anyway. The other reason I stuck with the common names is to make it easier for someone to move from say the implementation in JDK6 (which uses wsgen and wsimport). Although, the command line arguments are slightly different, which I was hesitant on. The main reason is that I wanted to use gnu getop which simplifies command line argument parsing, follows unix conventions, and is used in other jboss tools. This could be easily changed to directly mirror the arguments in the RI, if you guys think we should.

                    We could also make them jboss-wsgen.sh and jboss-wsimport.sh but that would be extra typing.

                    -Jason

                    • 7. Re: wsimport API, SPI, command line tool, and ant task
                      Thomas Diesler Master

                      I still believe that the jbossws tools should be named differently than the RI tools. Otherwise, there will be a lot of confusion in the forums and *a lot* more typing because it needs to be clarified every time what tools do you actually mean.

                      Also, imagine 1.2.0 is out and somebody googles for wsimport, they surely do not get information on our toolset.

                      My favorite is still wstools (with additional arguments) .

                      Lets discuss the tools integration in 1.2.0 on Thu at the conf call.

                      cheers

                      • 8. Re: wsimport API, SPI, command line tool, and ant task
                        Jason Greene Master

                        I completely disagree. We are talking about commodity tools. Besides, who cares if they some other toolset. The whole point of JAX-WS is that generated output of tooling is portable.

                        • 9. Re: wsimport API, SPI, command line tool, and ant task
                          Jason Greene Master

                           

                          "thomas.diesler@jboss.com" wrote:

                          Also, imagine 1.2.0 is out and somebody googles for wsimport, they surely do not get information on our toolset.


                          This, quite frankly, is the worst reason I have heard to date.


                          • 10. Re: wsimport API, SPI, command line tool, and ant task
                            Jason Greene Master

                            Further, since we do not agree on this, and since the actual team priority is TCK, I suggest that this not be included in 1.2, and in april, after I am gone, you can redo everything yourself.

                            • 11. Re: wsimport API, SPI, command line tool, and ant task
                              David Win Newbie

                              I would like this to be included in 1.2, you guys would get feedback from the community before the big JBoss 5.0 release.

                              I agree with Jason, I think keeping it as wsimport and wsgen adds portability to any JAXWS runtime.

                              Just on a side note, if I was googling...I would use the search "JBoss wsimport" or "JBoss wsgen"

                              • 12. Re: wsimport API, SPI, command line tool, and ant task
                                Thomas Diesler Master

                                Yes, this functionality should be included in 1.2.0 for many reasons. The actual naming of the tools seems to be the only remaining issue and should of course not hold back this important feature.

                                Lets clarify and step back a little.

                                When consuming a thirdparty web service using jbossws (i.e. a web service client) one would start with the abstract contract as input

                                wsdl -> [wsimport]
                                 +- SEI
                                 +- Service
                                 +- JAXB artifacts
                                 +- [wrappers]
                                 +- [impl template]
                                


                                [wrappers] - are generated on demand (i.e. with doc/lit wrapped, for exceptions)
                                [impl template] - a template for the endpoint implementation could be generated

                                When providing a webservice using jbossws one would start with the implementation bean or possibly with a SEI

                                Impl -> [wsgen]
                                [SEI] +- [wrappers]
                                 +- [wsdl]
                                


                                [wrappers] - are generated on demand (i.e. with doc/lit wrapped, for exceptions)
                                [wsdl] - could be generated if asked to do so

                                For branding reasons and clarity sake we cannot name the jbossws tools the same as the RI tools. After some whiteboard sessions, we came up with the following suggestions

                                [wsgen]: javatowsdl, wsserver, wscontract, wsendpoint, wsexport
                                [wsimport]: wsdltojava, wsclient

                                Our favorite choice is underlined.

                                I would like to reach a conclusion on this today, so we can actually bring the feature in and write about is here http://tddell.dyndns.org/mediawiki/index.php/JAX-WS_User_Guide#JBossWS_Tools