Doug,
yes, I *think* that I'm clear about the use of -import (wscompile) in
conjunction with the model parameter in jaxrpc-ri.xml (wsdeploy), which
doesn't not affect the generation of stubs for the client (no problem
using -gen:client against the use of -gen:server). For that acknowledge
I must express my gratitude to you.
Unfortunately, it raised another problem about the dynamic generation of
classes from a WSDL file.
Im my first and old approach (interface->WSDL) I have my interface with
a method which has a java.util.Date attribute in the signature method
that was mapped to a "datetime" type in WSDL. Now, I have a WSDL file
that in wsdeploy process creates a java.util.Calendar java object, which
will result at run-time say that cannot instantiate a Abstract Class
(java.util.Calendar) when I run a client invocation! Probably due the
default constructor politics assumed in RMI for JAXRPC in the Calendar
java object:
"
To be supported by JAX-RPC, an application class must conform to the
following rules:
* It must have a public default constructor.
* It must not implement (either directly or indirectly) the
java.rmi.Remote interface.
* Its fields must be supported JAX-RPC types.
The class may contain public, private, or protected fields. For its
value to be passed (or returned) during a remote call, a field must meet
these requirements:
* A public field cannot be final or transient.
* A non-public field must have corresponding getter and setter
methods.
"
If I force to my parameter be a java.util.Date in my service interface I
will get an error in wsdeploy saying that it cannot cast java.util.Date
to java.util.Calendar! I'm thinking in editing the generated sources to
get a date instead the calendar itself but I don't know if it will work
(well I will try if I can do it).
Could you assist me on that? I will post a message on that in jaxrpc
list too.
thanks,
Pedro Salazar.
On Fri, 2003-01-10 at 17:13, Doug Kohlert wrote:
> Pedro, what you did will not work because when you did the -gen:server
> it should have generated a new service endpoint interface and new
> value type classes used by that interface, it also should have created
> a stubbed out implementation class. You cannot simply replace that
> service endpoint interface with your own or use your own implementation,
> unless your service endpoint interfaces uses the exact value types generated
> by wscompile. This is because the generated serializers will try to
> create the generated value types, not yours.
>
> However, if what you did would work, what you need to do in step 2) below
> is to use the -model modelfile option on wscompile to create a model file.
> Then you modify the jaxrpc-ri.xml file you pass to wsdeploy to include a
> "model" attribute that specifies this file. Make sure to include the new
> model file in the war you pass to wsdeploy. If you specify a "model" attribute
> on the endpoint in the jaxrpc-ri.xml file, then wsdeploy will not regenerate
> the WSDL with bad parameter names etc.
>