You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Alex <wu...@gmail.com> on 2008/03/04 10:03:40 UTC

Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

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

Re: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

Posted by Alex <wu...@gmail.com>.
Hi Simon
Thanks for your reply, I would like to help to improve it.
I think maybe we can merge the tools\java2wsdl code, and let them both
follow the axis's approache.
On Wed, Mar 5, 2008 at 8:26 PM, Simon Laws <si...@googlemail.com>
wrote:

>  On Tue, Mar 4, 2008 at 9:03 AM, Alex <wu...@gmail.com> 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

Re: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

Posted by Scott Kurz <sc...@gmail.com>.
One difference between CXF J2W and Axis2 J2W appears to be that CXF follows
the JAXWS spec with respect
to the fault<-->exception mapping whereas Axis2 invents a new convention.

Correct me if I'm wrong but I don't think the Tuscany runtime supports the
Axis2 pattern, right?

This would imply some new work I believe... whereas support for the JAX-WS
spec'd pattern is implemented in class
JAXWSFaultExceptionMapper.

Scott




On Thu, Mar 6, 2008 at 12:25 PM, Alex <wu...@gmail.com> wrote:

> Hi, simon
>
> Axis2's JAVA2WSDL can handle the JAX-WS annnotations by default.
> Since it's
> org.apache.axis2.description.java2wsdl.DefaultSchemaGeneratorcontains
> following lines:
>  JAnnotation annotation = jclass.getAnnotation(
> AnnotationConstants.WEB_SERVICE);
>                if (annotation != null) {
>                    String tns =
>                            annotation.getValue(
> AnnotationConstants.TARGETNAMESPACE).asString();
>                    if (tns != null && !"".equals(tns)) {
>                        targetNamespace = tns;
>                        schemaTargetNameSpace = tns;
>                    }
>                }
> ....
>  JAnnotation methodAnnon = jMethod.getAnnotation(
> AnnotationConstants.WEB_METHOD);
>            if (methodAnnon != null) {
>                if
> (methodAnnon.getValue(AnnotationConstants.EXCLUDE).asBoolean())
> {
>                    continue;
>                }
>            }
> if use the "-sg" optional to replace the DefaultSchemaGenerator with
> org.apache.axis2.jaxbri.JaxbSchemaGenerator
> then it can handle the JAXB annotations.(actually it can handle JAX-WS and
> JAXB both, since JaxbSchemaGenerator extends DefaultSchemaGenerator )
>
> I will look into CXF in the furture, and find out what's differrent
> between
> them, if you alreadly know it, i would like to hear your comments.
> Best Regards
>
> - Alex
>
>
> On Wed, Mar 5, 2008 at 11:25 PM, Simon Nash <na...@apache.org> wrote:
>
> > See inline.
> >
> >   Simon
> >
> > Scott Kurz 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.)
> > >
> > Can you say more about what Axis2 configuration is needed?  Does this
> only
> > handle JAXB annotations or does it handle JAX-WS annnotations as well?
> > My primary use case that led me to look at using CXF was handling JAX-WS
> > annotations in service interfaces (which may also require handling JAXB
> > annotations in data types passed over the interface).
> >
> > > 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?
> > >
> > If some other project were to produce suitable SDO tools, then Tuscany
> > could
> > delegate to those tools instead of having its own.  Until this happens,
> > I'd
> > expect the current tools to remain in Tuscany.
> >
> >   Simon
> >
> > > Scott
> > >
> > >
> > >
> > > On Wed, Mar 5, 2008 at 7:26 AM, Simon Laws <si...@googlemail.com>
> > > wrote:
> > >
> > >> On Tue, Mar 4, 2008 at 9:03 AM, Alex <wu...@gmail.com> 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
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> http://jroller.com/page/dindin
>

Re: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

Posted by Alex <wu...@gmail.com>.
Hi, simon

