Jean-Sebastien Delfino wrote:
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?
One more thought, for option (a) we should be able to reuse the SCA
Contribution service to find all the WSDLs and XSDs used in an SCA
contribution (as well as the namespaces imported from other SCA
contributions) to automate the calls to the WSDL2Java and XSD2Java
codegen and generate everything the SCA contribution needs.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
