Re: Tuscany Java2WSDL and WSDL2Java tools
On Thu, May 22, 2008 at 6:02 PM, Raymond Feng [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote: On Thu, May 22, 2008 at 6:02 PM, Raymond Feng [EMAIL PROTECTED] 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
On Wed, May 21, 2008 at 7:47 PM, Simon Nash [EMAIL PROTECTED] 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
ant elder wrote: On Wed, May 21, 2008 at 7:47 PM, Simon Nash [EMAIL PROTECTED] 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
On Wed, May 21, 2008 at 5:03 PM, Scott Kurz [EMAIL PROTECTED] 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
On Thu, May 22, 2008 at 9:31 AM, ant elder [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 5:03 PM, Scott Kurz [EMAIL PROTECTED] 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 generateSEItrue/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
2008/5/22 ant elder [EMAIL PROTECTED]: On Thu, May 22, 2008 at 9:31 AM, ant elder [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 5:03 PM, Scott Kurz [EMAIL PROTECTED] 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 generateSEItrue/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
On Thu, May 22, 2008 at 9:03 AM, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: On Wed, May 21, 2008 at 7:47 PM, Simon Nash [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] Sent: Thursday, May 22, 2008 2:52 AM To: tuscany-dev tuscany-dev@ws.apache.org Subject: Re: Tuscany Java2WSDL and WSDL2Java tools On Thu, May 22, 2008 at 9:31 AM, ant elder [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 5:03 PM, Scott Kurz [EMAIL PROTECTED] 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 generateSEItrue/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
On Thu, May 22, 2008 at 5:04 PM, Raymond Feng [EMAIL PROTECTED] 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
Please see my comments inline. Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Thursday, May 22, 2008 9:36 AM To: tuscany-dev tuscany-dev@ws.apache.org Subject: Re: Tuscany Java2WSDL and WSDL2Java tools On Thu, May 22, 2008 at 5:04 PM, Raymond Feng [EMAIL PROTECTED] 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
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.
Re: Tuscany Java2WSDL and WSDL2Java tools
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
Re: Tuscany Java2WSDL and WSDL2Java tools
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 [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
Re: Tuscany Java2WSDL and WSDL2Java tools
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
