using WSEE doclet

[dhartford]

Finally, some success!
Pure WSEE doclet webservice without WSCompile. It uses RPC/Literal, but hopefully more support can be added for the other types.

The one missing piece was ejb-jar.xml gets generated but is missing this under < session > and needs to be added manually with xdoclet-1.2.3 [for this example]:
<service-endpoint>com.mycomp.session.interfaces.DataViewEndpoint</service-endpoint>

Bean:
/** This Session Bean is used for Session.
 * @ejb:bean name="com.mycomp.session.ejb.DataView"
 * type="Stateless"
 * transaction-type="Container"
 * display-name="DataView"
 * jndi-name="com.mycomp.session.interfaces.DataViewHome"
 * local-jndi-name="com.mycomp.session.interfaces.DataViewLocalHome"
 * view-type="all"
 *
 * @ejb-transaction="Supports"
 * @ejb:util
 * generate="physical"
 *
 *
 * @ejb.interface
 * service-endpoint-class="com.mycomp.session.interfaces.DataViewEndpoint"
 *
 * @wsee.port-component
 * name="DataViewEndpoint"
 * service-endpoint-interace="com.mycomp.session.interfaces.DataViewEndpoint"
 * service-endpoint-bean="com.mycomp.session.ejb.DataView"
 *
 * @wsee.jaxrpc-mapping
 * root-type-qname="DataViewEndpoint"
 */

maven.xml (easy to change to build.xml for ant):

<goal name="xdoclet:ejb">
 <taskdef name="ejbdoclet" classname="xdoclet.modules.ejb.EjbDocletTask">
 <classpath>
 <path refid="maven.dependency.classpath"/>
 </classpath>
 </taskdef>
 <taskdef name="wseedoclet" classname="xdoclet.modules.wsee.WseeDocletTask">
 <classpath>
 <path refid="maven.dependency.classpath"/>
 </classpath>
 </taskdef>
 <ejbdoclet
 destdir="${basedir}/generated/java"
 excludedtags="@version,@author,@todo"
 ejbspec="2.0"
 verbose="true"
 mergedir="${basedir}/src/mergedir" >


 <fileset dir="src/java">
 <include name="**/*Bean.java" />
 </fileset>

 <packageSubstitution packages="ejb" substituteWith="interfaces"/>

 <!--add entitypk only for generating compound pk-->
 <entitypk/>
 <homeinterface/>
 <localhomeinterface/>
 <remoteinterface/>
 <localinterface/>
 <utilobject cacheHomes="true" kind="both"/>
 <entitycmp/>

 <service-endpoint/>
 <valueobject/>
 <session/>

 <deploymentdescriptor
 destdir="${basedir}/target/classes/META-INF"
 mergedir="${basedir}/src/mergedir"
 validatexml="false"
 />
 <jboss
 version="4.0"
 unauthenticatedPrincipal="nobody"
 xmlencoding="UTF-8"
 destdir="${basedir}/target/classes/META-INF"
 mergedir="${basedir}/src/mergedir"
 validatexml="false"
 />
 </ejbdoclet>


<wseedoclet destDir="${basedir}/target/classes/META-INF"
 jaxrpcMappingFile="jaxrpc-mapping.xml"
 wseeSpec="1.1"
 verbose="true"
 force="true" >


 <fileset dir="src/java">
 <include name="**/*Bean.java" />
 </fileset>

 <jaxrpc-mapping/>
 <wsdl/>
 <deploymentdescriptor/>
</wseedoclet>

 </goal>

Jboss still prefers WSCOMPILE, just sharing my experience with anyone else who may be interested.

[adammeghji]

If your service endpoint isn't getting added to your ejb-jar.xml, make sure you're:
- building a deployment descriptor with ejbSpec="2.1"
- add this to your session bean:
@ejb.interface service-endpoint-class="arm.carrier.interfaces.CarrierFacadeService"

I was manually doing merges until I did this, and it started adding the service endpoint tag to ejb-jar.xml

Hope this helps!

[jason.greene]

Thanks for contributing this to the community, but keep in mind that a jaxrpc-mapping file is very important to make complex types map correctly. Until this file is generated as well, I still recommend that everyone use wscompile.

Also, eventually Java 5 annotations will be replacing xdoclet, and the new stack we are developing supports JSR181 (webservice) annotations.

-Jason

