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
Dan,
Does this one still look fixable and would it be possible to patch 2.0.x
with the fixes to get functional WSDL generation in this case?
Thanks again for your endeavours in resolving these issues,
Phil :n.
On Wed, 2008-02-27 at 16:48 -0500, Daniel Kulp wrote:
This looks exactly like the issue in:
http://www.nabble.com/Does-CXF-Support-Interfaces-as-Web-Params--to15702272.html
I'll look at it more tonight or tomorrow.
Dan
On Wednesday 27 February 2008, Phil Weighill-Smith wrote:
Dan,
So we managed to get the new tool running, but we still have the same
problem. I've attached the full actual WSDL generated.
This is generated using the following snippet of Ant scripting:
target name=generate-remote-java2wsdl
depends=-make-output-dir java
classname=org.apache.cxf.tools.java2ws.JavaToWS fork=true arg
value=-wsdl/
arg value=-s/
arg
value=${product.dir}/user-module/built/output/generated/ arg
value=-o/
arg
value=${product.dir}/user-module/built/output/UserModule.wsdl/
arg
value=com.volantis.openapi.mss.usermodule.UserModule/ classpath
path refid=cxf.classpath/
/classpath
/java
/target
When executed we get the following output from Ant:
generate-remote-java2wsdl:
[java] log4j:WARN No appenders could be found for logger
(org.apache.cxf.bus.spring.BusApplicationContext). [java] log4j:WARN
Please initialize the log4j system properly. [java] Feb 27, 2008
2:06:35 PM org.apache.cxf.bus.spring.BusApplicationContext
getConfigResources [java] INFO: No cxf.xml configuration file
detected, relying on defaults. [java] Feb 27, 2008 2:06:37 PM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass [java] INFO: Creating Service
{http://com.volantis.xmlns/2008/01/mss/user-module}UserModuleService
from class com.volantis.openapi.mss.usermodule.UserModule [java] Feb
27, 2008 2:06:38 PM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass [java] INFO:
{http://com.volantis.xmlns/2008/01/mss/user-module}parameters part
type QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}parameter part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}parameters part
type QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}return part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}return part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}definition part
type QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}parameter part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}return part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}return part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}parameters part
type QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}return part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}preference part
type QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}originalPreference
part type QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}parameters part
type QName null.
I'm wondering if the QName null issues are the source of our problems,
and what they mean.
Here is the start of our SEI (with the first operation/method
included):
package com.volantis.openapi.mss.usermodule;
import com.volantis.openapi.mss.usermodule.jaxb.Adapters;
import java.util.List;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.xml.datatype.Duration;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
/**
* Provides access to the various operations that can be performed
against the * user module which forms part of the MSS API.
*
* ...
*/
@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 {
/**
* Get the details of the specified user, with or without
extension * parameter and subscription details and potentially
updating the user's * last known device.
*
* @param applicationID the ID for the application
scope in * which the user exists.
Must not be * null
* @param userID the application-scope unique
ID for * the user to be retrieved.
Must
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
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
days). Better yet, check out
CXF from Svn, experiment a bit by editing those lines, then attach a
patch to that jira. :-)
Dan
On Thursday 31 January 2008, Phil Weighill-Smith wrote:
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
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: Supressing generation of xs:extension against inheritance
Thanks for the suggestions. I guess I'll live with the xs:extensions for now (I guess they don't really affect the actual XML structure, save element ordering). Phil :n. On Thu, 2008-01-31 at 17:06 -0500, Benson Margulies wrote: On Thu, 2008-01-31 at 17:01 -0500, Daniel Kulp wrote: Honestly, looking at the jaxb spec, I don't see anything that would allow that.Thats something you may want to ask on the jaxb lists: https://jaxb.dev.java.net/servlets/ProjectMailingListList There might be some hidden flag or something that could be used to set it. I don't really know. (sort of) As per the blog posting I wrote at dssheep.blogspot.com, you could consider the following methodology: 1) Use your current classes as sacrificial. 2) Edit the XSD until you like it. 3) Regenerate new classes. The new classes will be redundant, but will that really hurt? You could also whip up a set of facade wrappers that delegate your interfaces to them.
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
=getThingResponse
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=SimpleServiceService
wsdl:port name=SimpleServicePort
binding=ns1:SimpleServiceServiceSoapBinding
soap:address location=http://localhost:9090/hello/
/wsdl:port
/wsdl:service
/wsdl:definitions
The only things I still can't control are:
* 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)
* 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)
* ensuring the WSDL contains appropriate documentation.
Any ideas how to address these?
Phil :n.
On Fri, 2008-01-25 at 11:50 -0500, Daniel Kulp wrote:
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
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
