Are the WLS 9.1 Web Service Ant Tasks ready for prime time?

Question

I am trying to create a Proof of Concept (POC) for Enterprise and B2B Services at Wendy's Int'l, Inc.
As part of this POC, I created a WSDL for an in-house service and then used the wsdlc and jwsc Ant Tasks to translate this WSDL to Java classes and ultimately (I hoped) a deployable services.
In this document, I describe the issues I encountered setting up what I consider to be a simple POC.
I'll try to attach my WSDL file and build.xml so you can follow along.
I'll also try to attach my CSS file so you can compare how the generated WSDL appears in the Browser to the way I want it to appear.
If attachments are not allowed on these forums, then I will wait and see if there is interest in those documents before I paste them under this topic.
Some preliminary information about my environment.
Environment:
     Windows XP Pro SP2
     WebLogic 9.1
     Java 1.5.0_04
Service Name:
     AppRelease
Note: If I modify my WSDL (perhaps to add a new Operation or to change the definition of an element) and run wsdlc again, the AppReleaseSOAPPortImpl.java file is overwritten For this reason, I implemented my service logic in a class called AppReleaseServiceImple.java.
Now, for the issues.
1.     Bug:
In the WSDL generated by wsdlc, the wsdl:part child of the wsdl:message tag is erroneously prefixed with a colon.
This occurs whether or not I specify a prefix for the http://schemas.xmlsoap.org/wsdl/ namespace.
Work around: Extract the wsdl from the jar file, fix it and add it back into the jar.
2.     Bug:
In the WSDL generated by wsdlc, the wsdl:input and wsdl:output children of the wsdl:operation child of wsdl:portType tag are erroneously prefixed with a colon. Like 1 above, this occurs whether or not I specify a prefix for the http://schemas.xmlsoap.org/wsdl/ namespace.
Work around: Extract the wsdl from the jar file, fix it and add it back into the jar.
The error message generated by Bugs 1 and 2 is not helpful in diagnosing the problem:
[jwsc] Error at line:46 col:7 ':' expected [?! -- [CDATA[ ]
3.     Bug:
In the WSDL generated by wsdlc, the documentation elements have all of my html elements stripped out, as well as my xhtml and wsdl namespace references. This completely negates one of the best features of the documentation tag, being able to present the WSDL in a browser as a nicely formatted, human friendly document which is also the underlying WSDL that can be viewed when the person views the source document.
I label this as a bug because it greatly reduces the functionality of the resulting WSDL.
4.     Annoyance:
The WSDL generated by wsdlc has all of my comments stripped out, except the comments in the xsd:schema section of the wsdl:types element. I would prefer that all my comments be left in the WSDL, but if comments must be stripped out then I think all of the comments should be stripped out.
5.     Annoyance:
The WSDL generated by wsdlc has my CSS specification stripped.
Work around: I don’t know if adding the CSS back will do any good because I have not yet created a deployable service (see the last issue below).
6.     Annoyance:
The WSDL generated by wsdlc has different namespace prefixes than the ones I specified for my application's namespace and for the http://schemas.xmlsoap.org/wsdl/soap/ namespace.
Work around: Perform a find/replace on namespace prefixes "s0" and "s1" to return them to my prefered values.
Another thing I can do at this point is simply replace the generated WSDL in the jar file with my original WSDL. This would address issues 1 thru 6 above.
7.     Annoyance:
The java source files created by wsdlc are put into a jar file. This makes it annoying when working within a traditional IDE like Eclipse because there is no way to reference the source files within the jar as working source.
Work around: Extract the source files from the jar and identify the resulting directory structure as part of the source structure of the project.
8.     Bug:
The jwsc task complains if the same parameter name is used in multiple operations. I received the following Errors from jwsc:
[jwsc] C:\IDE\workspace\Acre-WL9.1\AppReleaseSOAPPort.java 0:0
[jwsc] [ERROR] - Parameter element "{http://acre.services.wendys.com/AppRelease/}garRequest" is not unique across document/literal bare WebService.
Since the operation names are unique, I see no reason to also require uniqueness in the parameter names used by those operations.
Work around: Use unique element names for the input parameters of the services operations.
9.     Bug:
Once items 1, 2 and 8 above are taken care of, jwsc fails with the following error:
java.lang.AssertionError: java.lang.ClassNotFoundException: weblogic.j2ee.descriptor.ApplicationBeanImpl
This seems to be due to the weblogic.jar file not being in the System Classpath.
However, I should note that when I set verbose="on" and debug="on" in the jwsc ant task, there was a message from the task which stated "[jwsc] [search path for class files: [big freakin’ jar list]". In the big freakin’ jar list, I did find weblogic.jar and weblogic.jar has the required ApplicationBeanImpl. This indicates to me that the jwsc task does not fully honor either its classpathref attribute, nor an embedded classpath element.
Work around: Make sure the weblogic.jar is in the System Classpath.
10.     Bug:
I fixed bug #9 by running a setDomainEnv script and then ran my ant task. This time I received the following output:
ant build-serviceBuildfile: build.xml
build-service:
[jwsc] 1 JWS files will be processed.
[jwsc] Processing JWS: C:\IDE\workspace\Acre-WL9.1\src\com\wendys\services\acre\AppReleaseServiceImpl.java
[jwsc] JWS: C:\IDE\workspace\Acre-WL9.1\src\com\wendys\services\acre\AppReleaseServiceImpl.java Validated.
[AntUtil.deleteDir] Deleting directory <some temporary directory>
BUILD FAILED
java.lang.ExceptionInInitializerError
At this point, I am completely stymied about how to proceed.
I wonder what new issues await once this 10th issue is addressed.
Really, is this tool set ready for prime time?

Answer 1

<i>Sorry to hear you are having so many issues with using the WLS 9.1 web service Ant tasks, inside of Eclipse.
I generally create a User Library for the couple weblogic jars needed, and use it (the User Library) in my Eclipse projects that I create JWSes in.</i><br>
I also have a separate WebLogic Library in Eclipse (actually 2 libraries since I work with WL 8.1 and now WL 9.1). As you may know, one of the long-standing issues with the Ant integration within Eclipse is the fact that Ant, being an External Tool, does not receive the Project-specific Paths/Libraries. However, since most Java-relevant Ant tasks can take classpath and classpathref attributes, this is usually not an issue. In the case of the BEA-supplied wsdlc Ant task, it is apparent from the verbose/debug console output that wsdlc can see the jars in its classpathref, but it ignores those references when resolving class references and instead only uses the system classpath.
<p>
<i>I've only needed the weblogic.jar and xbean.jar, not all the ones you mentioned in an earlier thread of this post.</i><br>
I have not tried to winnow down exactly which jars are required. I simply included all the jars that exist and were added to the system classpath by the setDomainEnv.bat file created by WebLogic 9.1.
<p>
<i>Afterwards, I create an Ant Builder to build the JWS Web Service EAR, as opposed to fiddlin' with Eclipse.</i><br>
I too use Ant to build my deployable archives. Eclipse is simply my IDE of choice. I validated that all the issues I listed occurred when running Ant from the command line.
<p>
<i>If you are interested in how I do it, send me an e-mail (to [email protected]), and I'll send you a zip of one of these JWS projects. The build.xml script for the project, takes care of a lot of the "annoyances" you mentioned, one of which I think is not accurate. I have never had a situation where the wsdlc Ant task "overwrote" my XXXImpl.java file..</i><br>
Since I'm doing a POC to determine how we want to proceed with developing Web Services and an SOA in general, I tried to perform the same tasks using Axis 2 1.0, the WebLogic 9.1 tools, and XFire 1.1. Overwriting the Impl class is a common failing in the tools which take a WSDL and create Java source files for all three frameworks.
<p>
Try my scenario. Add another operation to an existing WSDL, and run the wsdlc Ant Task. The old IMPL class will be over-written.
<p>
Because of this, I have a separate Impl class and I make sure that all its methods and annotations match the methods and annotations in the Skeleton Impl class created by wsdlc.
<p>
<i>Maybe that's because I use the <exec> Ant task with jar.exe (the xvf options) in my build.xml, to only get what I need out of the .jar/.zip the wsdlc generates. I'm typically only interest in the interface class that my XXXImpl.java file needs to implements, because I use XMLBeans for the input args (and return values) of my web service operations.</i><br>
Perhaps. I am not using XMLBeans in any of the three frameworks because the resulting service seems to be lighter-weight in all three frameworks if XMLBeans is not used. I'm sure there will be scenarios where XMLBeans is preferred, but I have not encountered that case in this POC.
<p>
<i>Regards,
Mike Wooten</i>
Thanks for the follow-up.
Mike McAngus