You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2008/05/21 15:26:06 UTC
Tuscany Java2WSDL and WSDL2Java tools
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
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by ant elder <an...@gmail.com>.
On Thu, May 22, 2008 at 9:03 AM, Simon Nash <na...@apache.org> wrote:
> ant elder wrote:
>
>> On Wed, May 21, 2008 at 7:47 PM, Simon Nash <na...@apache.org> wrote:
>>
>> 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.
>>>
>>>
>> One extra thing an SCA specific tool does need to do is to add the
>> org.osoa.sca.Remotable annotation to the SEI. Maybe that could be done
>> with
>> a simple post processor?
>>
>> ...ant
>>
>> According to the SCA Java spec, @WebService implies @Remotable
> (see chapter 9 of JavaCAA), so this may not be an issue.
>
>
For the benifit of those hunting for that its also in the errata for the 1.0
spec, item 12 at
http://www.osoa.org/display/Main/Errata+for+Java+Annotations+and+APIs+V1.00
...ant
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
> On Wed, May 21, 2008 at 7:47 PM, Simon Nash <na...@apache.org> wrote:
>
>> 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.
>>
>
> One extra thing an SCA specific tool does need to do is to add the
> org.osoa.sca.Remotable annotation to the SEI. Maybe that could be done with
> a simple post processor?
>
> ...ant
>
According to the SCA Java spec, @WebService implies @Remotable
(see chapter 9 of JavaCAA), so this may not be an issue.
Simon
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by ant elder <an...@gmail.com>.
On Wed, May 21, 2008 at 7:47 PM, Simon Nash <na...@apache.org> wrote:
> 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.
>
One extra thing an SCA specific tool does need to do is to add the
org.osoa.sca.Remotable annotation to the SEI. Maybe that could be done with
a simple post processor?
...ant
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by Simon Nash <na...@apache.org>.
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 <an...@gmail.com> wrote:
>
>> On Wed, May 21, 2008 at 2:53 PM, Mike Edwards <
>> mike.edwards.inglenook@gmail.com> 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
>>
>
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by kelvin goodson <kg...@thegoodsons.org.uk>.
2008/5/22 ant elder <an...@apache.org>:
> On Thu, May 22, 2008 at 9:31 AM, ant elder <an...@apache.org> wrote:
>
> >
> >
> > On Wed, May 21, 2008 at 5:03 PM, Scott Kurz <sc...@gmail.com> 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.
> >>
> >
> > Yes after playing around with the tools i think thats right. It looks
> like
> > the current Tuscany/SCA W2J tool generates just a service interface but
> not
> > the types for the operation arguments, and that interface is annotated
> with
> > the osoa @Service and @Remotable annotataions. So to use that interface
> you
> > must use another tool to generate the Java classes for the types (and
> hope
> > that both tools generate identical names for the types) otherwise the W2J
> > generated interface wont even compile.
> >
> > ...ant
> >
> >
> Given the above what would people think about abandoning our Tuscany/SCA
> Axis2 base W2J tool and just updating the SDO tool to support generating
> the
> SEI class?
I think this may not be directly relevant, since from what I can work out
the additional function you are discussing would be a bolt-on addition to
the SDO Java generator, but here's a quick heads up to anyone who might be
thinking of changing the SDO Java generator. You will need skills in
JavaJet (uses a JSP like syntax). There's an FAQ on how to get Eclipse set
up to modify the JavaJet here [1]
To give you a flavour, the JavaJet input files for the generator are here
[2], which generates java code [3], and that generated java code itself is
used to generate the end users generated java classes.
Kelvin.
[1] http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.html
[2]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/tools/templates/models/
[3]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/templates/model/
> So for example the helloworld bpel sample where both of these are
> used at at the bottom of the pom.xml [1] would have the
> tuscany-maven-wsdl2java plugin removed and an extra parameter added to the
> tuscany-sdo-plugin like <generateSEI>true</generateSEI>?
>
> The generateSEI parameter would only be available when the sdo plugin is
> using a wsdl document and although the generated interface would have the
> SCA @Service and @Remotable annotations as they're just strings it wouldn't
> drag in any sca dependencies to sdo, the sca jar would only be needed when
> you actually compile the generated interface.
>
> ...ant
>
> [1]
>
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-bpel/pom.xml
>
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by Scott Kurz <sc...@gmail.com>.
Maybe others are taking this for granted, but I think it would help to get
clear on why exactly we need a Tuscany SEI2WSDL/WSDL2SEI toolset, as opposed
to, say, leveraging and extending something like the CXF toolset.
I can see these arguments:
A) There are SCA-specific aspects of the artifacts to deal with and other
tools are not extensible enough.
Example: A SEI2WSDL tool should handle the SCA @OneWay in addition to
the JAX-WS @Oneway
B) The databinding extensibility/pluggability mechanims in other toolsets
(CXF) are not flexible/robust enough. (We certainly know this is true of
JAXWS RI).
C) We care about more than just Java as the SEI, but others don't?
D) We want to provide a tool-time mapping which matches our runtime
mapping.
------------------------------------------------------------------------------
I'm not familiar enough w/ other tools to argue A) or B), but I'm assuming
that D) is the most important reason for most people.
While it does seem inefficient for every Apache WS-related project to have
to implement all the JAX-WS rules from scratch, and while we might hope that
any tool "following the spec (JAXWS)" (plus whatever databinding
introspection rules Tuscany establishes) should work.... we want to have a
single tool that we have control of as a project.
If we take, for example, the time not too long ago where we debated an
aspect of the rules for calculating that a WSDL was doc-lit-wrapped, it
would help to have a single tool that for certain shared the same
interpretation as the runtime.
-----
Before we go writing code to support all the JAX-WS WSDL customizations,
have we agreed that this is why we are doing this?
Scott
On Fri, May 23, 2008 at 5:23 AM, ant elder <an...@apache.org> wrote:
> On Thu, May 22, 2008 at 6:02 PM, Raymond Feng <en...@gmail.com> wrote:
>
> <snip>
>
> Anyway, so would we be committing to doing this in time for the next
> >> release? If so I can stop looking at upgrading the exsiting tools to
> work
> >> with Axis2 1.4. Or is this just "something to look at in the furture"
> and
> >> I
> >> still need to get the existing tools running with Axis2 1.4 in time for
> >> our
> >> next SCA release?
> >>
> >
> > Effort wise, which approach requires more? We need to make a good balance
> > here. If the migration to 1.4 is an one-day work, then I think it's worth
> to
> > migrate it 1st to have a working base.
> >
> >
> Its not just about getting the old tool working again though - the current
> tool code produces different wsdl than what the runtime does and it will
> get
> even more different as we switch to the new runtime wsdl generation code,
> and AFAICT we have nothing that uses the current tool, no doc on how to use
> it, and no testcases. Yes writing a new tool based on the new runtime wsdl
> generation code is more effort but isn't that inevertably going to happen
> so
> spending any more time on the old tool code a bit redundant?
>
> ...ant
>
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by ant elder <an...@apache.org>.
On Thu, May 22, 2008 at 6:02 PM, Raymond Feng <en...@gmail.com> wrote:
<snip>
Anyway, so would we be committing to doing this in time for the next
>> release? If so I can stop looking at upgrading the exsiting tools to work
>> with Axis2 1.4. Or is this just "something to look at in the furture" and
>> I
>> still need to get the existing tools running with Axis2 1.4 in time for
>> our
>> next SCA release?
>>
>
> Effort wise, which approach requires more? We need to make a good balance
> here. If the migration to 1.4 is an one-day work, then I think it's worth to
> migrate it 1st to have a working base.
>
>
Its not just about getting the old tool working again though - the current
tool code produces different wsdl than what the runtime does and it will get
even more different as we switch to the new runtime wsdl generation code,
and AFAICT we have nothing that uses the current tool, no doc on how to use
it, and no testcases. Yes writing a new tool based on the new runtime wsdl
generation code is more effort but isn't that inevertably going to happen so
spending any more time on the old tool code a bit redundant?
...ant
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Thursday, May 22, 2008 9:36 AM
To: "tuscany-dev" <tu...@ws.apache.org>
Subject: Re: Tuscany Java2WSDL and WSDL2Java tools
> On Thu, May 22, 2008 at 5:04 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> Hi,
>>
>> The SCA spec says that we follow the JAXWS rules to map between remotable
>> java interfaces and WSDL port types. There are two things involved:
>>
>> 1) WSDL portType <--> Java Interface (JAXWS)
>> 2) XSD <--> Java Types (Databinding specific)
>>
>> Ideally, the JAXWS WSDL2Java/Java2WSDL tools shouold allow different
>> databindings to be plugged in to handle the XSD2Java/Java2XSD
>> generations.
>> Unfortunately, the JAXWS RI wsimport/wsgen tool doesn't have the
>> pluggability yet to add SDO support.
>>
>> An alternative is that we develop/use a tool to only generate artifacts
>> for
>> 1 (I don't see an option for the JAXWS wsimport/wsgen tool to disable the
>> XSD handling either) and use databinding-specific Java/XSD code gen. I
>> think
>> the only connection between the two tools are the package <--> namespace
>> mapping rules.
>>
>> Based on the above, I don't think we should add generateSEI to SDO.
>> Instead, we should have SEI2WSDL and WSDL2SEI tools in SCA.
>>
>>
> I've a lot of sympathy with that approach...though it is a bit more work
> :)
>
Great.
> WSDL2SEI is what we have right now with tools/wsdl2java as it cuts out
> generation of eveything other than the SEI class, but to do that it uses
> and
> copies code from the Axis2 WSDL2Java tool, is the suggestion to stop using
> any Axis2 code and write our own SEI generator?
How complex is the logic to generate a java interface out of a WSDL
portType? What are the main Axis2 code dependencies (is the code fairly
isolated)?
The following is list of items I see:
portType QName --> Java interface name
operation name --> method name
part element/type --> argument/return name and type (following the mapping
rules by the pluggable databinding for XSD type --> Java type,we can use
JAXB as the default)
fault --> exception
>
> The SEI2WSDL tool would be based on the new code we have for runtime WSDL
> generation right? Not completely convinced about "SEI" in the name, people
> know what Java2WSDL does so does keeping on calling our tool Java2WSDL
> really hurt?
I just use "SEI" as an example to differentiate the traditional J2W. I can
live with J2W. If possible, we should leverage the new code for runtime WSDL
generation.
>
> Anyway, so would we be committing to doing this in time for the next
> release? If so I can stop looking at upgrading the exsiting tools to work
> with Axis2 1.4. Or is this just "something to look at in the furture" and
> I
> still need to get the existing tools running with Axis2 1.4 in time for
> our
> next SCA release?
Effort wise, which approach requires more? We need to make a good balance
here. If the migration to 1.4 is an one-day work, then I think it's worth to
migrate it 1st to have a working base.
>
> ...ant
>
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by ant elder <an...@gmail.com>.
On Thu, May 22, 2008 at 5:04 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> The SCA spec says that we follow the JAXWS rules to map between remotable
> java interfaces and WSDL port types. There are two things involved:
>
> 1) WSDL portType <--> Java Interface (JAXWS)
> 2) XSD <--> Java Types (Databinding specific)
>
> Ideally, the JAXWS WSDL2Java/Java2WSDL tools shouold allow different
> databindings to be plugged in to handle the XSD2Java/Java2XSD generations.
> Unfortunately, the JAXWS RI wsimport/wsgen tool doesn't have the
> pluggability yet to add SDO support.
>
> An alternative is that we develop/use a tool to only generate artifacts for
> 1 (I don't see an option for the JAXWS wsimport/wsgen tool to disable the
> XSD handling either) and use databinding-specific Java/XSD code gen. I think
> the only connection between the two tools are the package <--> namespace
> mapping rules.
>
> Based on the above, I don't think we should add generateSEI to SDO.
> Instead, we should have SEI2WSDL and WSDL2SEI tools in SCA.
>
>
I've a lot of sympathy with that approach...though it is a bit more work :)
WSDL2SEI is what we have right now with tools/wsdl2java as it cuts out
generation of eveything other than the SEI class, but to do that it uses and
copies code from the Axis2 WSDL2Java tool, is the suggestion to stop using
any Axis2 code and write our own SEI generator?
The SEI2WSDL tool would be based on the new code we have for runtime WSDL
generation right? Not completely convinced about "SEI" in the name, people
know what Java2WSDL does so does keeping on calling our tool Java2WSDL
really hurt?
Anyway, so would we be committing to doing this in time for the next
release? If so I can stop looking at upgrading the exsiting tools to work
with Axis2 1.4. Or is this just "something to look at in the furture" and I
still need to get the existing tools running with Axis2 1.4 in time for our
next SCA release?
...ant
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by Raymond Feng <en...@gmail.com>.
Hi,
The SCA spec says that we follow the JAXWS rules to map between remotable
java interfaces and WSDL port types. There are two things involved:
1) WSDL portType <--> Java Interface (JAXWS)
2) XSD <--> Java Types (Databinding specific)
Ideally, the JAXWS WSDL2Java/Java2WSDL tools shouold allow different
databindings to be plugged in to handle the XSD2Java/Java2XSD generations.
Unfortunately, the JAXWS RI wsimport/wsgen tool doesn't have the
pluggability yet to add SDO support.
An alternative is that we develop/use a tool to only generate artifacts for
1 (I don't see an option for the JAXWS wsimport/wsgen tool to disable the
XSD handling either) and use databinding-specific Java/XSD code gen. I think
the only connection between the two tools are the package <--> namespace
mapping rules.
Based on the above, I don't think we should add generateSEI to SDO. Instead,
we should have SEI2WSDL and WSDL2SEI tools in SCA.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Thursday, May 22, 2008 2:52 AM
To: "tuscany-dev" <tu...@ws.apache.org>
Subject: Re: Tuscany Java2WSDL and WSDL2Java tools
> On Thu, May 22, 2008 at 9:31 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Wed, May 21, 2008 at 5:03 PM, Scott Kurz <sc...@gmail.com> 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.
>>>
>>
>> Yes after playing around with the tools i think thats right. It looks
>> like
>> the current Tuscany/SCA W2J tool generates just a service interface but
>> not
>> the types for the operation arguments, and that interface is annotated
>> with
>> the osoa @Service and @Remotable annotataions. So to use that interface
>> you
>> must use another tool to generate the Java classes for the types (and
>> hope
>> that both tools generate identical names for the types) otherwise the W2J
>> generated interface wont even compile.
>>
>> ...ant
>>
>>
> Given the above what would people think about abandoning our Tuscany/SCA
> Axis2 base W2J tool and just updating the SDO tool to support generating
> the
> SEI class? So for example the helloworld bpel sample where both of these
> are
> used at at the bottom of the pom.xml [1] would have the
> tuscany-maven-wsdl2java plugin removed and an extra parameter added to the
> tuscany-sdo-plugin like <generateSEI>true</generateSEI>?
>
> The generateSEI parameter would only be available when the sdo plugin is
> using a wsdl document and although the generated interface would have the
> SCA @Service and @Remotable annotations as they're just strings it
> wouldn't
> drag in any sca dependencies to sdo, the sca jar would only be needed when
> you actually compile the generated interface.
>
> ...ant
>
> [1]
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-bpel/pom.xml
>
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by ant elder <an...@apache.org>.
On Thu, May 22, 2008 at 9:31 AM, ant elder <an...@apache.org> wrote:
>
>
> On Wed, May 21, 2008 at 5:03 PM, Scott Kurz <sc...@gmail.com> 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.
>>
>
> Yes after playing around with the tools i think thats right. It looks like
> the current Tuscany/SCA W2J tool generates just a service interface but not
> the types for the operation arguments, and that interface is annotated with
> the osoa @Service and @Remotable annotataions. So to use that interface you
> must use another tool to generate the Java classes for the types (and hope
> that both tools generate identical names for the types) otherwise the W2J
> generated interface wont even compile.
>
> ...ant
>
>
Given the above what would people think about abandoning our Tuscany/SCA
Axis2 base W2J tool and just updating the SDO tool to support generating the
SEI class? So for example the helloworld bpel sample where both of these are
used at at the bottom of the pom.xml [1] would have the
tuscany-maven-wsdl2java plugin removed and an extra parameter added to the
tuscany-sdo-plugin like <generateSEI>true</generateSEI>?
The generateSEI parameter would only be available when the sdo plugin is
using a wsdl document and although the generated interface would have the
SCA @Service and @Remotable annotations as they're just strings it wouldn't
drag in any sca dependencies to sdo, the sca jar would only be needed when
you actually compile the generated interface.
...ant
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-bpel/pom.xml
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by ant elder <an...@apache.org>.
On Wed, May 21, 2008 at 5:03 PM, Scott Kurz <sc...@gmail.com> 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.
>
Yes after playing around with the tools i think thats right. It looks like
the current Tuscany/SCA W2J tool generates just a service interface but not
the types for the operation arguments, and that interface is annotated with
the osoa @Service and @Remotable annotataions. So to use that interface you
must use another tool to generate the Java classes for the types (and hope
that both tools generate identical names for the types) otherwise the W2J
generated interface wont even compile.
...ant
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by Scott Kurz <sc...@gmail.com>.
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.
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.
On Wed, May 21, 2008 at 10:05 AM, ant elder <an...@gmail.com> wrote:
> On Wed, May 21, 2008 at 2:53 PM, Mike Edwards <
> mike.edwards.inglenook@gmail.com> 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
>
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by ant elder <an...@gmail.com>.
On Wed, May 21, 2008 at 2:53 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> 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
Re: Tuscany Java2WSDL and WSDL2Java tools
Posted by Mike Edwards <mi...@gmail.com>.
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?
Yours, Mike.