Re: Problem generating WSDL from Java API with CXF 2.0.3
Hi Dan, Just in case I didn't update you on our status, in the end we found that we had to turn our interfaces that the SEI methods took and returned into concrete classes to make this work. We still have a separation between the concrete class and the actual implementation used which allows our concrete class to be immutable and the implementation mutable as we wanted. I think even now we have some weirdness around the WSDL generation, but we can at least move forward. Thanks again for your time. Phil :n. On Tue, 2008-02-26 at 13:42 -0500, Daniel Kulp wrote: On Tuesday 26 February 2008, Phil Weighill-Smith wrote: That's the sort of answer I was looking for. Thanks, Phil :n) PS: Was this an RTFM moment?! I wish I could say the answer was yes... :-( I think most of our docs on the wiki at this point are more targetted toward the 2.0.x toolset (since 2.0.x is released). Dan - Original Message - From: Daniel Kulp [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Cc: Phil Weighill-Smith [EMAIL PROTECTED] Sent: Tue, 26 Feb 2008 11:25:16 -0700 (MST) Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3 On Monday 25 February 2008, Phil Weighill-Smith wrote: Dan, The exception happened with just using command line access - with long class paths ;n) Yes, I think we were getting the tooling from a 2.0.1 JAR remnant. But I couldn't find the tooling in the 2.1 snap...? Which tooling? The java2wsdl tool has been merged into the new java2ws tool which supports a bunch of new things. If you just want the wsdl, pass the -wsdl flag. Dan
Re: Problem generating WSDL from Java API with CXF 2.0.3
minOccurs=0 name=return/ /xs:sequence /xs:complexType and the fact that there is no User element/complex type generated...? Phil :n. PS: Thanks for your help so far! On Tue, 2008-02-26 at 13:42 -0500, Daniel Kulp wrote: On Tuesday 26 February 2008, Phil Weighill-Smith wrote: That's the sort of answer I was looking for. Thanks, Phil :n) PS: Was this an RTFM moment?! I wish I could say the answer was yes... :-( I think most of our docs on the wiki at this point are more targetted toward the 2.0.x toolset (since 2.0.x is released). Dan - Original Message - From: Daniel Kulp [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Cc: Phil Weighill-Smith [EMAIL PROTECTED] Sent: Tue, 26 Feb 2008 11:25:16 -0700 (MST) Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3 On Monday 25 February 2008, Phil Weighill-Smith wrote: Dan, The exception happened with just using command line access - with long class paths ;n) Yes, I think we were getting the tooling from a 2.0.1 JAR remnant. But I couldn't find the tooling in the 2.1 snap...? Which tooling? The java2wsdl tool has been merged into the new java2ws tool which supports a bunch of new things. If you just want the wsdl, pass the -wsdl flag. Dan
Re: Problem generating WSDL from Java API with CXF 2.0.3
2.0.x is released). Dan - Original Message - From: Daniel Kulp [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Cc: Phil Weighill-Smith [EMAIL PROTECTED] Sent: Tue, 26 Feb 2008 11:25:16 -0700 (MST) Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3 On Monday 25 February 2008, Phil Weighill-Smith wrote: Dan, The exception happened with just using command line access - with long class paths ;n) Yes, I think we were getting the tooling from a 2.0.1 JAR remnant. But I couldn't find the tooling in the 2.1 snap...? Which tooling? The java2wsdl tool has been merged into the new java2ws tool which supports a bunch of new things. If you just want the wsdl, pass the -wsdl flag. Dan -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
On Monday 25 February 2008, Phil Weighill-Smith wrote:
Dan,
The exception happened with just using command line access - with long
class paths ;n)
Yes, I think we were getting the tooling from a 2.0.1 JAR remnant. But
I couldn't find the tooling in the 2.1 snap...?
Which tooling? The java2wsdl tool has been merged into the new java2ws
tool which supports a bunch of new things. If you just want the wsdl,
pass the -wsdl flag.
Dan
We can consider 1.6.0_04. To be honest, we really need to compile with
a 1.5.x environment ideally since we probably need to support 1.5.x
JREs.
Phil :n.
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 25 February 2008 17:08:00 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
Hmm..
Is this in maven or other build system? It looks like its picking up
some old jars someplace as the class:
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor
no longer even exists.
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK I'm using is 1.6.0.03.
If using 2.1 snapshot, you may want to flip to 1.6.0_04. 03 includes
the 2.0 JAXWS/JAXB API's which may cause issues with the 2.1 versions
that CXF 2.1 requires._04 includes the proper 2.1 versions and I
have gone through and made sure CXF builds and runs with _04.
Dan
On Monday 25 February 2008, Phil Weighill-Smith wrote:
I've tried out the 2.1 snapshot available today and found that the
API has changed in some way in CXF so now trying to generate a WSDL
from Java code gives:
Exception in thread main java.lang.NoSuchMethodError:
org.apache.cxf.tools.java2wsdl.processor.internal.ServiceBuilderFact
or y.newBuilder()Lorg/apache/cxf/service/ServiceBuilder; at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.getServiceB
ui lder(JavaToProcessor.java:144) at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.process(Jav
aT oProcessor.java:87)
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK I'm using is 1.6.0.03.
Any suggestions?
Phil :n.
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 22 February 2008 17:26:59 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
On Friday 22 February 2008, Phil Weighill-Smith wrote:
Dan, sorry it's been several weeks since you e-mailed this to me
and I've not actioned it. Where do I find CXF's official JIRA app?
https://issues.apache.org/jira/browse/CXF
That said, the namespace issue in the WrapperClassGenerator should
be fixed with the latest 2.1 snapshots. I'll probably be doing new
snapshots again today since I've fixed a TON of bugs over the last
couple days. That MAY also fix the other issues you note below as
it will totally delegate to JAXB to generate the getUserResponse
type in the wsdl. Any chance you can try with the latest 2.1
snapshots (or wait till tomorrow/monday and try the ones I'll deploy
later today?)
Dan
By the way, I have also hit a problem where the response parts are
generated with incomplete result definitions. For example, if I
have a method in my SEI like:
@WebService(name = UserModule,
targetNamespace =
http://www.volantis.com/xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
User getUser(@WebParam(name=name) final String name);
...
}
where User is, for example, like this:
@XmlJavaTypeAdapter(UserAdapter.class)
public interface User {
String getName();
String getPassword();
}
with an implementation like:
@XmlType(name = User)
public class UserImpl implements User {
private String name;
private String password;
public void setName(final String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPassword(final String password) {
this.password = password;
}
public String getPassword() {
return password;
}
}
and the adapter looks like:
public final class UserAdapter extends
XmlAdapterUserImpl, User {
@Override
public UserImpl marshal(final User user) throws Exception {
return (UserImpl) user;
}
@Override
public User unmarshal(final UserImpl user) throws Exception {
return user;
}
}
I get some WSDL like this:
wsdl:definitions name=UserModuleService
targetNamespace=http
Re: Problem generating WSDL from Java API with CXF 2.0.3
That's the sort of answer I was looking for. Thanks,
Phil :n)
PS: Was this an RTFM moment?!
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: Tue, 26 Feb 2008 11:25:16 -0700 (MST)
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
On Monday 25 February 2008, Phil Weighill-Smith wrote:
Dan,
The exception happened with just using command line access - with long
class paths ;n)
Yes, I think we were getting the tooling from a 2.0.1 JAR remnant. But
I couldn't find the tooling in the 2.1 snap...?
Which tooling? The java2wsdl tool has been merged into the new java2ws
tool which supports a bunch of new things. If you just want the wsdl,
pass the -wsdl flag.
Dan
We can consider 1.6.0_04. To be honest, we really need to compile with
a 1.5.x environment ideally since we probably need to support 1.5.x
JREs.
Phil :n.
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 25 February 2008 17:08:00 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
Hmm..
Is this in maven or other build system? It looks like its picking up
some old jars someplace as the class:
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor
no longer even exists.
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK I'm using is 1.6.0.03.
If using 2.1 snapshot, you may want to flip to 1.6.0_04. 03 includes
the 2.0 JAXWS/JAXB API's which may cause issues with the 2.1 versions
that CXF 2.1 requires._04 includes the proper 2.1 versions and I
have gone through and made sure CXF builds and runs with _04.
Dan
On Monday 25 February 2008, Phil Weighill-Smith wrote:
I've tried out the 2.1 snapshot available today and found that the
API has changed in some way in CXF so now trying to generate a WSDL
from Java code gives:
Exception in thread main java.lang.NoSuchMethodError:
org.apache.cxf.tools.java2wsdl.processor.internal.ServiceBuilderFact
or y.newBuilder()Lorg/apache/cxf/service/ServiceBuilder; at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.getServiceB
ui lder(JavaToProcessor.java:144) at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.process(Jav
aT oProcessor.java:87)
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK I'm using is 1.6.0.03.
Any suggestions?
Phil :n.
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 22 February 2008 17:26:59 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
On Friday 22 February 2008, Phil Weighill-Smith wrote:
Dan, sorry it's been several weeks since you e-mailed this to me
and I've not actioned it. Where do I find CXF's official JIRA app?
https://issues.apache.org/jira/browse/CXF
That said, the namespace issue in the WrapperClassGenerator should
be fixed with the latest 2.1 snapshots. I'll probably be doing new
snapshots again today since I've fixed a TON of bugs over the last
couple days. That MAY also fix the other issues you note below as
it will totally delegate to JAXB to generate the getUserResponse
type in the wsdl. Any chance you can try with the latest 2.1
snapshots (or wait till tomorrow/monday and try the ones I'll deploy
later today?)
Dan
By the way, I have also hit a problem where the response parts are
generated with incomplete result definitions. For example, if I
have a method in my SEI like:
@WebService(name = UserModule,
targetNamespace =
http://www.volantis.com/xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
User getUser(@WebParam(name=name) final String name);
...
}
where User is, for example, like this:
@XmlJavaTypeAdapter(UserAdapter.class)
public interface User {
String getName();
String getPassword();
}
with an implementation like:
@XmlType(name = User)
public class UserImpl implements User {
private String name;
private String password;
public void setName(final String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPassword(final String password) {
this.password = password;
}
public String getPassword() {
return password;
}
}
and the adapter looks like:
public final class UserAdapter extends
XmlAdapterUserImpl, User
Re: Problem generating WSDL from Java API with CXF 2.0.3
On Tuesday 26 February 2008, Phil Weighill-Smith wrote: That's the sort of answer I was looking for. Thanks, Phil :n) PS: Was this an RTFM moment?! I wish I could say the answer was yes... :-( I think most of our docs on the wiki at this point are more targetted toward the 2.0.x toolset (since 2.0.x is released). Dan - Original Message - From: Daniel Kulp [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Cc: Phil Weighill-Smith [EMAIL PROTECTED] Sent: Tue, 26 Feb 2008 11:25:16 -0700 (MST) Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3 On Monday 25 February 2008, Phil Weighill-Smith wrote: Dan, The exception happened with just using command line access - with long class paths ;n) Yes, I think we were getting the tooling from a 2.0.1 JAR remnant. But I couldn't find the tooling in the 2.1 snap...? Which tooling? The java2wsdl tool has been merged into the new java2ws tool which supports a bunch of new things. If you just want the wsdl, pass the -wsdl flag. Dan -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
Phil, I updated the docs for both java2wsdl and java2ws, so others won't have the same confusion. Sorry this happened to you. Glen Am Dienstag, den 26.02.2008, 13:42 -0500 schrieb Daniel Kulp: On Tuesday 26 February 2008, Phil Weighill-Smith wrote: That's the sort of answer I was looking for. Thanks, Phil :n) PS: Was this an RTFM moment?! I wish I could say the answer was yes... :-( I think most of our docs on the wiki at this point are more targetted toward the 2.0.x toolset (since 2.0.x is released). Dan - Original Message - From: Daniel Kulp [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Cc: Phil Weighill-Smith [EMAIL PROTECTED] Sent: Tue, 26 Feb 2008 11:25:16 -0700 (MST) Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3 On Monday 25 February 2008, Phil Weighill-Smith wrote: Dan, The exception happened with just using command line access - with long class paths ;n) Yes, I think we were getting the tooling from a 2.0.1 JAR remnant. But I couldn't find the tooling in the 2.1 snap...? Which tooling? The java2wsdl tool has been merged into the new java2ws tool which supports a bunch of new things. If you just want the wsdl, pass the -wsdl flag. Dan
Re: Problem generating WSDL from Java API with CXF 2.0.3
Dan,
I've tried out the 2.1 snapshot available today and found that the API has
changed in some way in CXF so now trying to generate a WSDL from Java code
gives:
Exception in thread main java.lang.NoSuchMethodError:
org.apache.cxf.tools.java2wsdl.processor.internal.ServiceBuilderFactory.newBuilder()Lorg/apache/cxf/service/ServiceBuilder;
at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.getServiceBuilder(JavaToProcessor.java:144)
at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.process(JavaToProcessor.java:87)
Note that this is both in the IDEA integration with CXF and via the command
line. The JDK I'm using is 1.6.0.03.
Any suggestions?
Phil :n.
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 22 February 2008 17:26:59 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
On Friday 22 February 2008, Phil Weighill-Smith wrote:
Dan, sorry it's been several weeks since you e-mailed this to me and
I've not actioned it. Where do I find CXF's official JIRA app?
https://issues.apache.org/jira/browse/CXF
That said, the namespace issue in the WrapperClassGenerator should be
fixed with the latest 2.1 snapshots. I'll probably be doing new
snapshots again today since I've fixed a TON of bugs over the last
couple days. That MAY also fix the other issues you note below as it
will totally delegate to JAXB to generate the getUserResponse type in
the wsdl. Any chance you can try with the latest 2.1 snapshots (or
wait till tomorrow/monday and try the ones I'll deploy later today?)
Dan
By the way, I have also hit a problem where the response parts are
generated with incomplete result definitions. For example, if I have a
method in my SEI like:
@WebService(name = UserModule,
targetNamespace =
http://www.volantis.com/xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
User getUser(@WebParam(name=name) final String name);
...
}
where User is, for example, like this:
@XmlJavaTypeAdapter(UserAdapter.class)
public interface User {
String getName();
String getPassword();
}
with an implementation like:
@XmlType(name = User)
public class UserImpl implements User {
private String name;
private String password;
public void setName(final String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPassword(final String password) {
this.password = password;
}
public String getPassword() {
return password;
}
}
and the adapter looks like:
public final class UserAdapter extends
XmlAdapterUserImpl, User {
@Override
public UserImpl marshal(final User user) throws Exception {
return (UserImpl) user;
}
@Override
public User unmarshal(final UserImpl user) throws Exception {
return user;
}
}
I get some WSDL like this:
wsdl:definitions name=UserModuleService
targetNamespace=http://com.volantis.openapi.mss.usermodule;
xmlns:ns1=http://www.volantis.com/xmlns/2008/01/mss/user-module;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://com.volantis.openapi.mss.usermodule;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; wsdl:types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns=http://www.volantis.com/xmlns/2008/01/mss/user-module;
attributeFormDefault=unqualified
elementFormDefault=unqualified
targetNamespace=http://www.volantis.com/xmlns/2008/01/mss/user-module
xs:element name=getUser type=getUser/
xs:complexType name=getUser
xs:sequence
xs:element minOccurs=0 name=name
type=xs:string/
/xs:sequence
/xs:complexType
xs:element name=getUserResponse
type=getUserResponse/ xs:complexType name=getUserResponse
xs:sequence
xs:element minOccurs=0 name=return/
/xs:sequence
/xs:complexType
...
/xs:schema
wsdl:types
...
wsdl:message name=getUser
wsdl:part name=parameters element=ns1:getUser
/wsdl:part
/wsdl:message
...
wsdl:message name=getUserResponse
wsdl:part name=parameters element=ns1:getUserResponse
/wsdl:part
/wsdl:message
...
wsdl:portType name=UserModule
wsdl:operation name=getUser
wsdl:input name=getUser message=ns1:getUser
/wsdl:input
wsdl:output name=getUserResponse
message=ns1
Re: Problem generating WSDL from Java API with CXF 2.0.3
Hmm..
Is this in maven or other build system? It looks like its picking up
some old jars someplace as the class:
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor
no longer even exists.
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK I'm using is 1.6.0.03.
If using 2.1 snapshot, you may want to flip to 1.6.0_04. 03 includes
the 2.0 JAXWS/JAXB API's which may cause issues with the 2.1 versions
that CXF 2.1 requires._04 includes the proper 2.1 versions and I
have gone through and made sure CXF builds and runs with _04.
Dan
On Monday 25 February 2008, Phil Weighill-Smith wrote:
I've tried out the 2.1 snapshot available today and found that the API
has changed in some way in CXF so now trying to generate a WSDL from
Java code gives:
Exception in thread main java.lang.NoSuchMethodError:
org.apache.cxf.tools.java2wsdl.processor.internal.ServiceBuilderFactor
y.newBuilder()Lorg/apache/cxf/service/ServiceBuilder; at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.getServiceBui
lder(JavaToProcessor.java:144) at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.process(JavaT
oProcessor.java:87)
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK I'm using is 1.6.0.03.
Any suggestions?
Phil :n.
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 22 February 2008 17:26:59 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
On Friday 22 February 2008, Phil Weighill-Smith wrote:
Dan, sorry it's been several weeks since you e-mailed this to me and
I've not actioned it. Where do I find CXF's official JIRA app?
https://issues.apache.org/jira/browse/CXF
That said, the namespace issue in the WrapperClassGenerator should be
fixed with the latest 2.1 snapshots. I'll probably be doing new
snapshots again today since I've fixed a TON of bugs over the last
couple days. That MAY also fix the other issues you note below as it
will totally delegate to JAXB to generate the getUserResponse type in
the wsdl. Any chance you can try with the latest 2.1 snapshots (or
wait till tomorrow/monday and try the ones I'll deploy later today?)
Dan
By the way, I have also hit a problem where the response parts are
generated with incomplete result definitions. For example, if I have
a method in my SEI like:
@WebService(name = UserModule,
targetNamespace =
http://www.volantis.com/xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
User getUser(@WebParam(name=name) final String name);
...
}
where User is, for example, like this:
@XmlJavaTypeAdapter(UserAdapter.class)
public interface User {
String getName();
String getPassword();
}
with an implementation like:
@XmlType(name = User)
public class UserImpl implements User {
private String name;
private String password;
public void setName(final String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPassword(final String password) {
this.password = password;
}
public String getPassword() {
return password;
}
}
and the adapter looks like:
public final class UserAdapter extends
XmlAdapterUserImpl, User {
@Override
public UserImpl marshal(final User user) throws Exception {
return (UserImpl) user;
}
@Override
public User unmarshal(final UserImpl user) throws Exception {
return user;
}
}
I get some WSDL like this:
wsdl:definitions name=UserModuleService
targetNamespace=http://com.volantis.openapi.mss.usermodule;
xmlns:ns1=http://www.volantis.com/xmlns/2008/01/mss/user-module;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://com.volantis.openapi.mss.usermodule;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; wsdl:types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns=http://www.volantis.com/xmlns/2008/01/mss/user-module;
attributeFormDefault=unqualified
elementFormDefault=unqualified
targetNamespace=http://www.volantis.com/xmlns/2008/01/mss/user-modu
le xs:element name=getUser type=getUser/
xs:complexType name=getUser
xs:sequence
xs:element minOccurs=0 name=name
type=xs:string/
/xs:sequence
/xs:complexType
xs:element name=getUserResponse
type=getUserResponse/ xs:complexType name=getUserResponse
Re: Problem generating WSDL from Java API with CXF 2.0.3
Dan, sorry it's been several weeks since you e-mailed this to me and
I've not actioned it. Where do I find CXF's official JIRA app?
By the way, I have also hit a problem where the response parts are
generated with incomplete result definitions. For example, if I have a
method in my SEI like:
@WebService(name = UserModule,
targetNamespace =
http://www.volantis.com/xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
User getUser(@WebParam(name=name) final String name);
...
}
where User is, for example, like this:
@XmlJavaTypeAdapter(UserAdapter.class)
public interface User {
String getName();
String getPassword();
}
with an implementation like:
@XmlType(name = User)
public class UserImpl implements User {
private String name;
private String password;
public void setName(final String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPassword(final String password) {
this.password = password;
}
public String getPassword() {
return password;
}
}
and the adapter looks like:
public final class UserAdapter extends
XmlAdapterUserImpl, User {
@Override
public UserImpl marshal(final User user) throws Exception {
return (UserImpl) user;
}
@Override
public User unmarshal(final UserImpl user) throws Exception {
return user;
}
}
I get some WSDL like this:
wsdl:definitions name=UserModuleService
targetNamespace=http://com.volantis.openapi.mss.usermodule;
xmlns:ns1=http://www.volantis.com/xmlns/2008/01/mss/user-module;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://com.volantis.openapi.mss.usermodule;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
wsdl:types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns=http://www.volantis.com/xmlns/2008/01/mss/user-module;
attributeFormDefault=unqualified
elementFormDefault=unqualified
targetNamespace=http://www.volantis.com/xmlns/2008/01/mss/user-module;
xs:element name=getUser type=getUser/
xs:complexType name=getUser
xs:sequence
xs:element minOccurs=0 name=name
type=xs:string/
/xs:sequence
/xs:complexType
xs:element name=getUserResponse type=getUserResponse/
xs:complexType name=getUserResponse
xs:sequence
xs:element minOccurs=0 name=return/
/xs:sequence
/xs:complexType
...
/xs:schema
wsdl:types
...
wsdl:message name=getUser
wsdl:part name=parameters element=ns1:getUser
/wsdl:part
/wsdl:message
...
wsdl:message name=getUserResponse
wsdl:part name=parameters element=ns1:getUserResponse
/wsdl:part
/wsdl:message
...
wsdl:portType name=UserModule
wsdl:operation name=getUser
wsdl:input name=getUser message=ns1:getUser
/wsdl:input
wsdl:output name=getUserResponse message=ns1:getUserResponse
/wsdl:output
/wsdl:operation
...
/wsdl:portType
wsdl:binding name=UserModuleServiceSoapBinding type=ns1:UserModule
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getUser
soap:operation soapAction= style=document/
wsdl:input name=getUser
soap:body use=literal/
/wsdl:input
wsdl:output name=getUserResponse
soap:body use=literal/
/wsdl:output
/wsdl:operation
...
/wsdl:binding
wsdl:service name=UserModuleService
wsdl:port name=UserModulePort
binding=ns1:UserModuleServiceSoapBinding
soap:address location=http://localhost:9090/mss/
/wsdl:port
/wsdl:service
/wsdl:definitions
As you can see, the (bolded) return element has no type, and I get no
XSD element or type definition for the User implementation for some
reason. Any ideas?
Phil :n.
On Fri, 2008-02-01 at 22:26 -0500, Daniel Kulp wrote:
This is definitely a bug and I see where the improper code is found.
Line 202 of WrapperClassGenerator specifically sets the namespace to
for the generated class. This needs to be updated to either not output
it or output the correct namespace. I'll need to experiment a bit to
figure out which.
Can you log a JIRA (feel free to assign to me) so it gets tracked. (I'm
busy with other stuff for the next couple
Re: Problem generating WSDL from Java API with CXF 2.0.3
On Friday 22 February 2008, Phil Weighill-Smith wrote:
Dan, sorry it's been several weeks since you e-mailed this to me and
I've not actioned it. Where do I find CXF's official JIRA app?
https://issues.apache.org/jira/browse/CXF
That said, the namespace issue in the WrapperClassGenerator should be
fixed with the latest 2.1 snapshots. I'll probably be doing new
snapshots again today since I've fixed a TON of bugs over the last
couple days. That MAY also fix the other issues you note below as it
will totally delegate to JAXB to generate the getUserResponse type in
the wsdl. Any chance you can try with the latest 2.1 snapshots (or
wait till tomorrow/monday and try the ones I'll deploy later today?)
Dan
By the way, I have also hit a problem where the response parts are
generated with incomplete result definitions. For example, if I have a
method in my SEI like:
@WebService(name = UserModule,
targetNamespace =
http://www.volantis.com/xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
User getUser(@WebParam(name=name) final String name);
...
}
where User is, for example, like this:
@XmlJavaTypeAdapter(UserAdapter.class)
public interface User {
String getName();
String getPassword();
}
with an implementation like:
@XmlType(name = User)
public class UserImpl implements User {
private String name;
private String password;
public void setName(final String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPassword(final String password) {
this.password = password;
}
public String getPassword() {
return password;
}
}
and the adapter looks like:
public final class UserAdapter extends
XmlAdapterUserImpl, User {
@Override
public UserImpl marshal(final User user) throws Exception {
return (UserImpl) user;
}
@Override
public User unmarshal(final UserImpl user) throws Exception {
return user;
}
}
I get some WSDL like this:
wsdl:definitions name=UserModuleService
targetNamespace=http://com.volantis.openapi.mss.usermodule;
xmlns:ns1=http://www.volantis.com/xmlns/2008/01/mss/user-module;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://com.volantis.openapi.mss.usermodule;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; wsdl:types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns=http://www.volantis.com/xmlns/2008/01/mss/user-module;
attributeFormDefault=unqualified
elementFormDefault=unqualified
targetNamespace=http://www.volantis.com/xmlns/2008/01/mss/user-module
xs:element name=getUser type=getUser/
xs:complexType name=getUser
xs:sequence
xs:element minOccurs=0 name=name
type=xs:string/
/xs:sequence
/xs:complexType
xs:element name=getUserResponse
type=getUserResponse/ xs:complexType name=getUserResponse
xs:sequence
xs:element minOccurs=0 name=return/
/xs:sequence
/xs:complexType
...
/xs:schema
wsdl:types
...
wsdl:message name=getUser
wsdl:part name=parameters element=ns1:getUser
/wsdl:part
/wsdl:message
...
wsdl:message name=getUserResponse
wsdl:part name=parameters element=ns1:getUserResponse
/wsdl:part
/wsdl:message
...
wsdl:portType name=UserModule
wsdl:operation name=getUser
wsdl:input name=getUser message=ns1:getUser
/wsdl:input
wsdl:output name=getUserResponse
message=ns1:getUserResponse /wsdl:output
/wsdl:operation
...
/wsdl:portType
wsdl:binding name=UserModuleServiceSoapBinding
type=ns1:UserModule soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/ wsdl:operation
name=getUser
soap:operation soapAction= style=document/
wsdl:input name=getUser
soap:body use=literal/
/wsdl:input
wsdl:output name=getUserResponse
soap:body use=literal/
/wsdl:output
/wsdl:operation
...
/wsdl:binding
wsdl:service name=UserModuleService
wsdl:port name=UserModulePort
binding=ns1:UserModuleServiceSoapBinding
soap:address location=http://localhost:9090/mss/
/wsdl:port
/wsdl:service
/wsdl:definitions
As you can see, the (bolded) return element has no type, and I get
no XSD element or type
Re: Problem generating WSDL from Java API with CXF 2.0.3
I'll get hold of the snapshots on Monday and try it out then. Thanks.
Phil :n)
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 22 February 2008 17:26:59 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
On Friday 22 February 2008, Phil Weighill-Smith wrote:
Dan, sorry it's been several weeks since you e-mailed this to me and
I've not actioned it. Where do I find CXF's official JIRA app?
https://issues.apache.org/jira/browse/CXF
That said, the namespace issue in the WrapperClassGenerator should be
fixed with the latest 2.1 snapshots. I'll probably be doing new
snapshots again today since I've fixed a TON of bugs over the last
couple days. That MAY also fix the other issues you note below as it
will totally delegate to JAXB to generate the getUserResponse type in
the wsdl. Any chance you can try with the latest 2.1 snapshots (or
wait till tomorrow/monday and try the ones I'll deploy later today?)
Dan
By the way, I have also hit a problem where the response parts are
generated with incomplete result definitions. For example, if I have a
method in my SEI like:
@WebService(name = UserModule,
targetNamespace =
http://www.volantis.com/xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
User getUser(@WebParam(name=name) final String name);
...
}
where User is, for example, like this:
@XmlJavaTypeAdapter(UserAdapter.class)
public interface User {
String getName();
String getPassword();
}
with an implementation like:
@XmlType(name = User)
public class UserImpl implements User {
private String name;
private String password;
public void setName(final String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPassword(final String password) {
this.password = password;
}
public String getPassword() {
return password;
}
}
and the adapter looks like:
public final class UserAdapter extends
XmlAdapterUserImpl, User {
@Override
public UserImpl marshal(final User user) throws Exception {
return (UserImpl) user;
}
@Override
public User unmarshal(final UserImpl user) throws Exception {
return user;
}
}
I get some WSDL like this:
wsdl:definitions name=UserModuleService
targetNamespace=http://com.volantis.openapi.mss.usermodule;
xmlns:ns1=http://www.volantis.com/xmlns/2008/01/mss/user-module;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://com.volantis.openapi.mss.usermodule;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; wsdl:types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns=http://www.volantis.com/xmlns/2008/01/mss/user-module;
attributeFormDefault=unqualified
elementFormDefault=unqualified
targetNamespace=http://www.volantis.com/xmlns/2008/01/mss/user-module
xs:element name=getUser type=getUser/
xs:complexType name=getUser
xs:sequence
xs:element minOccurs=0 name=name
type=xs:string/
/xs:sequence
/xs:complexType
xs:element name=getUserResponse
type=getUserResponse/ xs:complexType name=getUserResponse
xs:sequence
xs:element minOccurs=0 name=return/
/xs:sequence
/xs:complexType
...
/xs:schema
wsdl:types
...
wsdl:message name=getUser
wsdl:part name=parameters element=ns1:getUser
/wsdl:part
/wsdl:message
...
wsdl:message name=getUserResponse
wsdl:part name=parameters element=ns1:getUserResponse
/wsdl:part
/wsdl:message
...
wsdl:portType name=UserModule
wsdl:operation name=getUser
wsdl:input name=getUser message=ns1:getUser
/wsdl:input
wsdl:output name=getUserResponse
message=ns1:getUserResponse /wsdl:output
/wsdl:operation
...
/wsdl:portType
wsdl:binding name=UserModuleServiceSoapBinding
type=ns1:UserModule soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/ wsdl:operation
name=getUser
soap:operation soapAction= style=document/
wsdl:input name=getUser
soap:body use=literal/
/wsdl:input
wsdl:output name=getUserResponse
soap:body use=literal/
/wsdl:output
/wsdl:operation
...
/wsdl:binding
wsdl:service
Re: Problem generating WSDL from Java API with CXF 2.0.3
Regarding target namespace and the elementFormDefault issues...
Interestingly the package-info.java approach doesn't seem to work.
Whilst this sets the default element form to qualified, each element is
then generated with the form=unqualified attribute set. D'oh! I guess
I'll have to use the XmlElement approach. Will let you know what
happens.
I've also set the XmlSchema namespace as you have suggested, and have
explicitly set the @WebService(targetNamespace) to the same value but I
still get a WSDL targetNamespace derived from the package name. How do I
override this behaviour?
The package-info.java has:
@javax.xml.bind.annotation.XmlSchema(
namespace = http://com.volantis.xmlns/2008/01/mss/user-module;,
elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
package com.volantis.openapi.mss.usermodule;
and the SEI interface has:
@WebService(name = UserModule,
targetNamespace =
http://com.volantis.xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
...
ListUser getSubscribers(
@WebParam(name = application)
final String applicationID,
@WebParam(name = subscription)
final String subscriptionID,
@WebParam(name = includeExtensionParameters)
final boolean includeExtensionParameters,
@WebParam(name = includeSubscriptions)
final boolean includeSubscriptions) throws PersistenceException;
...
but the WSDL is generated with:
wsdl:definitions name=UserModuleService
targetNamespace=http://com.volantis.openapi.mss.usermodule;
xmlns:ns1=http://com.volantis.xmlns/2008/01/mss/user-module;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://com.volantis.openapi.mss.usermodule;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
wsdl:types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:tns=http://com.volantis.xmlns/2008/01/mss/user-module;
attributeFormDefault=unqualified
elementFormDefault=qualified
targetNamespace=http://com.volantis.xmlns/2008/01/mss/user-module;
...
xs:complexType name=getSubscribersResponse
xs:sequence
xs:element form=unqualified maxOccurs=unbounded
minOccurs=0 name=return type=xs:anyType/
/xs:sequence
/xs:complexType
...
/xs:schema
/wsdl:types
wsdl:message name=getSubscribersResponse
wsdl:part name=parameters element=ns1:getSubscribersResponse
/wsdl:part
/wsdl:message
...
What I want to see is:
* the WSDL targetNamespace matching the ns1 URI
* the elements generated with form qualified
* the sequence returned by getSubscribersResponse using the
generated schema type for User.
Any suggestions?
Phil :n(
On Mon, 2008-01-28 at 10:31 -0500, Daniel Kulp wrote:
2) Create a package-info.java class in the package containing the
beans.
It would look like:
@javax.xml.bind.annotation.XmlSchema(
namespace = http://the.namespace.to.use;,
elementFormDefault =
javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
package the package;
RE: Problem generating WSDL from Java API with CXF 2.0.3
Marc,
I've not tried a List it must be said. I know JAXB has built-in support
for this type of collection. I'm just rather surprised it doesn't cope
well with arrays (it probably does OK when not using an
XmlJavaTypeAdapter...).
Further, I've found that, even though I've used @XmlJavaTypeAdapter
against each of my API interfaces, I've had to explicitly re-annotate
usages of these interfaces nested within each other... like this:
@XmlJavaTypeAdapter(AAdapter.class)
public interface A {
B getB();
}
@XmlJavaTypeAdapter(BAdapter.class)
public interface B {
String getString();
}
// Implementation used in the AAdapter
public class AImpl implements A {
@XmlJavaTypeAdapter(BAdapter.class)
public B getB() { ... }
}
This seems likely a bug in the JAXB implementation, given what the JAXB
1.4 specification says:
12/11/06 JAXB 2.1 Final Release 284 A @XmlJavaTypeAdapter that
extends XmlAdapter valueType, boundType and is specified on
the class, interface or Enum type (i.e. on a program element
that matches meta annotation @Target={type}) must adapt
boundType at the point of reference as follows:
1. a property/field whose reference type is boundType. For e.g.
// Foo will be adapted to MyFoo
Foo foo;
2. a property/field where boundType is used as a parametric
type. For e.g.
// ListFoo will be adapted to ListMyFoo
ListFoo foo;
On Mon, 2008-01-28 at 15:45 -0500, Cobery, Marc wrote:
Hi,
Have you tried using a List instead of an array for your return value?
Do you have a demo project that I could reference?
I have tried the annotation of interfaces and have had it work sporadically.
I just received a org.apache.cxf.interceptor.Fault: Marshalling Error:
com.rulestream.core.knowledge.domain.MyClass is not known to this context
exception.
Before this exception, I could not initialize the web service.
Regards,
Marc
-Original Message-
From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
Sent: Monday, January 28, 2008 12:20 PM
To: Daniel Kulp
Cc: cxf-user@incubator.apache.org
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
Dan,
What I've found so far is that I can declare myself a new adapter, e.g.:
public final class SimpleThingArrayAdapter extends
XmlAdapterSimpleThingImpl[], SimpleThing[] {
@Override
public SimpleThingImpl[] marshal(SimpleThing[] simpleThings)
throws Exception {
if (simpleThings instanceof SimpleThingImpl[]) {
return (SimpleThingImpl[]) simpleThings;
} else {
SimpleThingImpl[] result =
new SimpleThingImpl[simpleThings.length];
System.arraycopy(simpleThings, 0,
result, 0,
simpleThings.length);
return result;
}
}
@Override
public SimpleThing[] unmarshal(SimpleThingImpl[] simpleThings)
throws Exception {
return simpleThings;
}
}
and then assign this against the web method, e.g.:
@WebResult(name = result,
targetNamespace = Namespace.URI)
@XmlJavaTypeAdapter(type = SimpleThing[].class, value =
org.bad.jaxb.SimpleThingArrayAdapter.class)
SimpleThing[] getThingsThatMatch(
@WebParam(name = namePattern)
final String namePattern);
This then gets rid of the error... I think. Not finished sorting this
out though...
If I hit a dead end I'll look see if 2.1 helps.
Thanks again,
Phil :n.
On Mon, 2008-01-28 at 11:41 -0500, Daniel Kulp wrote:
On Monday 28 January 2008, Phil Weighill-Smith wrote:
I'm trying to apply the pattern I described earlier to my real world
scenario. The problem I haven't figured out a way round is when I have
parameters and return types based on arrays of the interfaces. I get
an annotation error with JAXB complaining it can't handle interfaces
(despite having the required @XmlJavaTypeAdapter against the interface
itself). I've tried repeating the @XmlJavaTypeAdapter definition as
part of the web method signature but that doesn't seem to work.
That will only work with JAX-WS 2.1 and thus CXF 2.1 snapshots. And even
then I'm not sure if we have that working in the snapshots yet.
Not sure what to suggest. I'm wondering if it's not finding the impl
that goes with it. With 2.1, I'd suggest adding an @XmlSeeAlso
annotation to make sure the impl gets pulled in. Maybe try a
jaxb.index file in the package that just has the line SimpleThinkImpl
or similar to make sure the impl gets sucked into the context creation.
It might just be a bug in jaxb. I'd honestly suggest trying with the
CXF 2.1 snapshots to see if it works there. 2.1 uses the latest JAXB
2.1
Re: Problem generating WSDL from Java API with CXF 2.0.3
Any chance you could turn on FINE level logging?At least for the
org.apache.cxf.jaxb.JAXBDataBinding Logger?
It should log the list of classes that it is using to create the context.
I'd like to see what it thinks is in there.
Also, can you create a JIRA and attach a test case? I can definitely
dig into it easier then.
Thanks!
Dan
On Monday 28 January 2008, Cobery, Marc wrote:
Hi,
I have just switched to the 2.1 snapshot. The unmarshalling works
fine with an interface that is annotated and used as a WebParam, but
the marshalling fails for that same annotated interface if used as a
WebResult. The inbound message is bound correctly but the outbound
message is not. The failure is: Marshalling Error:
com.rulestream.core.knowledge.domain.ClassDef is not known to this
context
Is there anything I can do to set the context in the configuration? I
am using Java first development with annotations and jaxb.index files.
My JAXB marshalling and unmarshalling outside of CXF works fine.
Definition in my interface for the service:
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@WebResult(targetNamespace = http://core.rulestream.com;,
partName = parameters, name = classDef) @WebMethod(operationName =
retrieve)
public ClassDef retrieve(@WebParam(targetNamespace =
http://core.rulestream.com;, partName = parameters,name =
classDef) ClassDef cd);
Implementation of the service:
public ClassDef retrieve( ClassDef cd)
{
//if method returns Boolean then there is no problem
boolean b = cd.getName() != null;
logger.debug(USING INTERFACES!);
logger.debug(IN THE WS CALL save());
logger.debug(the class def uuid is:
+ (cd == null ? NULL : cd.getUuid()));
logger.debug(the class def name is:
+ (cd == null ? NULL : cd.getName()));
Date dt = new Date();
cd.setName(cd.getName()+dt.getTime());
cd.setCreationTime(dt);
//return b;
return cd;
}
Here is the configuration of the service:
jaxws:endpoint name=classDefService
address=/ClassDefService
serviceName=t:classDefService
xmlns:t=http://core.rulestream.com;
implementor=com.rulestream.services.knowledge.ws.impl.ClassDefService
Impl jaxws:features
bean class=org.apache.cxf.feature.LoggingFeature/
/jaxws:features
/jaxws:endpoint
Thanks for any help.
Regards,
Marc
-Original Message-
From: Cobery, Marc [mailto:[EMAIL PROTECTED]
Sent: Monday, January 28, 2008 3:45 PM
To: cxf-user@incubator.apache.org; [EMAIL PROTECTED];
Daniel Kulp Subject: RE: Problem generating WSDL from Java API with
CXF 2.0.3
Hi,
Have you tried using a List instead of an array for your return value?
Do you have a demo project that I could reference?
I have tried the annotation of interfaces and have had it work
sporadically. I just received a org.apache.cxf.interceptor.Fault:
Marshalling Error: com.rulestream.core.knowledge.domain.MyClass is not
known to this context exception. Before this exception, I could not
initialize the web service.
Regards,
Marc
-Original Message-
From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
Sent: Monday, January 28, 2008 12:20 PM
To: Daniel Kulp
Cc: cxf-user@incubator.apache.org
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
Dan,
What I've found so far is that I can declare myself a new adapter,
e.g.:
public final class SimpleThingArrayAdapter extends
XmlAdapterSimpleThingImpl[], SimpleThing[] {
@Override
public SimpleThingImpl[] marshal(SimpleThing[] simpleThings)
throws Exception {
if (simpleThings instanceof SimpleThingImpl[]) {
return (SimpleThingImpl[]) simpleThings;
} else {
SimpleThingImpl[] result =
new SimpleThingImpl[simpleThings.length];
System.arraycopy(simpleThings, 0,
result, 0,
simpleThings.length);
return result;
}
}
@Override
public SimpleThing[] unmarshal(SimpleThingImpl[] simpleThings)
throws Exception {
return simpleThings;
}
}
and then assign this against the web method, e.g.:
@WebResult(name = result,
targetNamespace = Namespace.URI)
@XmlJavaTypeAdapter(type = SimpleThing[].class, value =
org.bad.jaxb.SimpleThingArrayAdapter.class) SimpleThing[]
getThingsThatMatch(
@WebParam(name = namePattern)
final String namePattern);
This then gets rid of the error... I think. Not finished sorting this
out though...
If I hit a dead end I'll look see if 2.1 helps.
Thanks again,
Phil :n
Re: Problem generating WSDL from Java API with CXF 2.0.3
Dan/anyone else,
I've got further (not sure if it will actually work with JAXB
marshalling and unmarshalling, will find out later today) whilst still
using interfaces as part of my API - the WSDL now looks more-or-less OK.
The extra steps I've taken, as previously partially outlined, are to:
* provide a simple implementation of the interface, but one that
supplies setters too
* provide an XmlJavaTypeAdapter annotation against the SimpleThing
interface, and supply the XmlAdapter implementation to adapt
between the interface and the simple mutable implementation
* annotate the implementation to set the XmlType name to the
interface name so the WSDL looks sensible
So my SEI looks unchanged, but the following is added/modified:
/**
* A simple thing to communicate over the web service.
*/
@XmlJavaTypeAdapter(SimpleThingAdapter.class)
public interface SimpleThing {
...
Plus:
/**
* Simple but mutable implementation of [EMAIL PROTECTED] SimpleThing}.
*/
@XmlType(name = SimpleThing)
public class SimpleThingImpl implements SimpleThing {
// The name of this instance
private String name;
// The description of this instance
private String description;
@Override
public String getName() {
return name;
}
/**
* Sets or resets the name of this instance.
*
* @param name the new value for the name
*/
public void setName(final String name) {
this.name = name;
}
@Override
public String getDescription() {
return description;
}
/**
* Sets or resets the description for this instance.
*
* @param description the new value for the description
*/
public void setDescription(final String description) {
this.description = description;
}
}
And finally:
class SimpleThingAdapter extends XmlAdapterSimpleThingImpl, SimpleThing {
@Override
public SimpleThingImpl marshal(SimpleThing simpleThing)
throws Exception {
return (SimpleThingImpl) simpleThing;
}
@Override
public SimpleThing unmarshal(SimpleThingImpl simpleThing)
throws Exception {
return simpleThing;
}
}
With a Document, Literal, Wrapped binding I get the following WSDL:
?xml version=1.0 encoding=UTF-8?
wsdl:definitions name=SimpleServiceService targetNamespace=http://org.bad;
xmlns:ns1=http://org.bad.SimpleService/service;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://org.bad;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
wsdl:types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:tns=http://org.bad.SimpleService/service;
attributeFormDefault=unqualified
elementFormDefault=unqualified
targetNamespace=http://org.bad.SimpleService/service;
xs:element name=getThing type=tns:getThing/
xs:element name=getThingResponse type=tns:getThingResponse/
xs:complexType name=getThing
xs:sequence
xs:element minOccurs=0 name=name type=xs:string/
/xs:sequence
/xs:complexType
xs:complexType name=getThingResponse
xs:sequence
xs:element minOccurs=0 name=result
type=tns:SimpleThing/
/xs:sequence
/xs:complexType
xs:complexType name=SimpleThing
xs:sequence
xs:element minOccurs=0 name=description
type=xs:string/
xs:element minOccurs=0 name=name type=xs:string/
/xs:sequence
/xs:complexType
/xs:schema
/wsdl:types
wsdl:message name=getThing
wsdl:part name=parameters element=ns1:getThing
/wsdl:part
/wsdl:message
wsdl:message name=getThingResponse
wsdl:part name=parameters element=ns1:getThingResponse
/wsdl:part
/wsdl:message
wsdl:portType name=SimpleService
wsdl:operation name=getThing
wsdl:input name=getThing message=ns1:getThing
/wsdl:input
wsdl:output name=getThingResponse
message=ns1:getThingResponse
/wsdl:output
/wsdl:operation
/wsdl:portType
wsdl:binding name=SimpleServiceServiceSoapBinding
type=ns1:SimpleService
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getThing
soap:operation soapAction= style=document/
wsdl:input name=getThing
soap:body use=literal/
/wsdl:input
wsdl:output
Re: Problem generating WSDL from Java API with CXF 2.0.3
That's very cool. This is something I'd actually like to see a complete
project/build/example for as a tutorial or something if you can get it
working.
* whether the various parameters and results can be null (i.e.
I would like to change the minOccurs=0 to minOccurs=1 - the
default for XML Schema)
In the SimpleThingImpl, on the getters or on the fields, add:
@XmlElement(required = true)
* ensuring that the generated complex types have all elements in
the required namespace (the schema has elementFormDefault as
unqualified, whilst I'd like them to be qualified)
Two options:
1) And @XmlElement annotations to everything and fill in namespaces for
them
2) Create a package-info.java class in the package containing the beans.
It would look like:
@javax.xml.bind.annotation.XmlSchema(
namespace = http://the.namespace.to.use;,
elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
package the package;
* ensuring the WSDL contains appropriate documentation.
THAT is something I don't know if it's possible. You'd probably have to
ask on the JAXB list about that.
Dan
Any ideas how to address these?
On Monday 28 January 2008, Phil Weighill-Smith wrote:
Dan/anyone else,
I've got further (not sure if it will actually work with JAXB
marshalling and unmarshalling, will find out later today) whilst still
using interfaces as part of my API - the WSDL now looks more-or-less
OK.
The extra steps I've taken, as previously partially outlined, are to:
* provide a simple implementation of the interface, but one
that supplies setters too
* provide an XmlJavaTypeAdapter annotation against the
SimpleThing interface, and supply the XmlAdapter implementation to
adapt between the interface and the simple mutable implementation *
annotate the implementation to set the XmlType name to the interface
name so the WSDL looks sensible
So my SEI looks unchanged, but the following is added/modified:
/**
* A simple thing to communicate over the web service.
*/
@XmlJavaTypeAdapter(SimpleThingAdapter.class)
public interface SimpleThing {
...
Plus:
/**
* Simple but mutable implementation of [EMAIL PROTECTED] SimpleThing}.
*/
@XmlType(name = SimpleThing)
public class SimpleThingImpl implements SimpleThing {
// The name of this instance
private String name;
// The description of this instance
private String description;
@Override
public String getName() {
return name;
}
/**
* Sets or resets the name of this instance.
*
* @param name the new value for the name
*/
public void setName(final String name) {
this.name = name;
}
@Override
public String getDescription() {
return description;
}
/**
* Sets or resets the description for this instance.
*
* @param description the new value for the description
*/
public void setDescription(final String description) {
this.description = description;
}
}
And finally:
class SimpleThingAdapter extends XmlAdapterSimpleThingImpl,
SimpleThing { @Override
public SimpleThingImpl marshal(SimpleThing simpleThing)
throws Exception {
return (SimpleThingImpl) simpleThing;
}
@Override
public SimpleThing unmarshal(SimpleThingImpl simpleThing)
throws Exception {
return simpleThing;
}
}
With a Document, Literal, Wrapped binding I get the following WSDL:
?xml version=1.0 encoding=UTF-8?
wsdl:definitions name=SimpleServiceService
targetNamespace=http://org.bad;
xmlns:ns1=http://org.bad.SimpleService/service;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://org.bad;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
wsdl:types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:tns=http://org.bad.SimpleService/service;
attributeFormDefault=unqualified
elementFormDefault=unqualified
targetNamespace=http://org.bad.SimpleService/service; xs:element
name=getThing type=tns:getThing/ xs:element
name=getThingResponse type=tns:getThingResponse/ xs:complexType
name=getThing
xs:sequence
xs:element minOccurs=0 name=name
type=xs:string/ /xs:sequence
/xs:complexType
xs:complexType name=getThingResponse
xs:sequence
xs:element minOccurs=0 name=result
type=tns:SimpleThing/
/xs:sequence
/xs:complexType
xs:complexType name=SimpleThing
xs:sequence
xs:element minOccurs=0 name=description
Re: Problem generating WSDL from Java API with CXF 2.0.3
Dan,
Thanks again for your useful guidance.
I'm trying to apply the pattern I described earlier to my real world
scenario. The problem I haven't figured out a way round is when I have
parameters and return types based on arrays of the interfaces. I get an
annotation error with JAXB complaining it can't handle interfaces
(despite having the required @XmlJavaTypeAdapter against the interface
itself). I've tried repeating the @XmlJavaTypeAdapter definition as part
of the web method signature but that doesn't seem to work.
Do I need to provide an adapter for the array type? (I'll give that a
try, I guess.)
Phil :n(
PS: If I ever find time, I'm sure I could extend the SimpleService
example to cover these awkward aspects and to get it to a working
example state... don't hold your breath though! ;n)
On Mon, 2008-01-28 at 10:31 -0500, Daniel Kulp wrote:
That's very cool. This is something I'd actually like to see a complete
project/build/example for as a tutorial or something if you can get it
working.
* whether the various parameters and results can be null (i.e.
I would like to change the minOccurs=0 to minOccurs=1 - the
default for XML Schema)
In the SimpleThingImpl, on the getters or on the fields, add:
@XmlElement(required = true)
* ensuring that the generated complex types have all elements in
the required namespace (the schema has elementFormDefault as
unqualified, whilst I'd like them to be qualified)
Two options:
1) And @XmlElement annotations to everything and fill in namespaces for
them
2) Create a package-info.java class in the package containing the beans.
It would look like:
@javax.xml.bind.annotation.XmlSchema(
namespace = http://the.namespace.to.use;,
elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
package the package;
* ensuring the WSDL contains appropriate documentation.
THAT is something I don't know if it's possible. You'd probably have to
ask on the JAXB list about that.
Dan
Any ideas how to address these?
On Monday 28 January 2008, Phil Weighill-Smith wrote:
Dan/anyone else,
I've got further (not sure if it will actually work with JAXB
marshalling and unmarshalling, will find out later today) whilst still
using interfaces as part of my API - the WSDL now looks more-or-less
OK.
The extra steps I've taken, as previously partially outlined, are to:
* provide a simple implementation of the interface, but one
that supplies setters too
* provide an XmlJavaTypeAdapter annotation against the
SimpleThing interface, and supply the XmlAdapter implementation to
adapt between the interface and the simple mutable implementation *
annotate the implementation to set the XmlType name to the interface
name so the WSDL looks sensible
So my SEI looks unchanged, but the following is added/modified:
/**
* A simple thing to communicate over the web service.
*/
@XmlJavaTypeAdapter(SimpleThingAdapter.class)
public interface SimpleThing {
...
Plus:
/**
* Simple but mutable implementation of [EMAIL PROTECTED] SimpleThing}.
*/
@XmlType(name = SimpleThing)
public class SimpleThingImpl implements SimpleThing {
// The name of this instance
private String name;
// The description of this instance
private String description;
@Override
public String getName() {
return name;
}
/**
* Sets or resets the name of this instance.
*
* @param name the new value for the name
*/
public void setName(final String name) {
this.name = name;
}
@Override
public String getDescription() {
return description;
}
/**
* Sets or resets the description for this instance.
*
* @param description the new value for the description
*/
public void setDescription(final String description) {
this.description = description;
}
}
And finally:
class SimpleThingAdapter extends XmlAdapterSimpleThingImpl,
SimpleThing { @Override
public SimpleThingImpl marshal(SimpleThing simpleThing)
throws Exception {
return (SimpleThingImpl) simpleThing;
}
@Override
public SimpleThing unmarshal(SimpleThingImpl simpleThing)
throws Exception {
return simpleThing;
}
}
With a Document, Literal, Wrapped binding I get the following WSDL:
?xml version=1.0 encoding=UTF-8?
wsdl:definitions name=SimpleServiceService
targetNamespace=http://org.bad;
xmlns:ns1=http://org.bad.SimpleService/service;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://org.bad;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
RE: Problem generating WSDL from Java API with CXF 2.0.3
Hi,
I have just switched to the 2.1 snapshot. The unmarshalling works fine with an
interface that is annotated and used as a WebParam, but the marshalling fails
for that same annotated interface if used as a WebResult. The inbound message
is bound correctly but the outbound message is not. The failure is:
Marshalling Error: com.rulestream.core.knowledge.domain.ClassDef is not known
to this context
Is there anything I can do to set the context in the configuration? I am using
Java first development with annotations and jaxb.index files. My JAXB
marshalling and unmarshalling outside of CXF works fine.
Definition in my interface for the service:
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@WebResult(targetNamespace = http://core.rulestream.com;, partName =
parameters, name = classDef)
@WebMethod(operationName = retrieve)
public ClassDef retrieve(@WebParam(targetNamespace =
http://core.rulestream.com;, partName = parameters,name = classDef)
ClassDef cd);
Implementation of the service:
public ClassDef retrieve( ClassDef cd)
{
//if method returns Boolean then there is no problem
boolean b = cd.getName() != null;
logger.debug(USING INTERFACES!);
logger.debug(IN THE WS CALL save());
logger.debug(the class def uuid is:
+ (cd == null ? NULL : cd.getUuid()));
logger.debug(the class def name is:
+ (cd == null ? NULL : cd.getName()));
Date dt = new Date();
cd.setName(cd.getName()+dt.getTime());
cd.setCreationTime(dt);
//return b;
return cd;
}
Here is the configuration of the service:
jaxws:endpoint name=classDefService
address=/ClassDefService
serviceName=t:classDefService
xmlns:t=http://core.rulestream.com;
implementor=com.rulestream.services.knowledge.ws.impl.ClassDefServiceImpl
jaxws:features
bean class=org.apache.cxf.feature.LoggingFeature/
/jaxws:features
/jaxws:endpoint
Thanks for any help.
Regards,
Marc
-Original Message-
From: Cobery, Marc [mailto:[EMAIL PROTECTED]
Sent: Monday, January 28, 2008 3:45 PM
To: cxf-user@incubator.apache.org; [EMAIL PROTECTED]; Daniel Kulp
Subject: RE: Problem generating WSDL from Java API with CXF 2.0.3
Hi,
Have you tried using a List instead of an array for your return value?
Do you have a demo project that I could reference?
I have tried the annotation of interfaces and have had it work sporadically. I
just received a org.apache.cxf.interceptor.Fault: Marshalling Error:
com.rulestream.core.knowledge.domain.MyClass is not known to this context
exception.
Before this exception, I could not initialize the web service.
Regards,
Marc
-Original Message-
From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
Sent: Monday, January 28, 2008 12:20 PM
To: Daniel Kulp
Cc: cxf-user@incubator.apache.org
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
Dan,
What I've found so far is that I can declare myself a new adapter, e.g.:
public final class SimpleThingArrayAdapter extends
XmlAdapterSimpleThingImpl[], SimpleThing[] {
@Override
public SimpleThingImpl[] marshal(SimpleThing[] simpleThings)
throws Exception {
if (simpleThings instanceof SimpleThingImpl[]) {
return (SimpleThingImpl[]) simpleThings;
} else {
SimpleThingImpl[] result =
new SimpleThingImpl[simpleThings.length];
System.arraycopy(simpleThings, 0,
result, 0,
simpleThings.length);
return result;
}
}
@Override
public SimpleThing[] unmarshal(SimpleThingImpl[] simpleThings)
throws Exception {
return simpleThings;
}
}
and then assign this against the web method, e.g.:
@WebResult(name = result,
targetNamespace = Namespace.URI)
@XmlJavaTypeAdapter(type = SimpleThing[].class, value =
org.bad.jaxb.SimpleThingArrayAdapter.class)
SimpleThing[] getThingsThatMatch(
@WebParam(name = namePattern)
final String namePattern);
This then gets rid of the error... I think. Not finished sorting this
out though...
If I hit a dead end I'll look see if 2.1 helps.
Thanks again,
Phil :n.
On Mon, 2008-01-28 at 11:41 -0500, Daniel Kulp wrote:
On Monday 28 January 2008, Phil Weighill-Smith wrote:
I'm trying to apply the pattern I described earlier to my real world
scenario. The problem I haven't figured out a way round is when I have
parameters and return types based on arrays of the interfaces. I get
an annotation error with JAXB complaining it can't handle interfaces
(despite having the required @XmlJavaTypeAdapter against the interface
itself). I've tried
Re: Problem generating WSDL from Java API with CXF 2.0.3
JAXB generally doesn't like interfaces too much. In general, we
definitely suggest using concrete classes.
That said, one major issue is that your interface doesn't have setter
methods on it. There's no way there's any chance of it working without
that. JAXB would only expose properties that have bother getters and
setters. That said, I still doubt it will work as interfaces. The
jaxws spec really doesn't allow for that at all. Just concrete data
objects.
Dan
On Friday 25 January 2008, Phil Weighill-Smith wrote:
For some reason I can't get CXF 2.0.3 to generate what looks like
correct WSDL from a set of Java interfaces. I either get no XML
representing the object(s) or get an abstract complex type for the
object(s) depending on the interfaces involved.
Here's a simple example. Because I use interfaces for the returned
object(s) I have a factory. This looks like:
package org.bad;
/**
* A simple factory to allow JAXB to handle the various interfaces
used. */
public class SimpleFactory {
/**
* Support the [EMAIL PROTECTED] SimpleThing} class.
*
* @return a SimpleThing implementation. Added setters for good
luck not * knowing just how JAXB should handle unmarshalling
*/
public SimpleThing createSimpleThing() {
return new SimpleThing() {
/**
* The description.
*/
private String description = null;
/**
* The name.
*/
private String name = null;
@Override
public String getDescription() {
return description;
}
@Override
public String getName() {
return name;
}
/**
* Allow the description to be modified.
*
* @param description the new description
*/
public void setDescription(String description) {
this.description = description;
}
/**
* Allow the name to be modified.
*
* @param name the new name
*/
public void setName(String name) {
this.name = name;
}
};
}
}
I then have the SimpleThing (the object to be returned) defined as:
package org.bad;
import javax.xml.bind.annotation.XmlType;
/**
* A simple thing to communicate over the web service.
*/
@XmlType(factoryClass = SimpleFactory.class,
factoryMethod = createSimpleThing)
public interface SimpleThing {
/**
* A read-only name property.
*
* @return the name property
*/
String getName();
/**
* A read-only description property.
*
* @return the description property
*/
String getDescription();
}
Finally, the service is then defined thus:
package org.bad;
import javax.jws.WebService;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.soap.SOAPBinding;
/**
* The SEI java class.
*/
@WebService(name = SimpleService,
targetNamespace = http://org.bad.SimpleService/service;)
@SOAPBinding(style = SOAPBinding.Style.RPC,
use = SOAPBinding.Use.ENCODED,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface SimpleService {
/**
* Get a [EMAIL PROTECTED] SimpleThing} by name.
*
* @param name the name for the [EMAIL PROTECTED] SimpleThing} to be
returned. * @return the [EMAIL PROTECTED] SimpleThing} with that name, or
null if
there isn't a
* match
*/
@WebResult(name = result,
targetNamespace = http://org.bad.SimpleService;)
SimpleThing getThing(
@WebParam(name = name)
final String name);
}
When I run the java2wsdl (via the IDEA's Web Services integration
mechanism) I get the following output:
?xml version=1.0 encoding=UTF-8?
wsdl:definitions name=SimpleServiceService
targetNamespace=http://org.bad;
xmlns:ns1=http://org.bad.SimpleService/service;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://org.bad;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
wsdl:message name=getThing
wsdl:part name=name type=xsd:string
/wsdl:part
/wsdl:message
wsdl:message name=getThingResponse
wsdl:part name=result
/wsdl:part
/wsdl:message
wsdl:portType name=SimpleService
wsdl:operation name=getThing
wsdl:input name=getThing message=ns1:getThing
/wsdl:input
wsdl:output name=getThingResponse
message=ns1:getThingResponse
/wsdl:output
/wsdl:operation
/wsdl:portType
