Generating versus reusing classes for parameters

[Benson Margulies <bi...@gmail.com>]

I am working on an overall application in which I control both the client
and the server. So, I'd like to just use some preexisting bean-pattern
classes and enums as parameters to a JAX-WS service, where these classes
will be available in the classpath on both sides.

I suppose that it would be harmless to handle the SEI the same way.

This leads to the following question: would I still need to run wsdl2java at
all, and, if so, with what options? To be more specific, if I am using
<jaxws:client/> in Spring to configure the client proxy, will it work if the
very same classes, with the same annotations, are present in the classpath
on the client side?

If, for some reason, I wanted to do this with just some classes, and still
use generated code for the SEI or other things, then what happens? Is there
some way to configure wsdl2java?

Re: Generating versus reusing classes for parameters

[Daniel Kulp <dk...@apache.org>]

On Saturday 14 August 2010 4:12:34 pm Benson Margulies wrote:
> I am working on an overall application in which I control both the client
> and the server. So, I'd like to just use some preexisting bean-pattern
> classes and enums as parameters to a JAX-WS service, where these classes
> will be available in the classpath on both sides.
> 
> I suppose that it would be harmless to handle the SEI the same way.
> 
> This leads to the following question: would I still need to run wsdl2java
> at all, and, if so, with what options? To be more specific, if I am using
> <jaxws:client/> in Spring to configure the client proxy, will it work if
> the very same classes, with the same annotations, are present in the
> classpath on the client side?

In almost all cases, yes.   For the most part, if an SEI is well defined with 
all the needed annotations and the param beans are also defined properly, 
there is no need to do wsdl2java on anything.

> If, for some reason, I wanted to do this with just some classes, and still
> use generated code for the SEI or other things, then what happens? Is there
> some way to configure wsdl2java?

There are some jaxb binding things that you can use to map a namespace into a 
pregenerated package and then specify a  map="false" option to 
jaxb:schemaBindings binding element.   See section 7.6 of the JAXB spec.   In 
general, it's not easy to do and fairly error prone.  I would suggest just not 
running the wsdl2java thing.  :-)

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Generating versus reusing classes for parameters

[Benson Margulies <bi...@gmail.com>]

Um, one more query added to the end ...

On Sat, Aug 14, 2010 at 4:12 PM, Benson Margulies <bi...@gmail.com>wrote:

> I am working on an overall application in which I control both the client
> and the server. So, I'd like to just use some preexisting bean-pattern
> classes and enums as parameters to a JAX-WS service, where these classes
> will be available in the classpath on both sides.
>
> I suppose that it would be harmless to handle the SEI the same way.
>
> This leads to the following question: would I still need to run wsdl2java
> at all, and, if so, with what options? To be more specific, if I am using
> <jaxws:client/> in Spring to configure the client proxy, will it work if the
> very same classes, with the same annotations, are present in the classpath
> on the client side?
>
> If, for some reason, I wanted to do this with just some classes, and still
> use generated code for the SEI or other things, then what happens? Is there
> some way to configure wsdl2java?
>

I forgot to start at the beginning. I have a class that I use as a parameter
to an SEI. One of its elements is an enum from elsewhere in my code base.
There are no annotations on the enum, and no package-info.java in it's JAR.

When wsdl2java sees this, it creates a brand new enum, not a reference to
the existing one. How would I avoid that?