Axis2's JAVA2WSDL can handle the JAX-WS annnotations by default.
Since it's org.apache.axis2.description.java2wsdl.DefaultSchemaGeneratorcontains
following lines:
 JAnnotation annotation = jclass.getAnnotation(
AnnotationConstants.WEB_SERVICE);
                if (annotation != null) {
                    String tns =
                            annotation.getValue(
AnnotationConstants.TARGETNAMESPACE).asString();
                    if (tns != null && !"".equals(tns)) {
                        targetNamespace = tns;
                        schemaTargetNameSpace = tns;
                    }
                }
....
 JAnnotation methodAnnon = jMethod.getAnnotation(
AnnotationConstants.WEB_METHOD);
            if (methodAnnon != null) {
                if
(methodAnnon.getValue(AnnotationConstants.EXCLUDE).asBoolean())
{
                    continue;
                }
            }
if use the "-sg" optional to replace the DefaultSchemaGenerator with
org.apache.axis2.jaxbri.JaxbSchemaGenerator
then it can handle the JAXB annotations.(actually it can handle JAX-WS and
JAXB both, since JaxbSchemaGenerator extends DefaultSchemaGenerator )

I will look into CXF in the furture, and find out what's differrent between
them, if you alreadly know it, i would like to hear your comments.
Best Regards

- Alex


On Wed, Mar 5, 2008 at 11:25 PM, Simon Nash <na...@apache.org> wrote:

> See inline.
>
>   Simon
>
> Scott Kurz 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.)
> >
> Can you say more about what Axis2 configuration is needed?  Does this only
> handle JAXB annotations or does it handle JAX-WS annnotations as well?
> My primary use case that led me to look at using CXF was handling JAX-WS
> annotations in service interfaces (which may also require handling JAXB
> annotations in data types passed over the interface).
>
> > 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?
> >
> If some other project were to produce suitable SDO tools, then Tuscany
> could
> delegate to those tools instead of having its own.  Until this happens,
> I'd
> expect the current tools to remain in Tuscany.
>
>   Simon
>
> > Scott
> >
> >
> >
> > On Wed, Mar 5, 2008 at 7:26 AM, Simon Laws <si...@googlemail.com>
> > wrote:
> >
> >> On Tue, Mar 4, 2008 at 9:03 AM, Alex <wu...@gmail.com> 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
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


-- 
http://jroller.com/page/dindin

Re: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

Posted by Simon Nash <na...@apache.org>.
See inline.

   Simon

Scott Kurz 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.)
> 
Can you say more about what Axis2 configuration is needed?  Does this only
handle JAXB annotations or does it handle JAX-WS annnotations as well?
My primary use case that led me to look at using CXF was handling JAX-WS
annotations in service interfaces (which may also require handling JAXB
annotations in data types passed over the interface).

> 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?
> 
If some other project were to produce suitable SDO tools, then Tuscany could
delegate to those tools instead of having its own.  Until this happens, I'd
expect the current tools to remain in Tuscany.

   Simon

> Scott
> 
> 
> 
> On Wed, Mar 5, 2008 at 7:26 AM, Simon Laws <si...@googlemail.com>
> wrote:
> 
>> On Tue, Mar 4, 2008 at 9:03 AM, Alex <wu...@gmail.com> 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
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

Posted by kelvin goodson <ke...@thegoodsons.org.uk>.
On 05/03/2008, Scott Kurz <sc...@gmail.com> wrote:
>
>
> 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?


The WSDL/WSDL tools are currently in the SCA code base, so I don't imagine
that would change as a result of the creation of a SDO specific project.

Kelvin.

Re: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

Posted by Scott Kurz <sc...@gmail.com>.
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 <na...@apache.org> wrote:

> See inline.
>
>   Simon
>
> Simon Laws wrote:
> > On Wed, Mar 5, 2008 at 2:30 PM, Alex <wu...@gmail.com> 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 <sc...@gmail.com>
> 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 <si...@googlemail.com>
> >>> wrote:
> >>>
> >>>> On Tue, Mar 4, 2008 at 9:03 AM, Alex <wu...@gmail.com> 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/tuscany-dev@ws.apache.org/msg27855.html
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

