During last months, we’ve been working to provide our customers with webservices with attachments. JBossWS currently (v.1.0.3) supports both SwA and MTOM+XOP although only the first one was available in earliest releases. For this reason, we started some month ago with SwA, then we added a new webservice endpoint with MTOM+XOP in RPC style. Finally, a couple of weeks ago some customers asked us to provide them with a Doc/Lit style endpoint in order to better support interoperability with Microsoft webservice clients. Considering that Document/Literal is the way to go for future webservices and that official JBossWS mtom samples are rpc-only, the process required to get your wonderfull doc/lit mtom endpoint may be interesting to be blogged
As long as JBossWS wstools.sh utility doesn’t generate correct artifacts when ran in java2wsdl mode on classes containing javax.activation.DataHandler instances, you have to do something like this:

1. prepare a copy of your source file removing any reference to DataHandler from the enpoint interface and/or any data transfer object it contains
2. prepare a wstools-config.xml: do not forget to set style=”document”. If your enpoint methods contain at most one parameter each, prefer setting parameter-style=”bare” since this will make you work easier on the following steps
3. run wstools.sh on the modified sources: this will generate the wsdl, jaxrpc-mapping.xml, webservices.xml and eventually some classes
4. manually modify the wsdl/xml artifacts to enable attachments: this is the most critical phase and the most boring one…
   • import xmime namespace in wsdl
     <import schemaLocation="http://www.w3.org/2005/05/xmlmime" namespace="http://www.w3.org/2005/05/xmlmime"/>
   • add/change elements for the attachments in the right point of your schema in the wsdl
     <element name='attachment' type='xmime:base64Binary' xmime:expectedContentTypes='*/*'/>
   • fix in/out method-param-parts-mappings and variable-mappings in jaxrpc-mapping.xml if required or whether you previously choose wrapped parameter style.
5. restore your original source files (with DataHandler instances)
6. eventually merge the webservices.xml obtained from wstools.sh with the one you already have for other endpoints: beware of “impl” namespaces references that of course are different for each endpoints
7. build your project and look at the server.log on the console

Of course you can skip wstools.sh usage and simply manually write your artifacts considering you have to put your hands on them in any case… however I found this way very usefull since our schema is quite huge (wstools.sh saved me a lot of time… and bug hunt/fix).
Hope this post will help someone; anyway if you know a better, faster, etc way to achieve the same result before JBossWS 2.0 become available (http://jira.jboss.org/jira/browse/JBWS-1155)… feel free to post a comment below.

We just made a patch for jbossws implementing two features:

1. The max expiration time and the default expiration time are hard coded in source code. Our patch made these values configurable in SubscriptionManager MBEAN
2. We noticed jbossws throws an InvalideExpirationTime Excetion when we try to subscribe with an expiration time longer than maxLeaseTime. According to specification (5.4) this exception should be used only when the expiration time is in the past or the expiration duration is zero. It should answer with a valid registration forcing expiration time to maxLeaseTime (Specification 3.1).

Problems was discovered and reported by Alessio in this user’s forum post:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=90201

and briefly discussed by me in this design’s forum post:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92340

You can find the patch (over jbossws-1.0.3.SP1 from jbossws svn) here or on jira:
http://jira.jboss.org/jira/browse/JBWS-1290