Dims--
Good point -- I'm trying to avoid generating too many .java files in
the pure-Axis case as we'll need lots of flies for JAX-RPC.
Using the .wsdd file appealed to me because it's really *simple* and
easy to debug. I think I also figured out how to use them to pass
headers to web service methods as parameters using the attributes on the
<parameter> element.
I'll give .wsdd generation a shot and see how it works. Maybe we'll
even have something new to talk about at ApacheCon. ;)
Eddie
Davanum Srinivas wrote:
That would indeed work fine. Another option is to try the --helperGen
option in wsdl2java. it can create _Helper.java for each bean (and
that contains the metadata).
thanks,
dims
On 12/7/05, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
All--
I've been doing a bit of digging into Axis to look at how we're
wiring up an Axis SOAPService from an annotated Java file. The
process basically works like this:
build-time:
- check annotations
- generate JavaBean model of the service
- serialize JavaBean model into .ser files available in an
application's classloader
runtime:
- load .ser files and convert into JavaBeans
- convert JavaBean model into a SOAPService
- load SOAPService into Axis
While this generally works, Axis already has the .wsdd mechanism for
being able to define the "shape" of a service from an annotated Java
source file. WSM could simply generate the .wsdd files at build time
and then those files would contain the operations, parameters, type
serializer / deserializers, etc that are needed to execute a service
in Axis.
Seems like this would be simpler than a lot of the code that exists
today to convert a .ser JavaBean into a SOAPService. It doesn't
provide a quick iterative development experience, but personally, I'm
more concerned with obtaining JSR-181 compliance and adding features
second.
We need to ship this thing. ;)
Thoughts? Dims / Ias, know of any reason why this wouldn't work?
Thanks for any input.
Eddie
--
Davanum Srinivas : http://wso2.com/blogs/
