You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2008/02/02 04:26:20 UTC
Re: Problem generating WSDL from Java API with CXF 2.0.3
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 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 {
> ...
> List<User> 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;
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
Posted by Phil Weighill-Smith <ph...@volantis.com>.
I'll get hold of the snapshots on Monday and try it out then. Thanks.
Phil :n)
----- Original Message -----
From: "Daniel Kulp" <dk...@apache.org>
To: cxf-user@incubator.apache.org
Cc: "Phil Weighill-Smith" <ph...@volantis.com>
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
> XmlAdapter<UserImpl, 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 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 {
> > > ...
> > > List<User> 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;
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
Posted by Glen Mazza <gl...@verizon.net>.
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 <dk...@apache.org>
> > To: cxf-user@incubator.apache.org
> > Cc: Phil Weighill-Smith <ph...@volantis.com>
> > 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
Posted by Phil Weighill-Smith <ph...@volantis.com>.
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 not be * null
> > * @param device the DRWS device name for the
> > request * during which the user's
> > details are * to be retrieved. If
> > not null this may * be used to
> > update the user's last * known
> > device
> > * @param includeExtensionParameters identifies whether extension
> > * parameters should be
> > populated * @param includeSubscriptions identifies whether
> > subscriptions * should be populated
> > * @return the user with or without extension parameter and/or
> > subscription * details. Will not be null
> > * @throws PersistenceException if there is a problem with the MSS
> > * persistence mechanism
> > */
> > @XmlJavaTypeAdapter(Adapters.UserAdapter.class)
> > User getUser(
> > @WebParam(name = "application")
> > final String applicationID,
> > @WebParam(name = "id")
> > final String userID,
> > @WebParam(name = "device")
> > final String device,
> > @WebParam(name = "includeExtensionParameters")
> > final boolean includeExtensionParameters,
> > @WebParam(name = "includeSubscriptions")
> > final boolean includeSubscriptions) throws
> > PersistenceException; ...
> > }
> >
> > The User interface looks like:
> >
> >
> > package com.volantis.openapi.mss.usermodule;
> >
> > import com.volantis.openapi.mss.usermodule.jaxb.Adapters;
> >
> > import java.util.Calendar;
> > import java.util.List;
> >
> > import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
> > import javax.xml.bind.annotation.XmlElement;
> >
> > /**
> > * Represents the details of a user as stored in MSS.
> > *
> > * <p><strong>Warning: This is a facade provided for use by user code,
> > not for * implementation in user code. User implementations of this
> > interface are * highly likely to be incompatible with future releases
> > of the product at both * binary and source levels.</strong></p>
> > *
> > * @volantis-api-include-in PublicAPI
> > */
> > @XmlJavaTypeAdapter(Adapters.UserAdapter.class)
> > public interface User {
> > /**
> > * The user's application-scope unique identity. This is typically
> > defined * by an operator token though may be a generated unique ID
> > obtained from * the MSS User Identification Service.
> > *
> > * @return the user's identity. Will not be null
> > */
> > @XmlElement(required = true)
> > String getID();
> >
> > ...
> > }
> >
> >
> > The implementation of this looks like:
> >
> >
> > package com.volantis.openapi.mss.usermodule.jaxb;
> >
> > import com.volantis.openapi.mss.usermodule.User;
> >
> > import javax.xml.bind.annotation.XmlType;
> > import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
> >
> > /**
> > * A mutable implementation of the {@link User} API for use
> > * in JAXB bindings.
> > */
> > @XmlType(name = "User")
> > public class UserImpl extends ParameterOwner implements User {
> > /**
> > * The ID for this user.
> > */
> > private String id;
> >
> > ...
> >
> > /**
> > * Initializes the new instance.
> > */
> > public UserImpl() {
> > }
> >
> > @Override
> > public String getID() {
> > return id;
> > }
> >
> > /**
> > * Permit the ID to be updated.
> > *
> > * @param id the new value. Must not be null
> > * @throws IllegalArgumentException if any constraints are
> > violated */
> > public void setID(final String id) throws IllegalArgumentException
> > { if (id == null) {
> > throw new IllegalArgumentException();
> > }
> >
> > this.id = id;
> > }
> >
> > ...
> > }
> >
> >
> > (The ParameterOwner base class can be ignored pretty much in this
> > cut-down example, but I leave it here so you can see how the UserImpl
> > is structured by extending a base class with certain properties.)
> >
> > Finally, the adapter looks like this:
> >
> >
> > package com.volantis.openapi.mss.usermodule.jaxb;
> >
> > import com.volantis.openapi.mss.usermodule.User;
> >
> > import javax.xml.bind.annotation.adapters.XmlAdapter;
> >
> > /**
> > * Provides the various Java type adapters required to allow the API
> > to be * appropriately bound to JAX-WS and JAXB.
> > */
> > public final class Adapters {
> > /**
> > * {@link User} adapter.
> > */
> > public static final class UserAdapter extends
> > XmlAdapter<UserImpl, User> {
> > @Override
> > public UserImpl marshal(final User user) throws Exception {
> > return (UserImpl) user;
> > }
> >
> > @Override
> > public User unmarshal(final UserImpl user) throws Exception {
> > return user;
> > }
> > }
> >
> > ...
> > }
> >
> >
> > Any suggestions as to why the response for the getUser operation is
> > like:
> >
> >
> > <xs:element name="getUserResponse" type="getUserResponse"/>
> > <xs:complexType name="getUserResponse">
> > <xs:sequence>
> > <xs:element 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 <dk...@apache.org>
> > > > To: cxf-user@incubator.apache.org
> > > > Cc: Phil Weighill-Smith <ph...@volantis.com>
> > > > 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
Posted by Daniel Kulp <dk...@apache.org>.
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 not be * null
> * @param device the DRWS device name for the
> request * during which the user's
> details are * to be retrieved. If
> not null this may * be used to
> update the user's last * known
> device
> * @param includeExtensionParameters identifies whether extension
> * parameters should be
> populated * @param includeSubscriptions identifies whether
> subscriptions * should be populated
> * @return the user with or without extension parameter and/or
> subscription * details. Will not be null
> * @throws PersistenceException if there is a problem with the MSS
> * persistence mechanism
> */
> @XmlJavaTypeAdapter(Adapters.UserAdapter.class)
> User getUser(
> @WebParam(name = "application")
> final String applicationID,
> @WebParam(name = "id")
> final String userID,
> @WebParam(name = "device")
> final String device,
> @WebParam(name = "includeExtensionParameters")
> final boolean includeExtensionParameters,
> @WebParam(name = "includeSubscriptions")
> final boolean includeSubscriptions) throws
> PersistenceException; ...
> }
>
> The User interface looks like:
>
>
> package com.volantis.openapi.mss.usermodule;
>
> import com.volantis.openapi.mss.usermodule.jaxb.Adapters;
>
> import java.util.Calendar;
> import java.util.List;
>
> import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
> import javax.xml.bind.annotation.XmlElement;
>
> /**
> * Represents the details of a user as stored in MSS.
> *
> * <p><strong>Warning: This is a facade provided for use by user code,
> not for * implementation in user code. User implementations of this
> interface are * highly likely to be incompatible with future releases
> of the product at both * binary and source levels.</strong></p>
> *
> * @volantis-api-include-in PublicAPI
> */
> @XmlJavaTypeAdapter(Adapters.UserAdapter.class)
> public interface User {
> /**
> * The user's application-scope unique identity. This is typically
> defined * by an operator token though may be a generated unique ID
> obtained from * the MSS User Identification Service.
> *
> * @return the user's identity. Will not be null
> */
> @XmlElement(required = true)
> String getID();
>
> ...
> }
>
>
> The implementation of this looks like:
>
>
> package com.volantis.openapi.mss.usermodule.jaxb;
>
> import com.volantis.openapi.mss.usermodule.User;
>
> import javax.xml.bind.annotation.XmlType;
> import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
>
> /**
> * A mutable implementation of the {@link User} API for use
> * in JAXB bindings.
> */
> @XmlType(name = "User")
> public class UserImpl extends ParameterOwner implements User {
> /**
> * The ID for this user.
> */
> private String id;
>
> ...
>
> /**
> * Initializes the new instance.
> */
> public UserImpl() {
> }
>
> @Override
> public String getID() {
> return id;
> }
>
> /**
> * Permit the ID to be updated.
> *
> * @param id the new value. Must not be null
> * @throws IllegalArgumentException if any constraints are
> violated */
> public void setID(final String id) throws IllegalArgumentException
> { if (id == null) {
> throw new IllegalArgumentException();
> }
>
> this.id = id;
> }
>
> ...
> }
>
>
> (The ParameterOwner base class can be ignored pretty much in this
> cut-down example, but I leave it here so you can see how the UserImpl
> is structured by extending a base class with certain properties.)
>
> Finally, the adapter looks like this:
>
>
> package com.volantis.openapi.mss.usermodule.jaxb;
>
> import com.volantis.openapi.mss.usermodule.User;
>
> import javax.xml.bind.annotation.adapters.XmlAdapter;
>
> /**
> * Provides the various Java type adapters required to allow the API
> to be * appropriately bound to JAX-WS and JAXB.
> */
> public final class Adapters {
> /**
> * {@link User} adapter.
> */
> public static final class UserAdapter extends
> XmlAdapter<UserImpl, User> {
> @Override
> public UserImpl marshal(final User user) throws Exception {
> return (UserImpl) user;
> }
>
> @Override
> public User unmarshal(final UserImpl user) throws Exception {
> return user;
> }
> }
>
> ...
> }
>
>
> Any suggestions as to why the response for the getUser operation is
> like:
>
>
> <xs:element name="getUserResponse" type="getUserResponse"/>
> <xs:complexType name="getUserResponse">
> <xs:sequence>
> <xs:element 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 <dk...@apache.org>
> > > To: cxf-user@incubator.apache.org
> > > Cc: Phil Weighill-Smith <ph...@volantis.com>
> > > 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
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
Posted by Phil Weighill-Smith <ph...@volantis.com>.
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 not be
* null
* @param device the DRWS device name for the request
* during which the user's details are
* to be retrieved. If not null this may
* be used to update the user's last
* known device
* @param includeExtensionParameters identifies whether extension
* parameters should be populated
* @param includeSubscriptions identifies whether subscriptions
* should be populated
* @return the user with or without extension parameter and/or subscription
* details. Will not be null
* @throws PersistenceException if there is a problem with the MSS
* persistence mechanism
*/
@XmlJavaTypeAdapter(Adapters.UserAdapter.class)
User getUser(
@WebParam(name = "application")
final String applicationID,
@WebParam(name = "id")
final String userID,
@WebParam(name = "device")
final String device,
@WebParam(name = "includeExtensionParameters")
final boolean includeExtensionParameters,
@WebParam(name = "includeSubscriptions")
final boolean includeSubscriptions) throws PersistenceException;
...
}
The User interface looks like:
package com.volantis.openapi.mss.usermodule;
import com.volantis.openapi.mss.usermodule.jaxb.Adapters;
import java.util.Calendar;
import java.util.List;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
import javax.xml.bind.annotation.XmlElement;
/**
* Represents the details of a user as stored in MSS.
*
* <p><strong>Warning: This is a facade provided for use by user code, not for
* implementation in user code. User implementations of this interface are
* highly likely to be incompatible with future releases of the product at both
* binary and source levels.</strong></p>
*
* @volantis-api-include-in PublicAPI
*/
@XmlJavaTypeAdapter(Adapters.UserAdapter.class)
public interface User {
/**
* The user's application-scope unique identity. This is typically defined
* by an operator token though may be a generated unique ID obtained from
* the MSS User Identification Service.
*
* @return the user's identity. Will not be null
*/
@XmlElement(required = true)
String getID();
...
}
The implementation of this looks like:
package com.volantis.openapi.mss.usermodule.jaxb;
import com.volantis.openapi.mss.usermodule.User;
import javax.xml.bind.annotation.XmlType;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
/**
* A mutable implementation of the {@link User} API for use
* in JAXB bindings.
*/
@XmlType(name = "User")
public class UserImpl extends ParameterOwner implements User {
/**
* The ID for this user.
*/
private String id;
...
/**
* Initializes the new instance.
*/
public UserImpl() {
}
@Override
public String getID() {
return id;
}
/**
* Permit the ID to be updated.
*
* @param id the new value. Must not be null
* @throws IllegalArgumentException if any constraints are violated
*/
public void setID(final String id) throws IllegalArgumentException {
if (id == null) {
throw new IllegalArgumentException();
}
this.id = id;
}
...
}
(The ParameterOwner base class can be ignored pretty much in this
cut-down example, but I leave it here so you can see how the UserImpl is
structured by extending a base class with certain properties.)
Finally, the adapter looks like this:
package com.volantis.openapi.mss.usermodule.jaxb;
import com.volantis.openapi.mss.usermodule.User;
import javax.xml.bind.annotation.adapters.XmlAdapter;
/**
* Provides the various Java type adapters required to allow the API to be
* appropriately bound to JAX-WS and JAXB.
*/
public final class Adapters {
/**
* {@link User} adapter.
*/
public static final class UserAdapter extends
XmlAdapter<UserImpl, User> {
@Override
public UserImpl marshal(final User user) throws Exception {
return (UserImpl) user;
}
@Override
public User unmarshal(final UserImpl user) throws Exception {
return user;
}
}
...
}
Any suggestions as to why the response for the getUser operation is
like:
<xs:element name="getUserResponse" type="getUserResponse"/>
<xs:complexType name="getUserResponse">
<xs:sequence>
<xs:element 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 <dk...@apache.org>
> > To: cxf-user@incubator.apache.org
> > Cc: Phil Weighill-Smith <ph...@volantis.com>
> > 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
Posted by Phil Weighill-Smith <ph...@volantis.com>.
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 <dk...@apache.org>
> > To: cxf-user@incubator.apache.org
> > Cc: Phil Weighill-Smith <ph...@volantis.com>
> > 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
Posted by Daniel Kulp <dk...@apache.org>.
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 <dk...@apache.org>
> To: cxf-user@incubator.apache.org
> Cc: Phil Weighill-Smith <ph...@volantis.com>
> 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
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
Posted by Phil Weighill-Smith <ph...@volantis.com>.
That's the sort of answer I was looking for. Thanks,
Phil :n)
PS: Was this an RTFM moment?!
----- Original Message -----
From: Daniel Kulp <dk...@apache.org>
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith <ph...@volantis.com>
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" <dk...@apache.org>
> To: cxf-user@incubator.apache.org
> Cc: "Phil Weighill-Smith" <ph...@volantis.com>
> 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" <dk...@apache.org>
> > To: cxf-user@incubator.apache.org
> > Cc: "Phil Weighill-Smith" <ph...@volantis.com>
> > 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
> > > XmlAdapter<UserImpl, 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-mo
> > >du 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">
> > > <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 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 {
> > > > > ...
> > > > > List<User> 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-mo
> > > > >du le "> ...
> > > > > <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;
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: What jars files are not required on client side
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 26 February 2008, Li, Weiye wrote:
> I just started to use CXF with Spring. There're 23 jars required for
> the integration of Spring and CXF on the document (
> http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html )
>
> Are those all required on client side? Are there any only required for
> Server side? Thanks.
That list looks about correct. You may be able to ditch:
geronimo-servlet_2.5_spec-1.1-M1.jar
If you use Java6 up to update 3, you can ditch a couple more, but that
isn't very tested well at this point. (CXF 2.1 will support update 4
and newer)
I think there is a spring-all jar or similar that could be used instead
of the individual spring jars. Not really sure though.
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
What jars files are not required on client side
Posted by "Li, Weiye" <We...@STJUDE.ORG>.
I just started to use CXF with Spring. There're 23 jars required for the integration of Spring and CXF on the document ( http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html )
Are those all required on client side? Are there any only required for Server side? Thanks.
Re: Problem generating WSDL from Java API with CXF 2.0.3
Posted by Daniel Kulp <dk...@apache.org>.
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" <dk...@apache.org>
> To: cxf-user@incubator.apache.org
> Cc: "Phil Weighill-Smith" <ph...@volantis.com>
> 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" <dk...@apache.org>
> > To: cxf-user@incubator.apache.org
> > Cc: "Phil Weighill-Smith" <ph...@volantis.com>
> > 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
> > > XmlAdapter<UserImpl, 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-mo
> > >du 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">
> > > <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 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 {
> > > > > ...
> > > > > List<User> 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-mo
> > > > >du le "> ...
> > > > > <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;
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
Posted by Phil Weighill-Smith <ph...@volantis.com>.
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...?
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" <dk...@apache.org>
To: cxf-user@incubator.apache.org
Cc: "Phil Weighill-Smith" <ph...@volantis.com>
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.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" <dk...@apache.org>
> To: cxf-user@incubator.apache.org
> Cc: "Phil Weighill-Smith" <ph...@volantis.com>
> 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
> > XmlAdapter<UserImpl, 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">
> > <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 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
> > > > {
> > > > ...
> > > > List<User> 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-modu
> > > >le "> ...
> > > > <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;
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
Posted by Daniel Kulp <dk...@apache.org>.
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" <dk...@apache.org>
> To: cxf-user@incubator.apache.org
> Cc: "Phil Weighill-Smith" <ph...@volantis.com>
> 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
> > XmlAdapter<UserImpl, 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">
> > <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 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
> > > > {
> > > > ...
> > > > List<User> 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-modu
> > > >le "> ...
> > > > <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;
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
Posted by Phil Weighill-Smith <ph...@volantis.com>.
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" <dk...@apache.org>
To: cxf-user@incubator.apache.org
Cc: "Phil Weighill-Smith" <ph...@volantis.com>
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
> XmlAdapter<UserImpl, 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 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 {
> > > ...
> > > List<User> 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;
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
Posted by Daniel Kulp <dk...@apache.org>.
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
> XmlAdapter<UserImpl, 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 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 {
> > > ...
> > > List<User> 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;
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
Posted by Phil Weighill-Smith <ph...@volantis.com>.
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
XmlAdapter<UserImpl, 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 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 {
> > ...
> > List<User> 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;
>
>
>