It's really the runtime code that Tuscany primarily needs to make choices on and make as good as possible. Users will be able to use any W2J/J2W tool which generate Tuscany-supported databindings, and the JAX-WS annotations should be honored.... i.e. in a bigger sense the runtime codegen and dev-time codegen won't ever be synched (I don't think anyone would argue that..maybe I'm wrong).
So we might restate and scope down the question a bit and say: given that we have a dev-time tool to do J2W with an SDO databinding, how can we leverage this at runtime and also support other databindings with this runtime util (e.g. JAXB)? Now, our runtime util could certainly be refactored to look at the introspected databinding, and if it's SDO, call our dev-time SDO J2W, and if it's not, call Axis2 J2W, (or maybe there are even more cases). We could do this today simply. But then when we get to the question of how to have J2W honor JAX-WS annotations, (which Simon Nash has started to look at), we would have to solve this once on the Axis2 path (or CXF if that works out to be better), and once in our own SDO-enabled J2W. A fundamental problem is we haven't found a J2W framework that is extensible enough to truly plug in support for a new databinding (SDO). On first glance, it looks like our tools plugs in SDO into Axis2 J2W but it ended up as more of a rewrite. And of course JAX-WS/JAXB RI isn't pluggable. That's how we ended up with our own J2W for SDO. If CXF makes writing this databinding plugin easier then great. I'm not sure anyone has looked into this. Or, maybe Axis2 has matured since we first started using it two years ago. Both of these (like Alex confirmed for Axis2) have the ability to honor the JAXB annotations. Hopefully one or both also support the JAX-WS annotations, and this we also need to understand more. But I think this is what we need to look at next in order to really simpllify this area. Scott On Wed, Mar 5, 2008 at 10:52 AM, Simon Nash <[EMAIL PROTECTED]> wrote: > See inline. > > Simon > > Simon Laws wrote: > > On Wed, Mar 5, 2008 at 2:30 PM, Alex <[EMAIL PROTECTED]> wrote: > > > >> Hi Scott, > >> > >> the Axis2 Java2WSDL can add "-sg" option with the value " > >> org.apache.axis2.jaxbri.JaxbSchemaGenerator". > >> then it can deal with the JXAB annotations. > >> since interface-wsdl-java2wsdl relies on Axis'2 java2wsdl directly, > It's > >> easy to do JXAB. > >> But for tools\java2wsdl, it NOT easy since it use different approache. > >> -Alex > >> On Wed, Mar 5, 2008 at 10:09 PM, Scott Kurz <[EMAIL PROTECTED]> > wrote: > >> > >>> One important difference if I understand correctly is the tool handles > >>> SDOs > >>> whereas the runtime > >>> interface-wsdl-java2wsdl module only handles POJO types. > >>> > >>> I think the runtime code basically relies on Axis2's Java->XSD > mapping, > >>> which I don't think would > >>> fully honor JAXB annotations in the Java as it ideally would (though > it > >>> looks like we do an extra > >>> step allowing us to recognize if a NS->pkg mapping other than the > >> default > >>> was used to gen the Java). > >>> > >>> (With some configuration, I believe it's possible to use Axis2's J2W > >>> function in a way such that it would > >>> recognize these JAXB annotations, or another alternative I believe > Simon > >>> Nash mentioned was to look into > >>> CXF.) > >>> > >>> I didn't follow all of the discussion about removing SDO from the > >> Tuscany > >>> charter... but if SDO is no > >>> longer a special part of the Tuscany project then what would happen to > >> the > >>> W2J/J2W tools built around > >>> SDO support? > >>> > >>> Scott > >>> > >>> > >>> > >>> On Wed, Mar 5, 2008 at 7:26 AM, Simon Laws <[EMAIL PROTECTED]> > >>> wrote: > >>> > >>>> On Tue, Mar 4, 2008 at 9:03 AM, Alex <[EMAIL PROTECTED]> wrote: > >>>> > >>>>> Hi All, > >>>>> In tuscany-sca (1.1 above) , there are two modules related with > >>>> java2wsdl: > >>>>> 1.) modules\interface-wsdl-java2wsdl > >>>>> 2.) tools\java2wsdl > >>>>> The java2wsdl interface(1) provides a runtime interface to handle > >> java > >>>>> object to wsdl object > >>>>> the java2wsdl tool (2) provides a command-line tool for converting > >>> java > >>>>> classes into wsdl files. > >>>>> the (1) use JAVA2WSDLBuilder (from Axis2 1.3 code) and > >>>> AxisService2WSDL11, > >>>>> AxisService2WSDL20 to generate WSDL > >>>>> the (2) use TuscanyJAVA2WSDLBuilder, TuscanyWSDLTypeGenerator ... to > >>>>> generate WSDL > >>>>> Why there are two different ways? Why not just use axis code only or > >>>>> tuscany > >>>>> code only for the two modules? > >>>>> Or there are already a plan to merge the code? so which one will be > >> if > >>>>> there > >>>>> is a choice? > >>>>> > >>>>> Thanks > >>>>> - Alex > >>>>> > >>>> Hi Alex > >>>> > >>>> I don't think there is a good reason for the two approaches to WSDL > >>>> generation. It's probably just historical. I agree that it would be > >> much > >>>> cleaner and more maintainable to have one set of code for doing this. > >> I > >>>> saw > >>>> a comment on the list the other from someone getting different > results > >>>> depending on which approach they used. This is obviously not a good > >>> thing. > >>>> Are you interested in getting involved in trying to fix this? > >>>> > >>>> Regards > >>>> > >>>> Simon > >>>> > >> > >> > >> -- > >> http://jroller.com/page/dindin > >> > > > > The question then is, what do we want these tools to do? Some thoughts > from > > my point of view. This is just my view and others may disagree... > > > > - The runtime J2WSDL should be able to generate WSDL for Java interfaces > for > > the Java interface styles that Tuscany SCA supports. Specifically I mean > > that our runtime tooling should be able to handle the various > databindings > > that we support for java interfaces, e.g. SDO, JAXB, etc. It's not > necessary > > that they are all supported straight away but we should have an approach > > that means we see how they could be supported. > > > +1 > > > - We should try and adopt existing technology for doing this generation > > where possible, Axis2, CxF etc. rather than writing our own > > > +1 > > > - We may need to make changes over and above the basic generation > provided > > by tools, such as Axis, to fix faults and add extra function, e.g. [1] > and I > > know Raymond has been working on making sure we adopt a JAXWS mapping > for > > java2wsdl generation. Also there are extra annotations that we may want > to > > introduce in the WSDL based on service configuration. > > > +1 > > > - We shouldn't have two sets of tooling implemented in different ways to > do > > this stuff > > > +1 > > > There has been previous discussion of this in [2] but I don't know where > > Simon got to. > > > Because of illness and travelling, I haven't made much progress with > calling the CXF generator. I'm hoping that I will be able to get back > into this next week. > > > It sounds like we need a tool into which we can plug WSDL > and > > XSD generators and also plug in post generation processors. As Scott > points > > out the runtime Java2WSDL currently has different capability compared > with > > the developer tooling. I'm with Alex on this, If we can further develop > the > > runtime tool then does anyone have any good reason why we can't use the > same > > code for the developer tool? > > > Yes in principle. However I'm not sure that the current Axis2 runtime > code > that we use has the flexibility necessary to handle things like SDO types > and JAX-WS annotations. > > Simon > > > Simon > > > > [1] > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28531.html > > [2] http://www.mail-archive.com/[email protected]/msg27855.html > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
