Scott Kurz wrote:
That 'generate-sdo' only generates the Java types from the schema types,
right?
It's the WSDL2Java which maps portType operations t**o Java methods and
(last I checked) our
W2J is the only tool which knows how to do this with an SDO databinding.
Are the Java Service Endpoint Interfaces generated from WSDL portTypes
when using an SDO databinding different from what JAX-WS would produce
when using a JAXB databinding? Or are the differences confined to the
Java code that's generated for the XSD types referenced in the WSDL?
If possible, it would be good if we could use standard tools to generate
the Java SEIs, and SDO-specific tools for the XSD to Java static SDO
translation.
I'm not sure how useful the SDO-based J2W is, however. There are a lot of
ways to generate a WSDL and
as long as the work Simon Nash is doing to do a J2W at runtime can handle
SDOs it would seem the tool-time
code could be abandoned.
I'd like to get the runtime part working properly before I start
looking at what is needed to make the same functionality available
from the tools. In principle this seems like the right approach,
but it might be quite a lot of work depending on environmental
differences and how much flexibility we want to enable through
different codegen options.
For example, the runtime code introspects the contribution to locate
the XSDs that correspond to SDO static types. At tool time, there
would need to be command-line options to say where to find the XSDs.
Another difference is that the runtime code code works by
introspecting Java classes loaded into the current VM. It is
considered bad practice for tools (e.g., rmic) to work in this
way, because of potential interference between the classes
being processed and the tool's own runtime. As an example,
think of what would happen if a loaded class ran a constructor
that went into a loop, or called System.exit(). Instead, these
tools read class files and generate a "pure data" in-memory
representation of the class information that is then processed.
I suspect there will be a number of such differences. None will
be insoluble, but all will require effort to design and implement.
Simon
On Wed, May 21, 2008 at 10:05 AM, ant elder <[EMAIL PROTECTED]> wrote:
On Wed, May 21, 2008 at 2:53 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:
ant elder wrote:
Do we really need these as they are today? Currently they contain copies
of
various Axis2 classes updated for Tuscany so its not a completely
trivial
upgrade to move to Axis2 1.4 and while looking at that I wondered what
we
really want them for.
The Java2WSDL tool doesn't look like its actually used anywhere by any
of
the Tuscany samples or demos or anything. We have all the new runtime
Java2WSDL code so ideally we'd move to that instead of using all the
patched
Java2WSDL classes. WSDL2Java is only used by one BPEL sample, the other
samples needing that type of thing use the SDO tools directly to gen
Java
classes from XML schema. We've now changed all the runtime to use jaxb
and
jaxws so should we look at using the tools for those instead of the
Axis2
WSDL2Java tool?
Any one have any thoughts?
...ant
Ant,
Whoa there....
:-)
One of the main points of having Tuscany tools in this area is to assist
developers who are having to use WSDL and who want to use SDOs in their
Java
code. If we get rid of the Tuscany tools, how are developers supposed to
handle this?
Handle what exactly is what I'm asking. What are the use cases we want to
support? Looking at the state of the code I'm not sure these tools actually
are working properly today and its not that clear (to me) what it is we
want
them to do anyway. SDO has its own tools for dealing with WSDL which we
use,
eg, look at the bottom of the pom.xml in the wsdl itest [1].
...ant
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/wsdl/pom.xml