[dhartford]

bingo - just changing to ejb 2.1 fixed the service-endpoint in the ejb-jar.xml!

So using WSEEdoclet (with ejbdoclet) can:

*Generate ejb-jar.xml (with service-endpoint defined).
*Generate the actual *Endpoint.java files.
*Generate a reasonable webservices.xml file.

WSEE can also do:
*create basic RPC-Literal META-INF/wsdl/*.wsdl files.
*create simple jaxrpc-mapping.xml files.

The WSDL and the JAXRPC-MAPPING.XML files are the next step to find a better solution.

-Be able to automatically handle complex types (Array of entity bean ValueObjects is a good testcase).
-Move towards WS-Basic-Profile-1.0 compliance (if needed?).

Now I feel comfortable looking at WSCOMPILE, WSDL4J, and similar tools for the WSDL files and the JAXRPC mapping.

[dhartford]

Also, eventually Java 5 annotations will be replacing xdoclet, and the new stack we are developing supports JSR181 (webservice) annotations.

Yes, I'm looking forward to those!

But, there are still projects that need to stick with J2EE 1.4! I'm trying to find the (hopefully) mature tools and solutions to make the webservices piece as easy (and compliant) as possible.

[jason.greene]

Also, just so you know we are also developing a set of webservice tools that will replace wscompile.

One other option you may want to consider, is using the xdoclet tasks to generate everything but the wsdl files, and the jaxrpc-mapping files, and then invoking wscompile from ant. There are only a few jars in the jwsdp that you need to do this. Also, you could enhance the wsee doclet to call out to wscompile (maybee via some kind of plugin system due to licensing restrictions).

If you have an interest in our tools project, you can see all of the tasks, and issues here (should you desire to contribute):
http://jira.jboss.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=12310050&fixfor=12310307

-Jason

[dhartford]

Thanks for the info Jason!

I did download jboss-4 branch and jboss-head branch to see if I could find the jbossWS tools, but without much luck. Where are they located?

[jason.greene]

They are in head at the moment. Checkout jboss-head instead of jboss-4.0. They will eventually be backported, and most likely released as a seperate package.

The tests for tools (and the new webservices stack) are currently located in jboss-head/webservice/test.

The build process is the same, but to run the tests you need to cd into the test directory and run ../../tools/bin/ant tests (or your own version of ant, as long as it has the proper libs).

Also we have both the old a new stacks in head, and currently the old is the default, so to use the new stack, you will need to cd into the webservice directory and run sh build.sh deploy-jbossws. The test is smart enough to complain if you skip this step, so don't worry if you forget.

Also, for design and development discussions relating to tools, and the new webservices stack we have a low traffic "Design of JBoss's Web Services Implementation" forum.

-Jason

[dhartford]

Update:

For generating the entity beans, if you use EJBDoclet make sure to use version XDOCLET-1.2.2! xdoclet-1.2.3 has a new getReadOnly*ValueObject methods that breaks the BeanSerializer. There does not seem to be an option yet to disable this method in ejbdoclet.

Working on WSCOMPILE for a better WSDL and jaxrpc-mapping.xml file - so far:

Required libs in classpath:

 <dependency>
 <groupId>jwsdp</groupId>
 <artifactId>jaxrpc-spi</artifactId>
 <version>jwsdp16</version>
 <type>jar</type>
 </dependency>
 <dependency>
 <groupId>jwsdp</groupId>
 <artifactId>jaxrpc-impl</artifactId>
 <version>jwsdp16</version>
 <type>jar</type>
 </dependency>
 <dependency>
 <groupId>jwsdp</groupId>
 <artifactId>jaxrpc-api</artifactId>
 <version>jwsdp16</version>
 <type>jar</type>
 </dependency>
 <dependency>
 <groupId>jwsdp</groupId>
 <artifactId>xsdlib</artifactId>
 <version>jwsdp16</version>
 <type>jar</type>
 </dependency>
 <dependency>
 <groupId>jwsdp</groupId>
 <artifactId>namespace</artifactId>
 <version>jwsdp16</version>
 <type>jar</type>
 </dependency>
 <dependency>
 <groupId>jwsdp</groupId>
 <artifactId>relaxngDatatype</artifactId>
 <version>jwsdp16</version>
 <type>jar</type>
 </dependency>
 <dependency>
 <groupId>jwsdp</groupId>
 <artifactId>jax-qname</artifactId>
 <version>jwsdp16</version>
 <type>jar</type>
 </dependency>

Setting up the build/maven.xml task. NOTE-run this after WSEEDoclet and compiling the classes:

<goal name="wscompile">
 <taskdef name="wscompile" classname="com.sun.xml.rpc.tools.ant.Wscompile">
 <classpath>
 <path refid="maven.dependency.classpath"/>
 </classpath>
 </taskdef>

 <!--generate server-side WSDL -->

 <wscompile
 fork="true"
 define="true"
 classpath="target/classes"
 nonClassDir="target/classes/META-INF/wsdl"
 features="documentliteral, wsi"
 config="DataViewconfig.xml"
 mapping="target/classes/META-INF/jaxrpc-mapping.xml"
 >
 <classpath>
 <path refid="maven.dependency.classpath"/>
 </classpath>

 </wscompile>

</goal>

<!-- you can comment out the < wsdl /> and < jaxrpc /> flags in WSEEDOCLET now -->

Configure DataViewconfig.xml for WSCOMPILE (by hand, yuck :-P)

<configuration xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
 <service name="DataViewEndpoint"
 targetNamespace="http://mycomp.com/wsdl"
 typeNamespace="http://mycomp.com/types"
 packageName="com.mycomp">
 <interface
 name="com.mycomp.session.interfaces.DataViewEndpoint"
 >
 </interface>
 </service>
</configuration>

Moving closer...I want to take advantage of the BeanSerializer to avoid creating custom handlers. Following the premise that I will be using ValueObject/Beans that only have properties/fields that are valid for the BeanSerializer. DocumentLiteral seems to be the right direction for this, but getting ClassNotFound when trying to find the _ResponseStructs.

[dhartford]

Question on _ResponseStructs - is this something that is/could be generated from the BeanSerializer or some other tool?

On deploy, getting 'ClassNotFound' for these _ResponseStructs.

[dhartford]

Change:

On the WSCOMPILE task, switched from:

features="documentliteral"
to:
features="rpcliteral"

This seems to be working better, and actually have single ValueObject beans going back and forth fine.

However, Arrays of ValueObject beans is NOT working, which was what held me back last time and made me look at documentliteral.

Any recommendations? (these are ValueObject[], not a Collection)

[thomas.diesler]

If you want to protect your investment, focus on standard web service annotations as defined in JSR-181. This already works in HEAD (jboss-5.0.0alpha)

XDoclet is a deprecated technology.

The Request/Response structures are the wrapper types wscompile generates arround doc/lit parameters. Remember, with document style web services only a single complex type that is completely defined in schema is marshalled as the request/response message

[dhartford]

If you want to protect your investment, focus on standard web service annotations as defined in JSR-181. This already works in HEAD (jboss-5.0.0alpha)

Thanks, I guess I'm concerned about tools support when jumping too far ahead. When will Jboss5 with annotations be supported with Eclipse WTP as a 'server' (assuming Jboss-IDE is not actually released with this support in the near future), or with JavaStudioCreator2 for JSF w/EJB?

These aren't ancillary or obscure tools either, these are core pieces used to assist in business software development. Both of these as examples and many others still only supporting jboss3 and have not even caught up with jboss4 yet :-(

p.s. yes, Eclipse WTP will soon support jboss4, but as of M5 it still did not.

[rlj]

Hi There

I've done as described in this post, but when I run Maven I get this error:

[wscompile] error: -mapping is an invalid option or argument

I've verbose="true" in my which gives me the command actually run in the console-output. If I run this command on a "normal" commandline I don't get this mapping-error.

This is my :

 <wscompile
 keep="true"
 client="false"
 server="true"
 xPrintStackTrace="true"
 xSerializable="true"
 verbose="true"
 classpath="${maven.dependency.classpath}"
 features="rpcliteral"
 mapping="${maven.build.dir}/META-INF/jaxrpc-mapping.xml"
 config="${maven.wscompile.config}"
 >
 <classpath>
 <path refid="maven.dependency.classpath"/>
 <pathelement path="${maven.build.dir}/classes"/>
 </classpath>
 </wscompile>

maven.wscompile.config is set to point on my config-file in the properties-file.

[dhartford]

I don't quite remember, but I do recall some of the issues were resolved with WSCOMPILE when you used fork="true".