Yang ZHONG wrote:
WSDL has schemas and portTypes.
WSDL2Java uses SDO CodeGen to compute classes names for schemas and
generates classes for portTypes.
SDO code seem not actually generated.
Is that desired?
If not, I can look into how to fix.
If yes, are users supposed to use SDO CodeGen themselves?
If so, what if users specify options causing different code from what
WSDL2Java expects?
How do we enable users to reflect the customization to WSDL2Java?
Yang,
If I remember correctly, the current WSDL2Java tool does not
automatically run XSD2Java for all the inline XSDs or all the XSDs
referenced from the WSDL. Application developers are responsible to run
the WSDL2Java tool or XSD2Java tool on each individual WSDL or XSD file.
On one hand, it would be nice to support a top-down generation from a
WSDL including the closure of all the referenced XSDs. On the other hand
if multiple WSDLs reference common XSDs you probably don't want to
regenerate code for these XSDs multiple times. Also if an application
developer starts to work on an XSD he'll probably want to generate SDOs
from it even before writing a WSDL, then later when he generates a Java
interface from that WSDL, the interface will have to point to these
SDOs... As you noted things will break if incompatible codegen options
are used in XSD2Java and WSDL2Java.
These issues are actually not specific to WSDL, you can run into similar
issues with a graph of XSDs...
We should start a discussion to find the best strategy for this codegen:
a) Handle generation on an SCA contribution basis (basically you don't
gen from individual files but you handle in a single pass ALL relevant
files in the contribution, with consistent codegen options and avoiding
duplicate gen).
b) Or continue with the current approach where the app developer
specifies which files to gen from (including support for "*.wsdl" or
"*.xsd").
c) Or add support for top-down generation of a closure from a WSDL or an
XSD.
d) Or any other scheme...
My preference would be for keeping option (b) and build option (a) on
top of it, but I think it'll help to look at how existing similar tools
are handling this:
How does the current XSD2Java tool handle this? What does it do when you
give it an a.xsd containing an <import/> of another b.xsd? Does it
generate code only for a.xsd? or for both a.xsd and b.xsd?
What about the JAXWS tools?
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