Posted by Simon Nash <na...@apache.org>.
See inline.

   Simon

Simon Laws wrote:
> On Wed, Mar 5, 2008 at 2:30 PM, Alex <wu...@gmail.com> 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 <sc...@gmail.com> 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 <si...@googlemail.com>
>>> wrote:
>>>
>>>> On Tue, Mar 4, 2008 at 9:03 AM, Alex <wu...@gmail.com> 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/tuscany-dev@ws.apache.org/msg27855.html
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.

Thanks,
Raymond


[[snip]]
> 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. To be precise, we should have J2WSDL and J2XSD. J2WSDL maps a java
interface to a WSDL portType following the JAXWS rules as required by the
SCA spec. The J2XSD maps parameter/return/exception types to XML schema
definitions. The J2XSD should be made extensible on databinding bases. For
example, both SDO and JAXB have the capability to generate XSD out of its
typing metadata.

>
> - We should try and adopt existing technology for doing this generation
> where possible, Axis2, CxF etc. rather than writing our own
>

I would argue based the following reasons:

1) Interface types are extensible in SCA. So far we support WSDL 1.1
portTypes and Java interfaces. We might add more such as WSDL 2.0 or even
CORBA IDL. The nice thing is that we have a neutral Interface/Operation
model. We map native interface definitions to our Interface/Operation model
and we just don't have the generation from our Interface/Operation to a
native interface definitions yet.

2) Regardless of the generation, we need to implement the mapping rules
anyway to validate the compatibility of SCA service/reference interfaces
defined in different IDLs.

3) We should try to implement Interface/Operation to WSDL/XSD (instead of
Java to WSDL/XSD). The 2WSDL part should be fairly straightforward (I can
prototype). We could reuse some code from Axis2/CXF by copying. The 2XSD
part can be handled by databindings. AFAIK, both SDO and JAXB provide such
APIs to handle that. Existing tools often don't have the flexibility we
need, for example, support different databindings, honoring SCA annotations.


> - 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.

This is the part I don't favor calling existing tools as-is, patching the
generated code is not fun :-(.

>
> - We shouldn't have two sets of tooling implemented in different ways to
> do
> this stuff

In some cases, we could even use the JAXWS wsgen/wsimport tools as-is if the
preferred databinding is JAXB.

>
> There has been previous discussion of this in [2] but I don't know where
> Simon got to. 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?
>
> Simon
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28531.html
> [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27855.html
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

Posted by Simon Laws <si...@googlemail.com>.
On Wed, Mar 5, 2008 at 2:30 PM, Alex <wu...@gmail.com> 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 <sc...@gmail.com> 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 <si...@googlemail.com>
> > wrote:
> >
> > > On Tue, Mar 4, 2008 at 9:03 AM, Alex <wu...@gmail.com> 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.

- We should try and adopt existing technology for doing this generation
where possible, Axis2, CxF etc. rather than writing our own

- 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.

- We shouldn't have two sets of tooling implemented in different ways to do
this stuff

There has been previous discussion of this in [2] but I don't know where
Simon got to. 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?

Simon

[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28531.html
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27855.html

Re: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

Posted by Alex <wu...@gmail.com>.
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 <sc...@gmail.com> 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 <si...@googlemail.com>
> wrote:
>
> > On Tue, Mar 4, 2008 at 9:03 AM, Alex <wu...@gmail.com> 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

Re: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

Posted by Scott Kurz <sc...@gmail.com>.
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 <si...@googlemail.com>
wrote:

> On Tue, Mar 4, 2008 at 9:03 AM, Alex <wu...@gmail.com> 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
>

Re: Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

Posted by Simon Laws <si...@googlemail.com>.
On Tue, Mar 4, 2008 at 9:03 AM, Alex <wu...@gmail.com> 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