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
