Jean-Sebastien Delfino wrote:
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.
It seems to me that different usecases apply. It should be possible
just to point the tool at some remote WSDL / XSD and generate the
required Java files locally, without needing to download the WSDL and
XSDs. One of the points of convenience here is that the Java programmer
wants as little to do with the WSDL and XSDs as possible - what they are
really after are the Java interface files and the SDOs - those are what
they will work with. Ideally they DONT want the WSDL and XSDs in their
contributions.
So an option (at least) should allow the user to request that the tool
follows all links and generates all the target entities. Another option
should allow for "bulk creation" - ie a run against not just a single
file but a whole series of them - and that the tool should only gen each
target once for the whole run (ie spot when the same WSDL or XSD is
processed more than once....).
It seems reasonable to allow just a single file to be processed, but I
doubt whether that is what I would want as a default.
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
