You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2008/06/04 23:00:54 UTC
Can't generate a Java interface from a WSDL portType
SCA allows you to define service interfaces using either WSDL or Java
(and potentially other languages too). The SCA Java API and Annotations
spec v1.0 says (section 1.9) says that the JAX-WS WSDL to Java mapping
rules are used to generate Java interfaces from WSDL.
I have a WSDL file describing my interface using a portType and I've
been trying the JAXWS wsimport Maven tool for about an hour now with no
luck. Looks like wsimport requires a WSDL <service>, which I don't have,
and don't want to have to write in my WSDL (it wouldn't make much sense
to have it on an interface anyway).
Is Tuscany providing a WSDL interface/portType to Java generation tool?
Is anybody out there using WSDL and Java interfaces? Any luck? What
JAX-WS compliant tool are you using to generate your Java interfaces?
--
Jean-Sebastien
Re: Can't generate a Java interface from a WSDL portType
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
I tend to agree with Simon, that the package name would rightly be derived from the target namespace
of the <wsdl:definitions/> containing the portType definition, since it's the port type that
defines the interface.
So +1 to the CXF interpretation.
On the other hand, there is a JAX-WS TCK. Does it test this piece of function I wonder...?
Yours, Mike.
Simon Nash wrote:
> Scott Kurz wrote:
>> Simon,
>>
>> The question is do we look at the <definitions> of the WSDL document
>> defining the imported portType
>> or the <definitions> of the document defining a WSDL service in terms
>> of the
>> imported portType (since the TNS
>> of each are different).
>>
>> I haven't read all of JAX-WS either but agree that the CXF behavior makes
>> more sense.
>>
>> If you consider the question "which <definitions>?" it seems you'd
>> naturally
>> pick the one in which
>> the portType is actually DEFINED as opposed to merely IMPORTED>
>>
>>> From what I can see the WSDL spec doesn't say anything particular
>>> about the
>> import behavior either.
>>
>> On the one hand this isn't too critical since, with either choice, we
>> generate a just-as-legal
>> @WebService(targetNamespace....)
>> into the Java to capture the original TNS.
>>
> Doesn't this raise the same question? The @WebService annotation
> for the generated Java interface should have the targetNamespace
> of the portType. It seems an extremely reasonable assumption
> that this is the same targetNamespace of the portType (whatever
> that means) that will be used to derive the package name.
>
> I tried this with the Sun RI and was surprised that it took the
> targetNamespace for the @WebService annotation from the portType's
> <wsdl:definitions>, even though it took the targetNamespace for
> the package name from the service's <wsdl:definitions>.
>
> This inconsistency seems wrong to me. My conclusion is that
> CXF has got this right.
>
>> On the other hand, JAX-WS could have been clearer on this...
>>
> I agree. And this seems like a warning that in cases where the
> spec is ambiguous, we should not assume that we can use the
> Sun RI's behaviour to determine which interpretation is correct.
>
> Simon
>>
>>
>>
>>
>>
>> On Mon, Jun 9, 2008 at 4:45 AM, Simon Nash <na...@apache.org> wrote:
>>
>>> Jean-Sebastien Delfino wrote:
>>>
>>>> Scott Kurz wrote:
>>>>
>>>>> Sebastien, I'm surprised the package names would be different.
>>>>> What is
>>>>> the namespace you're using that isn't mapping to the same package
>>>>> in each
>>>>> tool?
>>>>> Just curious...
>>>>>
>>>>>
>>>> My app is an order processing app with the following:
>>>>
>>>> WSDL service namespace:
>>>> http://sample/Order/Binding
>>>>
>>>> WSDL Order portType namespace:
>>>> http://sample/Order
>>>>
>>>> The CXF tool generates interface sample.order.Order
>>>> The JAXWS RI tool generates interface sample.order.binding.Order
>>>>
>>>> I gave the same WSDL file (containing the WSDL service) to both tools.
>>>>
>>>> One could argue that both are correct vs the JAX-WS spec as they
>>>> generate
>>>> a correct package name from the namespace of 'the' WSDL definition,
>>>> but the
>>>> funny thing is that they do not pick the same WSDL definition...
>>>> JAXWS-RI
>>>> picks the input definition given to the tool and CXF the definition
>>>> that
>>>> actually contains the portType... and the JAXWS spec doesn't seem to
>>>> state
>>>> which one should be picked (at least I couldn't find it).
>>>>
>>>> IMHO the CXF behavior is better, but I've not read all 150 pages of the
>>>> JAX-WS spec so I may be missing something :)
>>>>
>>>>
>>> From section 2.2 of the JAX-WS spec:
>>>
>>> A wsdl:portType element is mapped to a Java interface in the package
>>> mapped from the wsdl:definitions element (see section 2.1 for a
>>> description of wsdl:definitions mapping).
>>>
>>> Section 2.1 says:
>>>
>>> A wsdl:definitions element and its associated targetNamespace
>>> attribute is mapped to a Java package. JAXB[10] (see appendix D)
>>> defines a standard mapping from a namespace URI to a Java package
>>> name. By default, this algorithm is used to map the value of a
>>> wsdl:definitions element's targetNamespace attribute to a Java
>>> package name.
>>>
>>> } Conformance (Definitions mapping): In the absence of customizations,
>>> the Java package name is mapped from the value of a wsdl:definitions
>>> element's targetNamespace attribute using the algorithm defined by
>>> JAXB[10].
>>>
>>> So IMO the Java package name that's used to map the portType should
>>> be derived from the targetNamespace of the wsdl:definitions element.
>>> What was this targetNamespace?
>>>
>>> Simon
>>>
>>>
>>
>
>
Re: Can't generate a Java interface from a WSDL portType
Posted by Scott Kurz <sc...@gmail.com>.
On Tue, Jun 10, 2008 at 4:59 AM, Simon Nash <na...@apache.org> wrote:
>
> I tried this with the Sun RI and was surprised that it took the
> targetNamespace for the @WebService annotation from the portType's
> <wsdl:definitions>, even though it took the targetNamespace for
> the package name from the service's <wsdl:definitions>.
>
> This inconsistency seems wrong to me. My conclusion is that
> CXF has got this right.
>
That's interesting. Seems like wsimport might have a bug then if they're
not in synch with
themselves. (And sorry my earlier comment here was meaningless.)
>
> On the other hand, JAX-WS could have been clearer on this...
>>
>> I agree. And this seems like a warning that in cases where the
> spec is ambiguous, we should not assume that we can use the
> Sun RI's behaviour to determine which interpretation is correct.
>
> Simon
Good point.
Scott
Re: Can't generate a Java interface from a WSDL portType
Posted by Simon Nash <na...@apache.org>.
Scott Kurz wrote:
> Simon,
>
> The question is do we look at the <definitions> of the WSDL document
> defining the imported portType
> or the <definitions> of the document defining a WSDL service in terms of the
> imported portType (since the TNS
> of each are different).
>
> I haven't read all of JAX-WS either but agree that the CXF behavior makes
> more sense.
>
> If you consider the question "which <definitions>?" it seems you'd naturally
> pick the one in which
> the portType is actually DEFINED as opposed to merely IMPORTED>
>
>>>From what I can see the WSDL spec doesn't say anything particular about the
> import behavior either.
>
> On the one hand this isn't too critical since, with either choice, we
> generate a just-as-legal
> @WebService(targetNamespace....)
> into the Java to capture the original TNS.
>
Doesn't this raise the same question? The @WebService annotation
for the generated Java interface should have the targetNamespace
of the portType. It seems an extremely reasonable assumption
that this is the same targetNamespace of the portType (whatever
that means) that will be used to derive the package name.
I tried this with the Sun RI and was surprised that it took the
targetNamespace for the @WebService annotation from the portType's
<wsdl:definitions>, even though it took the targetNamespace for
the package name from the service's <wsdl:definitions>.
This inconsistency seems wrong to me. My conclusion is that
CXF has got this right.
> On the other hand, JAX-WS could have been clearer on this...
>
I agree. And this seems like a warning that in cases where the
spec is ambiguous, we should not assume that we can use the
Sun RI's behaviour to determine which interpretation is correct.
Simon
>
>
>
>
>
> On Mon, Jun 9, 2008 at 4:45 AM, Simon Nash <na...@apache.org> wrote:
>
>> Jean-Sebastien Delfino wrote:
>>
>>> Scott Kurz wrote:
>>>
>>>> Sebastien, I'm surprised the package names would be different. What is
>>>> the namespace you're using that isn't mapping to the same package in each
>>>> tool?
>>>> Just curious...
>>>>
>>>>
>>> My app is an order processing app with the following:
>>>
>>> WSDL service namespace:
>>> http://sample/Order/Binding
>>>
>>> WSDL Order portType namespace:
>>> http://sample/Order
>>>
>>> The CXF tool generates interface sample.order.Order
>>> The JAXWS RI tool generates interface sample.order.binding.Order
>>>
>>> I gave the same WSDL file (containing the WSDL service) to both tools.
>>>
>>> One could argue that both are correct vs the JAX-WS spec as they generate
>>> a correct package name from the namespace of 'the' WSDL definition, but the
>>> funny thing is that they do not pick the same WSDL definition... JAXWS-RI
>>> picks the input definition given to the tool and CXF the definition that
>>> actually contains the portType... and the JAXWS spec doesn't seem to state
>>> which one should be picked (at least I couldn't find it).
>>>
>>> IMHO the CXF behavior is better, but I've not read all 150 pages of the
>>> JAX-WS spec so I may be missing something :)
>>>
>>>
>> From section 2.2 of the JAX-WS spec:
>>
>> A wsdl:portType element is mapped to a Java interface in the package
>> mapped from the wsdl:definitions element (see section 2.1 for a
>> description of wsdl:definitions mapping).
>>
>> Section 2.1 says:
>>
>> A wsdl:definitions element and its associated targetNamespace
>> attribute is mapped to a Java package. JAXB[10] (see appendix D)
>> defines a standard mapping from a namespace URI to a Java package
>> name. By default, this algorithm is used to map the value of a
>> wsdl:definitions element's targetNamespace attribute to a Java
>> package name.
>>
>> } Conformance (Definitions mapping): In the absence of customizations,
>> the Java package name is mapped from the value of a wsdl:definitions
>> element's targetNamespace attribute using the algorithm defined by
>> JAXB[10].
>>
>> So IMO the Java package name that's used to map the portType should
>> be derived from the targetNamespace of the wsdl:definitions element.
>> What was this targetNamespace?
>>
>> Simon
>>
>>
>
Re: Can't generate a Java interface from a WSDL portType
Posted by Scott Kurz <sc...@gmail.com>.
Simon,
The question is do we look at the <definitions> of the WSDL document
defining the imported portType
or the <definitions> of the document defining a WSDL service in terms of the
imported portType (since the TNS
of each are different).
I haven't read all of JAX-WS either but agree that the CXF behavior makes
more sense.
If you consider the question "which <definitions>?" it seems you'd naturally
pick the one in which
the portType is actually DEFINED as opposed to merely IMPORTED>
>From what I can see the WSDL spec doesn't say anything particular about the
import behavior either.
On the one hand this isn't too critical since, with either choice, we
generate a just-as-legal
@WebService(targetNamespace....)
into the Java to capture the original TNS.
On the other hand, JAX-WS could have been clearer on this...
On Mon, Jun 9, 2008 at 4:45 AM, Simon Nash <na...@apache.org> wrote:
> Jean-Sebastien Delfino wrote:
>
>> Scott Kurz wrote:
>>
>>> Sebastien, I'm surprised the package names would be different. What is
>>> the namespace you're using that isn't mapping to the same package in each
>>> tool?
>>> Just curious...
>>>
>>>
>> My app is an order processing app with the following:
>>
>> WSDL service namespace:
>> http://sample/Order/Binding
>>
>> WSDL Order portType namespace:
>> http://sample/Order
>>
>> The CXF tool generates interface sample.order.Order
>> The JAXWS RI tool generates interface sample.order.binding.Order
>>
>> I gave the same WSDL file (containing the WSDL service) to both tools.
>>
>> One could argue that both are correct vs the JAX-WS spec as they generate
>> a correct package name from the namespace of 'the' WSDL definition, but the
>> funny thing is that they do not pick the same WSDL definition... JAXWS-RI
>> picks the input definition given to the tool and CXF the definition that
>> actually contains the portType... and the JAXWS spec doesn't seem to state
>> which one should be picked (at least I couldn't find it).
>>
>> IMHO the CXF behavior is better, but I've not read all 150 pages of the
>> JAX-WS spec so I may be missing something :)
>>
> >
> From section 2.2 of the JAX-WS spec:
>
> A wsdl:portType element is mapped to a Java interface in the package
> mapped from the wsdl:definitions element (see section 2.1 for a
> description of wsdl:definitions mapping).
>
> Section 2.1 says:
>
> A wsdl:definitions element and its associated targetNamespace
> attribute is mapped to a Java package. JAXB[10] (see appendix D)
> defines a standard mapping from a namespace URI to a Java package
> name. By default, this algorithm is used to map the value of a
> wsdl:definitions element's targetNamespace attribute to a Java
> package name.
>
> } Conformance (Definitions mapping): In the absence of customizations,
> the Java package name is mapped from the value of a wsdl:definitions
> element's targetNamespace attribute using the algorithm defined by
> JAXB[10].
>
> So IMO the Java package name that's used to map the portType should
> be derived from the targetNamespace of the wsdl:definitions element.
> What was this targetNamespace?
>
> Simon
>
>
Re: Can't generate a Java interface from a WSDL portType
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> Jean-Sebastien Delfino wrote:
>> Scott Kurz wrote:
>>> Sebastien, I'm surprised the package names would be different.
>>> What is
>>> the namespace you're using that isn't mapping to the same package in
>>> each
>>> tool?
>>> Just curious...
>>>
>>
>> My app is an order processing app with the following:
>>
>> WSDL service namespace:
>> http://sample/Order/Binding
>>
>> WSDL Order portType namespace:
>> http://sample/Order
>>
>> The CXF tool generates interface sample.order.Order
>> The JAXWS RI tool generates interface sample.order.binding.Order
>>
>> I gave the same WSDL file (containing the WSDL service) to both tools.
>>
>> One could argue that both are correct vs the JAX-WS spec as they
>> generate a correct package name from the namespace of 'the' WSDL
>> definition, but the funny thing is that they do not pick the same WSDL
>> definition... JAXWS-RI picks the input definition given to the tool
>> and CXF the definition that actually contains the portType... and the
>> JAXWS spec doesn't seem to state which one should be picked (at least
>> I couldn't find it).
>>
>> IMHO the CXF behavior is better, but I've not read all 150 pages of
>> the JAX-WS spec so I may be missing something :)
> >
> From section 2.2 of the JAX-WS spec:
>
> A wsdl:portType element is mapped to a Java interface in the package
> mapped from the wsdl:definitions element (see section 2.1 for a
> description of wsdl:definitions mapping).
>
> Section 2.1 says:
>
> A wsdl:definitions element and its associated targetNamespace
> attribute is mapped to a Java package. JAXB[10] (see appendix D)
> defines a standard mapping from a namespace URI to a Java package
> name. By default, this algorithm is used to map the value of a
> wsdl:definitions element’s targetNamespace attribute to a Java
> package name.
>
> } Conformance (Definitions mapping): In the absence of customizations,
> the Java package name is mapped from the value of a wsdl:definitions
> element’s targetNamespace attribute using the algorithm defined by
> JAXB[10].
Yeah I read that too. Again, both implementations comply with that text
but pick different definitions. That's all.
> So IMO the Java package name that's used to map the portType should
> be derived from the targetNamespace of the wsdl:definitions element.
> What was this targetNamespace?
See above: http://sample/Order
>
> Simon
>
--
Jean-Sebastien
Re: Can't generate a Java interface from a WSDL portType
Posted by Simon Nash <na...@apache.org>.
Jean-Sebastien Delfino wrote:
> Scott Kurz wrote:
>> Sebastien, I'm surprised the package names would be different. What is
>> the namespace you're using that isn't mapping to the same package in each
>> tool?
>> Just curious...
>>
>
> My app is an order processing app with the following:
>
> WSDL service namespace:
> http://sample/Order/Binding
>
> WSDL Order portType namespace:
> http://sample/Order
>
> The CXF tool generates interface sample.order.Order
> The JAXWS RI tool generates interface sample.order.binding.Order
>
> I gave the same WSDL file (containing the WSDL service) to both tools.
>
> One could argue that both are correct vs the JAX-WS spec as they
> generate a correct package name from the namespace of 'the' WSDL
> definition, but the funny thing is that they do not pick the same WSDL
> definition... JAXWS-RI picks the input definition given to the tool and
> CXF the definition that actually contains the portType... and the JAXWS
> spec doesn't seem to state which one should be picked (at least I
> couldn't find it).
>
> IMHO the CXF behavior is better, but I've not read all 150 pages of the
> JAX-WS spec so I may be missing something :)
>
From section 2.2 of the JAX-WS spec:
A wsdl:portType element is mapped to a Java interface in the package
mapped from the wsdl:definitions element (see section 2.1 for a
description of wsdl:definitions mapping).
Section 2.1 says:
A wsdl:definitions element and its associated targetNamespace
attribute is mapped to a Java package. JAXB[10] (see appendix D)
defines a standard mapping from a namespace URI to a Java package
name. By default, this algorithm is used to map the value of a
wsdl:definitions element’s targetNamespace attribute to a Java
package name.
} Conformance (Definitions mapping): In the absence of customizations,
the Java package name is mapped from the value of a wsdl:definitions
element’s targetNamespace attribute using the algorithm defined by
JAXB[10].
So IMO the Java package name that's used to map the portType should
be derived from the targetNamespace of the wsdl:definitions element.
What was this targetNamespace?
Simon
Re: Can't generate a Java interface from a WSDL portType
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Scott Kurz wrote:
> Sebastien, I'm surprised the package names would be different. What is
> the namespace you're using that isn't mapping to the same package in each
> tool?
> Just curious...
>
My app is an order processing app with the following:
WSDL service namespace:
http://sample/Order/Binding
WSDL Order portType namespace:
http://sample/Order
The CXF tool generates interface sample.order.Order
The JAXWS RI tool generates interface sample.order.binding.Order
I gave the same WSDL file (containing the WSDL service) to both tools.
One could argue that both are correct vs the JAX-WS spec as they
generate a correct package name from the namespace of 'the' WSDL
definition, but the funny thing is that they do not pick the same WSDL
definition... JAXWS-RI picks the input definition given to the tool and
CXF the definition that actually contains the portType... and the JAXWS
spec doesn't seem to state which one should be picked (at least I
couldn't find it).
IMHO the CXF behavior is better, but I've not read all 150 pages of the
JAX-WS spec so I may be missing something :)
--
Jean-Sebastien
Re: Can't generate a Java interface from a WSDL portType
Posted by Scott Kurz <sc...@gmail.com>.
Sebastien, I'm surprised the package names would be different. What is
the namespace you're using that isn't mapping to the same package in each
tool?
Just curious...
On Wed, Jun 4, 2008 at 7:25 PM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Raymond Feng wrote:
>
>> Hi,
>>
>> I got the CXF code-gen plugin 2.1 working after debugging the plugin
>> source code :-(.
>>
>> Here is the pom.xml snippt I figured out. Please note I had to override
>> wsdlRoot/testWsdlRoot to be a non-existing file to avoid NPE (I assume it's
>> CXF bug if the wsdl files are in src/test/resources/wsdl).
>>
>>
> ...
>
> That worked for me too. The generated output is slightly different from the
> JAXWS RI wsimport (different package name for the generated interface for
> example) but it looks OK.
>
> Thanks!
> --
> Jean-Sebastien
>
Re: Moving from Spring 2.0.6 to 2.0.8, was: Can't generate a Java
interface from a WSDL portType
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Mike Edwards wrote:
> Jean-Sebastien Delfino wrote:
>> CXF 2.1 uses Spring 2.0.8, while our implementation-spring module uses
>> 2.0.6. I'd like to test and change our Spring integration to use 2.0.8
>> as well. If there's no objection (and if it works) I'll make that
>> change in the next few days.
> Sebastien,
>
> I'll be happy to do the work to migrate Spring to 2.0.8 if you like...
>
>
> Yours, Mike.
Mike, Thanks, I already have the change, I just had to change 3
characters , 6 -> 8 in implementation-spring/pom.xml :)
--
Jean-Sebastien
Re: Moving from Spring 2.0.6 to 2.0.8, was: Can't generate a Java
interface from a WSDL portType
Posted by Mike Edwards <mi...@gmail.com>.
Jean-Sebastien Delfino wrote:
> CXF 2.1 uses Spring 2.0.8, while our implementation-spring module uses
> 2.0.6. I'd like to test and change our Spring integration to use 2.0.8
> as well. If there's no objection (and if it works) I'll make that change
> in the next few days.
Sebastien,
I'll be happy to do the work to migrate Spring to 2.0.8 if you like...
Yours, Mike.
Moving from Spring 2.0.6 to 2.0.8, was: Can't generate a Java interface
from a WSDL portType
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Raymond Feng wrote:
>> Hi,
>>
>> I got the CXF code-gen plugin 2.1 working after debugging the plugin
>> source code :-(.
>>
>> Here is the pom.xml snippt I figured out. Please note I had to
>> override wsdlRoot/testWsdlRoot to be a non-existing file to avoid NPE
>> (I assume it's CXF bug if the wsdl files are in src/test/resources/wsdl).
>>
>
> ...
>
> That worked for me too. The generated output is slightly different from
> the JAXWS RI wsimport (different package name for the generated
> interface for example) but it looks OK.
>
> Thanks!
CXF 2.1 uses Spring 2.0.8, while our implementation-spring module uses
2.0.6. I'd like to test and change our Spring integration to use 2.0.8
as well. If there's no objection (and if it works) I'll make that change
in the next few days.
--
Jean-Sebastien
Re: Can't generate a Java interface from a WSDL portType
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> I got the CXF code-gen plugin 2.1 working after debugging the plugin
> source code :-(.
>
> Here is the pom.xml snippt I figured out. Please note I had to override
> wsdlRoot/testWsdlRoot to be a non-existing file to avoid NPE (I assume
> it's CXF bug if the wsdl files are in src/test/resources/wsdl).
>
...
That worked for me too. The generated output is slightly different from
the JAXWS RI wsimport (different package name for the generated
interface for example) but it looks OK.
Thanks!
--
Jean-Sebastien
Re: Can't generate a Java interface from a WSDL portType
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I got the CXF code-gen plugin 2.1 working after debugging the plugin source
code :-(.
Here is the pom.xml snippt I figured out. Please note I had to override
wsdlRoot/testWsdlRoot to be a non-existing file to avoid NPE (I assume it's
CXF bug if the wsdl files are in src/test/resources/wsdl).
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${basedir}/target/jaxws-source</sourceRoot>
<wsdlRoot>NONE</wsdlRoot>
<!-- Override the default value to avoid NPE -->
<testWsdlRoot>NONE</testWsdlRoot>
<wsdlOptions>
<wsdlOption>
<wsdl>${basedir}/src/test/resources/wsdl/Stock.wsdl</wsdl>
<outputDir>${basedir}/target/jaxws-source</outputDir>
<packagenames>
<packagename>com.example.stock.cxf</packagename>
</packagenames>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
Thanks,
Raymond
--------------------------------------------------
From: "Scott Kurz" <sc...@gmail.com>
Sent: Wednesday, June 04, 2008 2:37 PM
To: <tu...@ws.apache.org>
Subject: Re: Can't generate a Java interface from a WSDL portType
> The Apache CXF tool issues a warning but still gens Java w/ JAXB
> databindings from a portType WSDL.
>
>
>
> On Wed, Jun 4, 2008 at 5:00 PM, Jean-Sebastien Delfino
> <js...@apache.org>
> wrote:
>
>> SCA allows you to define service interfaces using either WSDL or Java
>> (and
>> potentially other languages too). The SCA Java API and Annotations spec
>> v1.0 says (section 1.9) says that the JAX-WS WSDL to Java mapping rules
>> are
>> used to generate Java interfaces from WSDL.
>>
>> I have a WSDL file describing my interface using a portType and I've been
>> trying the JAXWS wsimport Maven tool for about an hour now with no luck.
>> Looks like wsimport requires a WSDL <service>, which I don't have, and
>> don't
>> want to have to write in my WSDL (it wouldn't make much sense to have it
>> on
>> an interface anyway).
>>
>> Is Tuscany providing a WSDL interface/portType to Java generation tool?
>>
>> Is anybody out there using WSDL and Java interfaces? Any luck? What
>> JAX-WS
>> compliant tool are you using to generate your Java interfaces?
>> --
>> Jean-Sebastien
>>
>
Re: Can't generate a Java interface from a WSDL portType
Posted by Scott Kurz <sc...@gmail.com>.
The Apache CXF tool issues a warning but still gens Java w/ JAXB
databindings from a portType WSDL.
On Wed, Jun 4, 2008 at 5:00 PM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> SCA allows you to define service interfaces using either WSDL or Java (and
> potentially other languages too). The SCA Java API and Annotations spec
> v1.0 says (section 1.9) says that the JAX-WS WSDL to Java mapping rules are
> used to generate Java interfaces from WSDL.
>
> I have a WSDL file describing my interface using a portType and I've been
> trying the JAXWS wsimport Maven tool for about an hour now with no luck.
> Looks like wsimport requires a WSDL <service>, which I don't have, and don't
> want to have to write in my WSDL (it wouldn't make much sense to have it on
> an interface anyway).
>
> Is Tuscany providing a WSDL interface/portType to Java generation tool?
>
> Is anybody out there using WSDL and Java interfaces? Any luck? What JAX-WS
> compliant tool are you using to generate your Java interfaces?
> --
> Jean-Sebastien
>