You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by MathisMohr <ma...@aol.com> on 2008/06/18 15:58:06 UTC
CXF, trouble to find Classes to unmarshal to
My Problem is:
I am to create a webservice. I'm currently using CXF 2.1, but that doesnt
seem to be the point, I also tried 2.0.6 and 2.0.7. with no different
outcome.
I have the WSDL and some XSD files defining the main request and response
messages. Thing is, the WSDL only defines 2 elements, and then refers to a
xsd:any element, so it would accept every data that follows. There is no
clear connection to the XSDs. I can generate Java Code out of them though.
Now when I use Jetty to start the webservice on my machine I see that it is
working. I can send messages to the webservice, but CXF only seems to
unmarshall the elements which are defined in the wsdl, everything else is
being summed up in an instance of ElementNSImpl (from xerces). Thanks to
debugging my webservice I found out that this Object actually has all my
information in it, in some kind of DOM-Tree, it's just not being
unmarshalled. As far as I see it, it seems that JaxB either doesnt recognize
the generated files of the xsd's (because there is no connection between the
wsdl and the xsds) or JaxB doesnt accept them. Either way, I have no
solution. Can someone help me?
wsdl-snippet:
<s:element name="GetVehicleOwnerHolderByChassisAndDate">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="VehOwnerHolderByChassisAndDate">
<s:complexType mixed="true">
<sequence>
<s:any />
</s:sequence>
</s:complexType>
</s:element>
</s:sequence>
</s:complexType>
</s:element>
Xsd-snippet:
<xs:element name="VehOwnerHolderByChassisAndDate"
type="VehOwnerHolderByChassisAndDateType"/>
<xs:complexType name="VehOwnerHolderByChassisAndDateType">
<xs:sequence>
<xs:element name="Header" type="HeaderType"/>
<xs:element name="Body">
<xs:complexType>
<xs:sequence>
<xs:element name="Request">
<xs:complexType>
<xs:sequence>
<xs:element name="VehCountryReq"
type="xs:string" nillable="false"/>
<xs:element
name="VehIdentificationNumberReq" type="xs:string"/>
<xs:element name="ReferenceDateTimeReq"
type="xs:dateTime" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
Generated-code:
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
"vehOwnerHolderByChassisAndDate"
})
@XmlRootElement(name = "GetVehicleOwnerHolderByChassisAndDate")
public class GetVehicleOwnerHolderByChassisAndDate {
@XmlElement(name = "VehOwnerHolderByChassisAndDate")
protected
GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
vehOwnerHolderByChassisAndDate;
public
GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
getVehOwnerHolderByChassisAndDate() {
return vehOwnerHolderByChassisAndDate;
}
public void
setVehOwnerHolderByChassisAndDate(GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
value) {
this.vehOwnerHolderByChassisAndDate = value;
}
*/
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
"content"
})
public static class VehOwnerHolderByChassisAndDate {
@XmlMixed
@XmlAnyElement(lax = true)
protected List content;
public List getContent() {
if (content == null) {
content = new ArrayList();
}
return this.content;
}
--
View this message in context: http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17983289.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF, trouble to find Classes to unmarshal to
Posted by MathisMohr <ma...@aol.com>.
Ok, that seems to solve the problem, I wrote an interceptor which kicks the
xmlns="" out of the payload, and then, WOW it works. yay!
I still dunno why it's in there anyway, the client logs the xml messages and
doesnt seem to have it in there..or it lies..when I dump the incomming
message into a logfile I see it..or saw it..writing that interceptor was
easier than expected..
But thanks for your help Dan, now I'm finally done..2 weeks late :D
MathisMohr wrote:
>
>
> I got a little deeper into this xmlns="" thing. If I send a plain xml
> message to my system (with another, rather "custom" client) that contains
> the xmlns="" part, the message is refused, or rather not unmarshalled (the
> phenomena I witness when I try to get the "real" client working.
> But once I remove that part, it works. Instead of the obnoxious
> ElementNSImpl instances I get my content wrapped up in JAXBElements, ready
> for further processing.
>
> Now, since I do not have any influence on the "real" client, and this
> workaround only works on my "custom" one..would it be possible to
> eliminate that part before the Message gets processed? Kinda like an
> interceptor, that reads the soapmessage, looks for the appropriate element
> and rewrites it?
>
>
>
> MathisMohr wrote:
>>
>>
>> So, as far as I understand it, if I "include" my xsd-files (without any
>> targetNamespace information) into my wsdl-schema (which has a
>> targetNamespace information) these attributes should be inherited by the
>> xsds..or not?
>>
>> I peeked a little deeper into what is actually sent by the other side to
>> my webservice, and stumbled upon this:
>>
>> (...)
>> <soap:Body>
>> <GetVehicleOwnerHolderByChassisAndDate
>> xmlns="http://services.eucaris.net/">
>> <VehOwnerHolderByChassisAndDate>
>> <VehOwnerHolderByChassisAndDate
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="">
>> (...)
>>
>> As far as I understand it, that part should determine to what schema the
>> following elements without prefix belong..but the client is leaving it
>> blank, or even setting it to a blank value. Could this be the reason why
>> JaxB doesnt recognize it on my side? Just a thought.
>>
>> Another thing I tried was to willingly alter the wsdl to not accept
>> "xsd:any" any more but to force it to accept the
>> "VehOwnerHolderByChassisAndDateType" from my xsds instead. This doesnt
>> work at all, all content is being rejected. Funny thing though, if I do
>> it that way I have a clear connection between all types, but whatever
>> junk the client sends doesnt seem to fit in..
>>
>>
>>
>> dkulp wrote:
>>>
>>>
>>> I have a feeling that lack of the target namespace is going to be an
>>> issue. The elements need to be namespace qualified for JAXB to look
>>> it up in it's internal maps.
>>>
>>>
>>> I just dug around a bit and discovered:
>>>
>>> http://www.xfront.com/ZeroOneOrManyNamespaces.html#mixed
>>>
>>> Thus, it looks like you should use an "include", not an "import" for
>>> this. However, that will bring those types in the same namespace.
>>> If the server isn't namespace qualifying that element on the wire,
>>> JAXB still won't be able to do anything with it.
>>>
>>>
>>> Dan
>>>
>>>
>>>
>>> On Jun 20, 2008, at 5:08 AM, MathisMohr wrote:
>>>
>>>>
>>>> Another day and another try, well..
>>>>
>>>> 1.: I'm rather new to xml/xsd/wsdl/webservice/cxf and all the files
>>>> were
>>>> provided by our partner, who developed the other side of the
>>>> webservice, so
>>>> I hoped it would work out of the box (I cant ask him, he's working
>>>> with
>>>> .Net). The xsd-files do not define a targetNamespace at all, nor do
>>>> they
>>>> contain a namespace except the XML-Schema one, this looks
>>>> suspicious..could
>>>> it be that this is the reason? Here's a more accurate snippet (the
>>>> original,
>>>> totally unmodified version I was supplied with). I already tried
>>>> adding the
>>>> targetNamespace into the XSDs, but I had no luck. Can you give me a
>>>> hint on
>>>> this?
>>>>
>>>> WSDL:
>>>> <?xml version="1.0" encoding="utf-8"?>
>>>> <definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
>>>> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
>>>> xmlns:s="http://www.w3.org/2001/XMLSchema"
>>>> xmlns:s0="http://services.eucaris.net/"
>>>> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
>>>> xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
>>>> xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
>>>> targetNamespace="http://services.eucaris.net/"
>>>> xmlns="http://schemas.xmlsoap.org/wsdl/">
>>>> <types>
>>>> <s:schema elementFormDefault="qualified"
>>>> targetNamespace="http://services.eucaris.net/">
>>>> <!-- This is were I had my imports -->
>>>> <s:element name="GetVehicleOwnerHolderByChassisAndDate">
>>>> <s:complexType>
>>>> <s:sequence>
>>>> <s:element minOccurs="0" maxOccurs="1"
>>>> name="VehOwnerHolderByChassisAndDate">
>>>> <s:complexType mixed="true">
>>>> <s:sequence>
>>>> <s:any />
>>>> </s:sequence>
>>>> </s:complexType>
>>>> </s:element>
>>>> </s:sequence>
>>>> </s:complexType>
>>>> </s:element>
>>>> (..more elements)
>>>>
>>>> XSD:
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <!-- XSD version v1.0.2 -->
>>>>
>>>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>>> elementFormDefault="qualified">
>>>> <xs:include schemaLocation="EucarisIIHeader.xsd"/>
>>>>
>>>> <xs:element name="VehOwnerHolderByChassisAndDate"
>>>> type="VehOwnerHolderByChassisAndDateType"/>
>>>>
>>>> <xs:complexType name="VehOwnerHolderByChassisAndDateType">
>>>> <xs:sequence>
>>>> <xs:element name="Header" type="HeaderType"/>
>>>> <xs:element name="Body">
>>>> <xs:complexType>
>>>> <xs:sequence>
>>>> <xs:element name="Request">
>>>> <xs:complexType>
>>>> <xs:sequence>
>>>> <xs:element name="VehCountryReq" type="xs:string"
>>>> nillable="false"/>
>>>> <xs:element name="VehIdentificationNumberReq"
>>>> type="xs:string"/>
>>>> <xs:element name="ReferenceDateTimeReq" type="xs:dateTime"
>>>> minOccurs="0"/>
>>>> </xs:sequence>
>>>> </xs:complexType>
>>>> </xs:element>
>>>> </xs:sequence>
>>>> </xs:complexType>
>>>> </xs:element>
>>>> </xs:sequence>
>>>> </xs:complexType>
>>>> </xs:schema>
>>>>
>>>>
>>>> 2.: Here, I followed the idea of generating each schema in a different
>>>> package (horrible until now, because now I have 5-6 implementations of
>>>> basically always the same type, but anyway for now). Adding the
>>>> Objectfactories of these packages to the Serviceinterface or its
>>>> Impl didnt
>>>> work either. Same error, and it's probably just related to 1.).
>>>>
>>>>
>>>> dkulp wrote:
>>>>>
>>>>>
>>>>> On Jun 19, 2008, at 2:17 AM, MathisMohr wrote:
>>>>>
>>>>>>
>>>>>> Ok I tried 2 things, both with no luck:
>>>>>>
>>>>>> 1.) I inlcuded the xsd-files into the wsdl, so that everything in
>>>>>> generated
>>>>>> in one move. It works, all the classes are being generated in one
>>>>>> package
>>>>>> (ie com.foo.generated.wsdl). Yet still, my test refuses to
>>>>>> unmarshall the
>>>>>> "inner" elements.
>>>>>
>>>>> That's actually probably bad. Are you using the -p option to map
>>>>> them all to one package? Or are all the schemas specifying the same
>>>>> targetNamespace? (in which case it should be an include, not import)
>>>>>
>>>>> The -p thing is really bad with multiple schemas. I've logged a bug
>>>>> about it:
>>>>> https://issues.apache.org/jira/browse/CXF-1662
>>>>>
>>>>>> 2.) Without this inclusion, I added the ObjectFactory of the
>>>>>> seperatly
>>>>>> generated xsd-classes (ie com.foo.generated.xsd) to my PortType. But
>>>>>> in this
>>>>>> case, it doesnt work as well. Yet this may be my fault, is my
>>>>>> placement of
>>>>>> the annotation (at the implementation of the serviceinterface)
>>>>>> correct?
>>>>>
>>>>> Maybe. Possibly on the impl instead. I'm not really sure. :-(
>>>>>
>>>>> If you use the 2.1.1 version that we are currently voting on, you can
>>>>> also use spring config to add the classes:
>>>>>
>>>>>
>>>>> <!-- Endpoint -->
>>>>> <jaxws:endpoint id="testEndpoint"
>>>>> implementor="org.apache.cxf.systest.jaxb.service.TestServiceImpl"
>>>>> address="http://localhost:7081/service/TestEndpoint">
>>>>>
>>>>> <jaxws:properties>
>>>>> <entry key="jaxb.additionalContextClasses">
>>>>> <bean
>>>>> class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
>>>>> <property name="classNames">
>>>>> <list>
>>>>> <value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</
>>>>> value>
>>>>> </list>
>>>>> </property>
>>>>> </bean>
>>>>> </entry>
>>>>> </jaxws:properties>
>>>>> </jaxws:endpoint>
>>>>>
>>>>> 2.1.1 can be downloaded from:
>>>>> http://people.apache.org/~dkulp/stage_cxf/2.1.1/
>>>>>
>>>>> It will hopefully be released tomorrow.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Another thing that came up, yet illogical, is: Could it be, that the
>>>>>> Elements, which are not unmarshalled simply don't match my generated
>>>>>> classes? But that really defies logic, the testclient AND the wsdl
>>>>>> were
>>>>>> supplied together..
>>>>>>
>>>>>>
>>>>>> dkulp wrote:
>>>>>>>
>>>>>>>
>>>>>>> This is much easier with 2.1, so stick with that.......
>>>>>>>
>>>>>>> As you surmised, by default, the runtime only knows about the types
>>>>>>> that are references in the generated code from the wsdl. One
>>>>>>> solution is to add imports in the wsdl to import the other schemas
>>>>>>> and
>>>>>>> regenerate.
>>>>>>>
>>>>>>> The other option is to tell CXF about the other types that you want
>>>>>>> it
>>>>>>> to accept. The JAXB @XmlSeeAlso annotation is the easiest way
>>>>>>> to do
>>>>>>> that. If you generate objects from your other schemas with xjc,
>>>>>>> it
>>>>>>> probably generated a ObjectFactory class. Just add:
>>>>>>> @XmlSeeAlso({com.foo.blah.ObjectFactory.class})
>>>>>>> to you code to have jaxb pick that up.
>>>>>>>
>>>>>>> There are ways of doing it via configuration and properties and
>>>>>>> such,
>>>>>>> but the XmlSeeAlso is probably the easiest, at least to get started
>>>>>>> to
>>>>>>> make sure it will work for you.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Jun 18, 2008, at 9:58 AM, MathisMohr wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> My Problem is:
>>>>>>>>
>>>>>>>> I am to create a webservice. I'm currently using CXF 2.1, but that
>>>>>>>> doesnt
>>>>>>>> seem to be the point, I also tried 2.0.6 and 2.0.7. with no
>>>>>>>> different
>>>>>>>> outcome.
>>>>>>>> I have the WSDL and some XSD files defining the main request and
>>>>>>>> response
>>>>>>>> messages. Thing is, the WSDL only defines 2 elements, and then
>>>>>>>> refers to a
>>>>>>>> xsd:any element, so it would accept every data that follows. There
>>>>>>>> is no
>>>>>>>> clear connection to the XSDs. I can generate Java Code out of them
>>>>>>>> though.
>>>>>>>> Now when I use Jetty to start the webservice on my machine I see
>>>>>>>> that it is
>>>>>>>> working. I can send messages to the webservice, but CXF only seems
>>>>>>>> to
>>>>>>>> unmarshall the elements which are defined in the wsdl, everything
>>>>>>>> else is
>>>>>>>> being summed up in an instance of ElementNSImpl (from xerces).
>>>>>>>> Thanks to
>>>>>>>> debugging my webservice I found out that this Object actually has
>>>>>>>> all my
>>>>>>>> information in it, in some kind of DOM-Tree, it's just not being
>>>>>>>> unmarshalled. As far as I see it, it seems that JaxB either doesnt
>>>>>>>> recognize
>>>>>>>> the generated files of the xsd's (because there is no connection
>>>>>>>> between the
>>>>>>>> wsdl and the xsds) or JaxB doesnt accept them. Either way, I
>>>>>>>> have no
>>>>>>>> solution. Can someone help me?
>>>>>>>>
>>>>>>>> wsdl-snippet:
>>>>>>>>
>>>>>>>> <s:element name="GetVehicleOwnerHolderByChassisAndDate">
>>>>>>>> <s:complexType>
>>>>>>>> <s:sequence>
>>>>>>>> <s:element minOccurs="0" maxOccurs="1"
>>>>>>>> name="VehOwnerHolderByChassisAndDate">
>>>>>>>> <s:complexType mixed="true">
>>>>>>>> <sequence>
>>>>>>>> <s:any />
>>>>>>>> </s:sequence>
>>>>>>>> </s:complexType>
>>>>>>>> </s:element>
>>>>>>>> </s:sequence>
>>>>>>>> </s:complexType>
>>>>>>>> </s:element>
>>>>>>>>
>>>>>>>> Xsd-snippet:
>>>>>>>>
>>>>>>>> <xs:element name="VehOwnerHolderByChassisAndDate"
>>>>>>>> type="VehOwnerHolderByChassisAndDateType"/>
>>>>>>>>
>>>>>>>> <xs:complexType name="VehOwnerHolderByChassisAndDateType">
>>>>>>>> <xs:sequence>
>>>>>>>> <xs:element name="Header" type="HeaderType"/>
>>>>>>>> <xs:element name="Body">
>>>>>>>> <xs:complexType>
>>>>>>>> <xs:sequence>
>>>>>>>> <xs:element name="Request">
>>>>>>>> <xs:complexType>
>>>>>>>> <xs:sequence>
>>>>>>>> <xs:element name="VehCountryReq"
>>>>>>>> type="xs:string" nillable="false"/>
>>>>>>>> <xs:element
>>>>>>>> name="VehIdentificationNumberReq" type="xs:string"/>
>>>>>>>> <xs:element
>>>>>>>> name="ReferenceDateTimeReq"
>>>>>>>> type="xs:dateTime" minOccurs="0"/>
>>>>>>>> </xs:sequence>
>>>>>>>> </xs:complexType>
>>>>>>>> </xs:element>
>>>>>>>> </xs:sequence>
>>>>>>>> </xs:complexType>
>>>>>>>> </xs:element>
>>>>>>>> </xs:sequence>
>>>>>>>> </xs:complexType>
>>>>>>>>
>>>>>>>> Generated-code:
>>>>>>>>
>>>>>>>> @XmlAccessorType(XmlAccessType.FIELD)
>>>>>>>> @XmlType(name = "", propOrder = {
>>>>>>>> "vehOwnerHolderByChassisAndDate"
>>>>>>>> })
>>>>>>>> @XmlRootElement(name = "GetVehicleOwnerHolderByChassisAndDate")
>>>>>>>> public class GetVehicleOwnerHolderByChassisAndDate {
>>>>>>>>
>>>>>>>> @XmlElement(name = "VehOwnerHolderByChassisAndDate")
>>>>>>>> protected
>>>>>>>> GetVehicleOwnerHolderByChassisAndDate
>>>>>>>> .VehOwnerHolderByChassisAndDate
>>>>>>>> vehOwnerHolderByChassisAndDate;
>>>>>>>>
>>>>>>>>
>>>>>>>> public
>>>>>>>> GetVehicleOwnerHolderByChassisAndDate
>>>>>>>> .VehOwnerHolderByChassisAndDate
>>>>>>>> getVehOwnerHolderByChassisAndDate() {
>>>>>>>> return vehOwnerHolderByChassisAndDate;
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> public void
>>>>>>>> setVehOwnerHolderByChassisAndDate
>>>>>>>> (GetVehicleOwnerHolderByChassisAndDate
>>>>>>>> .VehOwnerHolderByChassisAndDate
>>>>>>>> value) {
>>>>>>>> this.vehOwnerHolderByChassisAndDate = value;
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> */
>>>>>>>> @XmlAccessorType(XmlAccessType.FIELD)
>>>>>>>> @XmlType(name = "", propOrder = {
>>>>>>>> "content"
>>>>>>>> })
>>>>>>>> public static class VehOwnerHolderByChassisAndDate {
>>>>>>>>
>>>>>>>> @XmlMixed
>>>>>>>> @XmlAnyElement(lax = true)
>>>>>>>> protected List content;
>>>>>>>>
>>>>>>>>
>>>>>>>> public List getContent() {
>>>>>>>> if (content == null) {
>>>>>>>> content = new ArrayList();
>>>>>>>> }
>>>>>>>> return this.content;
>>>>>>>> }
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17983289.html
>>>>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> Daniel Kulp
>>>>>>> dkulp@apache.org
>>>>>>> http://www.dankulp.com/blog
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17998010.html
>>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>>
>>>>>
>>>>> ---
>>>>> Daniel Kulp
>>>>> dkulp@apache.org
>>>>> http://www.dankulp.com/blog
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p18025827.html
>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>
>>>
>>> ---
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p18085999.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF, trouble to find Classes to unmarshal to
Posted by MathisMohr <ma...@aol.com>.
I got a little deeper into this xmlns="" thing. If I send a plain xml
message to my system (with another, rather "custom" client) that contains
the xmlns="" part, the message is refused, or rather not unmarshalled (the
phenomena I witness when I try to get the "real" client working.
But once I remove that part, it works. Instead of the obnoxious
ElementNSImpl instances I get my content wrapped up in JAXBElements, ready
for further processing.
Now, since I do not have any influence on the "real" client, and this
workaround only works on my "custom" one..would it be possible to eliminate
that part before the Message gets processed? Kinda like an interceptor, that
reads the soapmessage, looks for the appropriate element and rewrites it?
MathisMohr wrote:
>
>
> So, as far as I understand it, if I "include" my xsd-files (without any
> targetNamespace information) into my wsdl-schema (which has a
> targetNamespace information) these attributes should be inherited by the
> xsds..or not?
>
> I peeked a little deeper into what is actually sent by the other side to
> my webservice, and stumbled upon this:
>
> (...)
> <soap:Body>
> <GetVehicleOwnerHolderByChassisAndDate
> xmlns="http://services.eucaris.net/">
> <VehOwnerHolderByChassisAndDate>
> <VehOwnerHolderByChassisAndDate
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="">
> (...)
>
> As far as I understand it, that part should determine to what schema the
> following elements without prefix belong..but the client is leaving it
> blank, or even setting it to a blank value. Could this be the reason why
> JaxB doesnt recognize it on my side? Just a thought.
>
> Another thing I tried was to willingly alter the wsdl to not accept
> "xsd:any" any more but to force it to accept the
> "VehOwnerHolderByChassisAndDateType" from my xsds instead. This doesnt
> work at all, all content is being rejected. Funny thing though, if I do it
> that way I have a clear connection between all types, but whatever junk
> the client sends doesnt seem to fit in..
>
>
>
> dkulp wrote:
>>
>>
>> I have a feeling that lack of the target namespace is going to be an
>> issue. The elements need to be namespace qualified for JAXB to look
>> it up in it's internal maps.
>>
>>
>> I just dug around a bit and discovered:
>>
>> http://www.xfront.com/ZeroOneOrManyNamespaces.html#mixed
>>
>> Thus, it looks like you should use an "include", not an "import" for
>> this. However, that will bring those types in the same namespace.
>> If the server isn't namespace qualifying that element on the wire,
>> JAXB still won't be able to do anything with it.
>>
>>
>> Dan
>>
>>
>>
>> On Jun 20, 2008, at 5:08 AM, MathisMohr wrote:
>>
>>>
>>> Another day and another try, well..
>>>
>>> 1.: I'm rather new to xml/xsd/wsdl/webservice/cxf and all the files
>>> were
>>> provided by our partner, who developed the other side of the
>>> webservice, so
>>> I hoped it would work out of the box (I cant ask him, he's working
>>> with
>>> .Net). The xsd-files do not define a targetNamespace at all, nor do
>>> they
>>> contain a namespace except the XML-Schema one, this looks
>>> suspicious..could
>>> it be that this is the reason? Here's a more accurate snippet (the
>>> original,
>>> totally unmodified version I was supplied with). I already tried
>>> adding the
>>> targetNamespace into the XSDs, but I had no luck. Can you give me a
>>> hint on
>>> this?
>>>
>>> WSDL:
>>> <?xml version="1.0" encoding="utf-8"?>
>>> <definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
>>> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
>>> xmlns:s="http://www.w3.org/2001/XMLSchema"
>>> xmlns:s0="http://services.eucaris.net/"
>>> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
>>> xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
>>> xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
>>> targetNamespace="http://services.eucaris.net/"
>>> xmlns="http://schemas.xmlsoap.org/wsdl/">
>>> <types>
>>> <s:schema elementFormDefault="qualified"
>>> targetNamespace="http://services.eucaris.net/">
>>> <!-- This is were I had my imports -->
>>> <s:element name="GetVehicleOwnerHolderByChassisAndDate">
>>> <s:complexType>
>>> <s:sequence>
>>> <s:element minOccurs="0" maxOccurs="1"
>>> name="VehOwnerHolderByChassisAndDate">
>>> <s:complexType mixed="true">
>>> <s:sequence>
>>> <s:any />
>>> </s:sequence>
>>> </s:complexType>
>>> </s:element>
>>> </s:sequence>
>>> </s:complexType>
>>> </s:element>
>>> (..more elements)
>>>
>>> XSD:
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <!-- XSD version v1.0.2 -->
>>>
>>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>> elementFormDefault="qualified">
>>> <xs:include schemaLocation="EucarisIIHeader.xsd"/>
>>>
>>> <xs:element name="VehOwnerHolderByChassisAndDate"
>>> type="VehOwnerHolderByChassisAndDateType"/>
>>>
>>> <xs:complexType name="VehOwnerHolderByChassisAndDateType">
>>> <xs:sequence>
>>> <xs:element name="Header" type="HeaderType"/>
>>> <xs:element name="Body">
>>> <xs:complexType>
>>> <xs:sequence>
>>> <xs:element name="Request">
>>> <xs:complexType>
>>> <xs:sequence>
>>> <xs:element name="VehCountryReq" type="xs:string"
>>> nillable="false"/>
>>> <xs:element name="VehIdentificationNumberReq"
>>> type="xs:string"/>
>>> <xs:element name="ReferenceDateTimeReq" type="xs:dateTime"
>>> minOccurs="0"/>
>>> </xs:sequence>
>>> </xs:complexType>
>>> </xs:element>
>>> </xs:sequence>
>>> </xs:complexType>
>>> </xs:element>
>>> </xs:sequence>
>>> </xs:complexType>
>>> </xs:schema>
>>>
>>>
>>> 2.: Here, I followed the idea of generating each schema in a different
>>> package (horrible until now, because now I have 5-6 implementations of
>>> basically always the same type, but anyway for now). Adding the
>>> Objectfactories of these packages to the Serviceinterface or its
>>> Impl didnt
>>> work either. Same error, and it's probably just related to 1.).
>>>
>>>
>>> dkulp wrote:
>>>>
>>>>
>>>> On Jun 19, 2008, at 2:17 AM, MathisMohr wrote:
>>>>
>>>>>
>>>>> Ok I tried 2 things, both with no luck:
>>>>>
>>>>> 1.) I inlcuded the xsd-files into the wsdl, so that everything in
>>>>> generated
>>>>> in one move. It works, all the classes are being generated in one
>>>>> package
>>>>> (ie com.foo.generated.wsdl). Yet still, my test refuses to
>>>>> unmarshall the
>>>>> "inner" elements.
>>>>
>>>> That's actually probably bad. Are you using the -p option to map
>>>> them all to one package? Or are all the schemas specifying the same
>>>> targetNamespace? (in which case it should be an include, not import)
>>>>
>>>> The -p thing is really bad with multiple schemas. I've logged a bug
>>>> about it:
>>>> https://issues.apache.org/jira/browse/CXF-1662
>>>>
>>>>> 2.) Without this inclusion, I added the ObjectFactory of the
>>>>> seperatly
>>>>> generated xsd-classes (ie com.foo.generated.xsd) to my PortType. But
>>>>> in this
>>>>> case, it doesnt work as well. Yet this may be my fault, is my
>>>>> placement of
>>>>> the annotation (at the implementation of the serviceinterface)
>>>>> correct?
>>>>
>>>> Maybe. Possibly on the impl instead. I'm not really sure. :-(
>>>>
>>>> If you use the 2.1.1 version that we are currently voting on, you can
>>>> also use spring config to add the classes:
>>>>
>>>>
>>>> <!-- Endpoint -->
>>>> <jaxws:endpoint id="testEndpoint"
>>>> implementor="org.apache.cxf.systest.jaxb.service.TestServiceImpl"
>>>> address="http://localhost:7081/service/TestEndpoint">
>>>>
>>>> <jaxws:properties>
>>>> <entry key="jaxb.additionalContextClasses">
>>>> <bean
>>>> class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
>>>> <property name="classNames">
>>>> <list>
>>>> <value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</
>>>> value>
>>>> </list>
>>>> </property>
>>>> </bean>
>>>> </entry>
>>>> </jaxws:properties>
>>>> </jaxws:endpoint>
>>>>
>>>> 2.1.1 can be downloaded from:
>>>> http://people.apache.org/~dkulp/stage_cxf/2.1.1/
>>>>
>>>> It will hopefully be released tomorrow.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>
>>>>> Another thing that came up, yet illogical, is: Could it be, that the
>>>>> Elements, which are not unmarshalled simply don't match my generated
>>>>> classes? But that really defies logic, the testclient AND the wsdl
>>>>> were
>>>>> supplied together..
>>>>>
>>>>>
>>>>> dkulp wrote:
>>>>>>
>>>>>>
>>>>>> This is much easier with 2.1, so stick with that.......
>>>>>>
>>>>>> As you surmised, by default, the runtime only knows about the types
>>>>>> that are references in the generated code from the wsdl. One
>>>>>> solution is to add imports in the wsdl to import the other schemas
>>>>>> and
>>>>>> regenerate.
>>>>>>
>>>>>> The other option is to tell CXF about the other types that you want
>>>>>> it
>>>>>> to accept. The JAXB @XmlSeeAlso annotation is the easiest way
>>>>>> to do
>>>>>> that. If you generate objects from your other schemas with xjc,
>>>>>> it
>>>>>> probably generated a ObjectFactory class. Just add:
>>>>>> @XmlSeeAlso({com.foo.blah.ObjectFactory.class})
>>>>>> to you code to have jaxb pick that up.
>>>>>>
>>>>>> There are ways of doing it via configuration and properties and
>>>>>> such,
>>>>>> but the XmlSeeAlso is probably the easiest, at least to get started
>>>>>> to
>>>>>> make sure it will work for you.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jun 18, 2008, at 9:58 AM, MathisMohr wrote:
>>>>>>
>>>>>>>
>>>>>>> My Problem is:
>>>>>>>
>>>>>>> I am to create a webservice. I'm currently using CXF 2.1, but that
>>>>>>> doesnt
>>>>>>> seem to be the point, I also tried 2.0.6 and 2.0.7. with no
>>>>>>> different
>>>>>>> outcome.
>>>>>>> I have the WSDL and some XSD files defining the main request and
>>>>>>> response
>>>>>>> messages. Thing is, the WSDL only defines 2 elements, and then
>>>>>>> refers to a
>>>>>>> xsd:any element, so it would accept every data that follows. There
>>>>>>> is no
>>>>>>> clear connection to the XSDs. I can generate Java Code out of them
>>>>>>> though.
>>>>>>> Now when I use Jetty to start the webservice on my machine I see
>>>>>>> that it is
>>>>>>> working. I can send messages to the webservice, but CXF only seems
>>>>>>> to
>>>>>>> unmarshall the elements which are defined in the wsdl, everything
>>>>>>> else is
>>>>>>> being summed up in an instance of ElementNSImpl (from xerces).
>>>>>>> Thanks to
>>>>>>> debugging my webservice I found out that this Object actually has
>>>>>>> all my
>>>>>>> information in it, in some kind of DOM-Tree, it's just not being
>>>>>>> unmarshalled. As far as I see it, it seems that JaxB either doesnt
>>>>>>> recognize
>>>>>>> the generated files of the xsd's (because there is no connection
>>>>>>> between the
>>>>>>> wsdl and the xsds) or JaxB doesnt accept them. Either way, I
>>>>>>> have no
>>>>>>> solution. Can someone help me?
>>>>>>>
>>>>>>> wsdl-snippet:
>>>>>>>
>>>>>>> <s:element name="GetVehicleOwnerHolderByChassisAndDate">
>>>>>>> <s:complexType>
>>>>>>> <s:sequence>
>>>>>>> <s:element minOccurs="0" maxOccurs="1"
>>>>>>> name="VehOwnerHolderByChassisAndDate">
>>>>>>> <s:complexType mixed="true">
>>>>>>> <sequence>
>>>>>>> <s:any />
>>>>>>> </s:sequence>
>>>>>>> </s:complexType>
>>>>>>> </s:element>
>>>>>>> </s:sequence>
>>>>>>> </s:complexType>
>>>>>>> </s:element>
>>>>>>>
>>>>>>> Xsd-snippet:
>>>>>>>
>>>>>>> <xs:element name="VehOwnerHolderByChassisAndDate"
>>>>>>> type="VehOwnerHolderByChassisAndDateType"/>
>>>>>>>
>>>>>>> <xs:complexType name="VehOwnerHolderByChassisAndDateType">
>>>>>>> <xs:sequence>
>>>>>>> <xs:element name="Header" type="HeaderType"/>
>>>>>>> <xs:element name="Body">
>>>>>>> <xs:complexType>
>>>>>>> <xs:sequence>
>>>>>>> <xs:element name="Request">
>>>>>>> <xs:complexType>
>>>>>>> <xs:sequence>
>>>>>>> <xs:element name="VehCountryReq"
>>>>>>> type="xs:string" nillable="false"/>
>>>>>>> <xs:element
>>>>>>> name="VehIdentificationNumberReq" type="xs:string"/>
>>>>>>> <xs:element
>>>>>>> name="ReferenceDateTimeReq"
>>>>>>> type="xs:dateTime" minOccurs="0"/>
>>>>>>> </xs:sequence>
>>>>>>> </xs:complexType>
>>>>>>> </xs:element>
>>>>>>> </xs:sequence>
>>>>>>> </xs:complexType>
>>>>>>> </xs:element>
>>>>>>> </xs:sequence>
>>>>>>> </xs:complexType>
>>>>>>>
>>>>>>> Generated-code:
>>>>>>>
>>>>>>> @XmlAccessorType(XmlAccessType.FIELD)
>>>>>>> @XmlType(name = "", propOrder = {
>>>>>>> "vehOwnerHolderByChassisAndDate"
>>>>>>> })
>>>>>>> @XmlRootElement(name = "GetVehicleOwnerHolderByChassisAndDate")
>>>>>>> public class GetVehicleOwnerHolderByChassisAndDate {
>>>>>>>
>>>>>>> @XmlElement(name = "VehOwnerHolderByChassisAndDate")
>>>>>>> protected
>>>>>>> GetVehicleOwnerHolderByChassisAndDate
>>>>>>> .VehOwnerHolderByChassisAndDate
>>>>>>> vehOwnerHolderByChassisAndDate;
>>>>>>>
>>>>>>>
>>>>>>> public
>>>>>>> GetVehicleOwnerHolderByChassisAndDate
>>>>>>> .VehOwnerHolderByChassisAndDate
>>>>>>> getVehOwnerHolderByChassisAndDate() {
>>>>>>> return vehOwnerHolderByChassisAndDate;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> public void
>>>>>>> setVehOwnerHolderByChassisAndDate
>>>>>>> (GetVehicleOwnerHolderByChassisAndDate
>>>>>>> .VehOwnerHolderByChassisAndDate
>>>>>>> value) {
>>>>>>> this.vehOwnerHolderByChassisAndDate = value;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> */
>>>>>>> @XmlAccessorType(XmlAccessType.FIELD)
>>>>>>> @XmlType(name = "", propOrder = {
>>>>>>> "content"
>>>>>>> })
>>>>>>> public static class VehOwnerHolderByChassisAndDate {
>>>>>>>
>>>>>>> @XmlMixed
>>>>>>> @XmlAnyElement(lax = true)
>>>>>>> protected List content;
>>>>>>>
>>>>>>>
>>>>>>> public List getContent() {
>>>>>>> if (content == null) {
>>>>>>> content = new ArrayList();
>>>>>>> }
>>>>>>> return this.content;
>>>>>>> }
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17983289.html
>>>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Daniel Kulp
>>>>>> dkulp@apache.org
>>>>>> http://www.dankulp.com/blog
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17998010.html
>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>
>>>>
>>>> ---
>>>> Daniel Kulp
>>>> dkulp@apache.org
>>>> http://www.dankulp.com/blog
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p18025827.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>
>> ---
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>>
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p18067086.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF, trouble to find Classes to unmarshal to
Posted by MathisMohr <ma...@aol.com>.
So, as far as I understand it, if I "include" my xsd-files (without any
targetNamespace information) into my wsdl-schema (which has a
targetNamespace information) these attributes should be inherited by the
xsds..or not?
I peeked a little deeper into what is actually sent by the other side to my
webservice, and stumbled upon this:
(...)
<soap:Body>
<GetVehicleOwnerHolderByChassisAndDate
xmlns="http://services.eucaris.net/">
<VehOwnerHolderByChassisAndDate>
<VehOwnerHolderByChassisAndDate
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="">
(...)
As far as I understand it, that part should determine to what schema the
following elements without prefix belong..but the client is leaving it
blank, or even setting it to a blank value. Could this be the reason why
JaxB doesnt recognize it on my side? Just a thought.
Another thing I tried was to willingly alter the wsdl to not accept
"xsd:any" any more but to force it to accept the
"VehOwnerHolderByChassisAndDateType" from my xsds instead. This doesnt work
at all, all content is being rejected. Funny thing though, if I do it that
way I have a clear connection between all types, but whatever junk the
client sends doesnt seem to fit in..
dkulp wrote:
>
>
> I have a feeling that lack of the target namespace is going to be an
> issue. The elements need to be namespace qualified for JAXB to look
> it up in it's internal maps.
>
>
> I just dug around a bit and discovered:
>
> http://www.xfront.com/ZeroOneOrManyNamespaces.html#mixed
>
> Thus, it looks like you should use an "include", not an "import" for
> this. However, that will bring those types in the same namespace.
> If the server isn't namespace qualifying that element on the wire,
> JAXB still won't be able to do anything with it.
>
>
> Dan
>
>
>
> On Jun 20, 2008, at 5:08 AM, MathisMohr wrote:
>
>>
>> Another day and another try, well..
>>
>> 1.: I'm rather new to xml/xsd/wsdl/webservice/cxf and all the files
>> were
>> provided by our partner, who developed the other side of the
>> webservice, so
>> I hoped it would work out of the box (I cant ask him, he's working
>> with
>> .Net). The xsd-files do not define a targetNamespace at all, nor do
>> they
>> contain a namespace except the XML-Schema one, this looks
>> suspicious..could
>> it be that this is the reason? Here's a more accurate snippet (the
>> original,
>> totally unmodified version I was supplied with). I already tried
>> adding the
>> targetNamespace into the XSDs, but I had no luck. Can you give me a
>> hint on
>> this?
>>
>> WSDL:
>> <?xml version="1.0" encoding="utf-8"?>
>> <definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
>> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
>> xmlns:s="http://www.w3.org/2001/XMLSchema"
>> xmlns:s0="http://services.eucaris.net/"
>> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
>> xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
>> xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
>> targetNamespace="http://services.eucaris.net/"
>> xmlns="http://schemas.xmlsoap.org/wsdl/">
>> <types>
>> <s:schema elementFormDefault="qualified"
>> targetNamespace="http://services.eucaris.net/">
>> <!-- This is were I had my imports -->
>> <s:element name="GetVehicleOwnerHolderByChassisAndDate">
>> <s:complexType>
>> <s:sequence>
>> <s:element minOccurs="0" maxOccurs="1"
>> name="VehOwnerHolderByChassisAndDate">
>> <s:complexType mixed="true">
>> <s:sequence>
>> <s:any />
>> </s:sequence>
>> </s:complexType>
>> </s:element>
>> </s:sequence>
>> </s:complexType>
>> </s:element>
>> (..more elements)
>>
>> XSD:
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!-- XSD version v1.0.2 -->
>>
>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>> elementFormDefault="qualified">
>> <xs:include schemaLocation="EucarisIIHeader.xsd"/>
>>
>> <xs:element name="VehOwnerHolderByChassisAndDate"
>> type="VehOwnerHolderByChassisAndDateType"/>
>>
>> <xs:complexType name="VehOwnerHolderByChassisAndDateType">
>> <xs:sequence>
>> <xs:element name="Header" type="HeaderType"/>
>> <xs:element name="Body">
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element name="Request">
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element name="VehCountryReq" type="xs:string"
>> nillable="false"/>
>> <xs:element name="VehIdentificationNumberReq"
>> type="xs:string"/>
>> <xs:element name="ReferenceDateTimeReq" type="xs:dateTime"
>> minOccurs="0"/>
>> </xs:sequence>
>> </xs:complexType>
>> </xs:element>
>> </xs:sequence>
>> </xs:complexType>
>> </xs:element>
>> </xs:sequence>
>> </xs:complexType>
>> </xs:schema>
>>
>>
>> 2.: Here, I followed the idea of generating each schema in a different
>> package (horrible until now, because now I have 5-6 implementations of
>> basically always the same type, but anyway for now). Adding the
>> Objectfactories of these packages to the Serviceinterface or its
>> Impl didnt
>> work either. Same error, and it's probably just related to 1.).
>>
>>
>> dkulp wrote:
>>>
>>>
>>> On Jun 19, 2008, at 2:17 AM, MathisMohr wrote:
>>>
>>>>
>>>> Ok I tried 2 things, both with no luck:
>>>>
>>>> 1.) I inlcuded the xsd-files into the wsdl, so that everything in
>>>> generated
>>>> in one move. It works, all the classes are being generated in one
>>>> package
>>>> (ie com.foo.generated.wsdl). Yet still, my test refuses to
>>>> unmarshall the
>>>> "inner" elements.
>>>
>>> That's actually probably bad. Are you using the -p option to map
>>> them all to one package? Or are all the schemas specifying the same
>>> targetNamespace? (in which case it should be an include, not import)
>>>
>>> The -p thing is really bad with multiple schemas. I've logged a bug
>>> about it:
>>> https://issues.apache.org/jira/browse/CXF-1662
>>>
>>>> 2.) Without this inclusion, I added the ObjectFactory of the
>>>> seperatly
>>>> generated xsd-classes (ie com.foo.generated.xsd) to my PortType. But
>>>> in this
>>>> case, it doesnt work as well. Yet this may be my fault, is my
>>>> placement of
>>>> the annotation (at the implementation of the serviceinterface)
>>>> correct?
>>>
>>> Maybe. Possibly on the impl instead. I'm not really sure. :-(
>>>
>>> If you use the 2.1.1 version that we are currently voting on, you can
>>> also use spring config to add the classes:
>>>
>>>
>>> <!-- Endpoint -->
>>> <jaxws:endpoint id="testEndpoint"
>>> implementor="org.apache.cxf.systest.jaxb.service.TestServiceImpl"
>>> address="http://localhost:7081/service/TestEndpoint">
>>>
>>> <jaxws:properties>
>>> <entry key="jaxb.additionalContextClasses">
>>> <bean
>>> class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
>>> <property name="classNames">
>>> <list>
>>> <value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</
>>> value>
>>> </list>
>>> </property>
>>> </bean>
>>> </entry>
>>> </jaxws:properties>
>>> </jaxws:endpoint>
>>>
>>> 2.1.1 can be downloaded from:
>>> http://people.apache.org/~dkulp/stage_cxf/2.1.1/
>>>
>>> It will hopefully be released tomorrow.
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>> Another thing that came up, yet illogical, is: Could it be, that the
>>>> Elements, which are not unmarshalled simply don't match my generated
>>>> classes? But that really defies logic, the testclient AND the wsdl
>>>> were
>>>> supplied together..
>>>>
>>>>
>>>> dkulp wrote:
>>>>>
>>>>>
>>>>> This is much easier with 2.1, so stick with that.......
>>>>>
>>>>> As you surmised, by default, the runtime only knows about the types
>>>>> that are references in the generated code from the wsdl. One
>>>>> solution is to add imports in the wsdl to import the other schemas
>>>>> and
>>>>> regenerate.
>>>>>
>>>>> The other option is to tell CXF about the other types that you want
>>>>> it
>>>>> to accept. The JAXB @XmlSeeAlso annotation is the easiest way
>>>>> to do
>>>>> that. If you generate objects from your other schemas with xjc,
>>>>> it
>>>>> probably generated a ObjectFactory class. Just add:
>>>>> @XmlSeeAlso({com.foo.blah.ObjectFactory.class})
>>>>> to you code to have jaxb pick that up.
>>>>>
>>>>> There are ways of doing it via configuration and properties and
>>>>> such,
>>>>> but the XmlSeeAlso is probably the easiest, at least to get started
>>>>> to
>>>>> make sure it will work for you.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Jun 18, 2008, at 9:58 AM, MathisMohr wrote:
>>>>>
>>>>>>
>>>>>> My Problem is:
>>>>>>
>>>>>> I am to create a webservice. I'm currently using CXF 2.1, but that
>>>>>> doesnt
>>>>>> seem to be the point, I also tried 2.0.6 and 2.0.7. with no
>>>>>> different
>>>>>> outcome.
>>>>>> I have the WSDL and some XSD files defining the main request and
>>>>>> response
>>>>>> messages. Thing is, the WSDL only defines 2 elements, and then
>>>>>> refers to a
>>>>>> xsd:any element, so it would accept every data that follows. There
>>>>>> is no
>>>>>> clear connection to the XSDs. I can generate Java Code out of them
>>>>>> though.
>>>>>> Now when I use Jetty to start the webservice on my machine I see
>>>>>> that it is
>>>>>> working. I can send messages to the webservice, but CXF only seems
>>>>>> to
>>>>>> unmarshall the elements which are defined in the wsdl, everything
>>>>>> else is
>>>>>> being summed up in an instance of ElementNSImpl (from xerces).
>>>>>> Thanks to
>>>>>> debugging my webservice I found out that this Object actually has
>>>>>> all my
>>>>>> information in it, in some kind of DOM-Tree, it's just not being
>>>>>> unmarshalled. As far as I see it, it seems that JaxB either doesnt
>>>>>> recognize
>>>>>> the generated files of the xsd's (because there is no connection
>>>>>> between the
>>>>>> wsdl and the xsds) or JaxB doesnt accept them. Either way, I
>>>>>> have no
>>>>>> solution. Can someone help me?
>>>>>>
>>>>>> wsdl-snippet:
>>>>>>
>>>>>> <s:element name="GetVehicleOwnerHolderByChassisAndDate">
>>>>>> <s:complexType>
>>>>>> <s:sequence>
>>>>>> <s:element minOccurs="0" maxOccurs="1"
>>>>>> name="VehOwnerHolderByChassisAndDate">
>>>>>> <s:complexType mixed="true">
>>>>>> <sequence>
>>>>>> <s:any />
>>>>>> </s:sequence>
>>>>>> </s:complexType>
>>>>>> </s:element>
>>>>>> </s:sequence>
>>>>>> </s:complexType>
>>>>>> </s:element>
>>>>>>
>>>>>> Xsd-snippet:
>>>>>>
>>>>>> <xs:element name="VehOwnerHolderByChassisAndDate"
>>>>>> type="VehOwnerHolderByChassisAndDateType"/>
>>>>>>
>>>>>> <xs:complexType name="VehOwnerHolderByChassisAndDateType">
>>>>>> <xs:sequence>
>>>>>> <xs:element name="Header" type="HeaderType"/>
>>>>>> <xs:element name="Body">
>>>>>> <xs:complexType>
>>>>>> <xs:sequence>
>>>>>> <xs:element name="Request">
>>>>>> <xs:complexType>
>>>>>> <xs:sequence>
>>>>>> <xs:element name="VehCountryReq"
>>>>>> type="xs:string" nillable="false"/>
>>>>>> <xs:element
>>>>>> name="VehIdentificationNumberReq" type="xs:string"/>
>>>>>> <xs:element
>>>>>> name="ReferenceDateTimeReq"
>>>>>> type="xs:dateTime" minOccurs="0"/>
>>>>>> </xs:sequence>
>>>>>> </xs:complexType>
>>>>>> </xs:element>
>>>>>> </xs:sequence>
>>>>>> </xs:complexType>
>>>>>> </xs:element>
>>>>>> </xs:sequence>
>>>>>> </xs:complexType>
>>>>>>
>>>>>> Generated-code:
>>>>>>
>>>>>> @XmlAccessorType(XmlAccessType.FIELD)
>>>>>> @XmlType(name = "", propOrder = {
>>>>>> "vehOwnerHolderByChassisAndDate"
>>>>>> })
>>>>>> @XmlRootElement(name = "GetVehicleOwnerHolderByChassisAndDate")
>>>>>> public class GetVehicleOwnerHolderByChassisAndDate {
>>>>>>
>>>>>> @XmlElement(name = "VehOwnerHolderByChassisAndDate")
>>>>>> protected
>>>>>> GetVehicleOwnerHolderByChassisAndDate
>>>>>> .VehOwnerHolderByChassisAndDate
>>>>>> vehOwnerHolderByChassisAndDate;
>>>>>>
>>>>>>
>>>>>> public
>>>>>> GetVehicleOwnerHolderByChassisAndDate
>>>>>> .VehOwnerHolderByChassisAndDate
>>>>>> getVehOwnerHolderByChassisAndDate() {
>>>>>> return vehOwnerHolderByChassisAndDate;
>>>>>> }
>>>>>>
>>>>>>
>>>>>> public void
>>>>>> setVehOwnerHolderByChassisAndDate
>>>>>> (GetVehicleOwnerHolderByChassisAndDate
>>>>>> .VehOwnerHolderByChassisAndDate
>>>>>> value) {
>>>>>> this.vehOwnerHolderByChassisAndDate = value;
>>>>>> }
>>>>>>
>>>>>>
>>>>>> */
>>>>>> @XmlAccessorType(XmlAccessType.FIELD)
>>>>>> @XmlType(name = "", propOrder = {
>>>>>> "content"
>>>>>> })
>>>>>> public static class VehOwnerHolderByChassisAndDate {
>>>>>>
>>>>>> @XmlMixed
>>>>>> @XmlAnyElement(lax = true)
>>>>>> protected List content;
>>>>>>
>>>>>>
>>>>>> public List getContent() {
>>>>>> if (content == null) {
>>>>>> content = new ArrayList();
>>>>>> }
>>>>>> return this.content;
>>>>>> }
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17983289.html
>>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>>
>>>>>
>>>>> ---
>>>>> Daniel Kulp
>>>>> dkulp@apache.org
>>>>> http://www.dankulp.com/blog
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17998010.html
>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>
>>>
>>> ---
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p18025827.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p18065759.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF, trouble to find Classes to unmarshal to
Posted by Daniel Kulp <dk...@apache.org>.
I have a feeling that lack of the target namespace is going to be an
issue. The elements need to be namespace qualified for JAXB to look
it up in it's internal maps.
I just dug around a bit and discovered:
http://www.xfront.com/ZeroOneOrManyNamespaces.html#mixed
Thus, it looks like you should use an "include", not an "import" for
this. However, that will bring those types in the same namespace.
If the server isn't namespace qualifying that element on the wire,
JAXB still won't be able to do anything with it.
Dan
On Jun 20, 2008, at 5:08 AM, MathisMohr wrote:
>
> Another day and another try, well..
>
> 1.: I'm rather new to xml/xsd/wsdl/webservice/cxf and all the files
> were
> provided by our partner, who developed the other side of the
> webservice, so
> I hoped it would work out of the box (I cant ask him, he's working
> with
> .Net). The xsd-files do not define a targetNamespace at all, nor do
> they
> contain a namespace except the XML-Schema one, this looks
> suspicious..could
> it be that this is the reason? Here's a more accurate snippet (the
> original,
> totally unmodified version I was supplied with). I already tried
> adding the
> targetNamespace into the XSDs, but I had no luck. Can you give me a
> hint on
> this?
>
> WSDL:
> <?xml version="1.0" encoding="utf-8"?>
> <definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
> xmlns:s="http://www.w3.org/2001/XMLSchema"
> xmlns:s0="http://services.eucaris.net/"
> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
> xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
> xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
> targetNamespace="http://services.eucaris.net/"
> xmlns="http://schemas.xmlsoap.org/wsdl/">
> <types>
> <s:schema elementFormDefault="qualified"
> targetNamespace="http://services.eucaris.net/">
> <!-- This is were I had my imports -->
> <s:element name="GetVehicleOwnerHolderByChassisAndDate">
> <s:complexType>
> <s:sequence>
> <s:element minOccurs="0" maxOccurs="1"
> name="VehOwnerHolderByChassisAndDate">
> <s:complexType mixed="true">
> <s:sequence>
> <s:any />
> </s:sequence>
> </s:complexType>
> </s:element>
> </s:sequence>
> </s:complexType>
> </s:element>
> (..more elements)
>
> XSD:
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- XSD version v1.0.2 -->
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified">
> <xs:include schemaLocation="EucarisIIHeader.xsd"/>
>
> <xs:element name="VehOwnerHolderByChassisAndDate"
> type="VehOwnerHolderByChassisAndDateType"/>
>
> <xs:complexType name="VehOwnerHolderByChassisAndDateType">
> <xs:sequence>
> <xs:element name="Header" type="HeaderType"/>
> <xs:element name="Body">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="Request">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="VehCountryReq" type="xs:string"
> nillable="false"/>
> <xs:element name="VehIdentificationNumberReq"
> type="xs:string"/>
> <xs:element name="ReferenceDateTimeReq" type="xs:dateTime"
> minOccurs="0"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
> </xs:schema>
>
>
> 2.: Here, I followed the idea of generating each schema in a different
> package (horrible until now, because now I have 5-6 implementations of
> basically always the same type, but anyway for now). Adding the
> Objectfactories of these packages to the Serviceinterface or its
> Impl didnt
> work either. Same error, and it's probably just related to 1.).
>
>
> dkulp wrote:
>>
>>
>> On Jun 19, 2008, at 2:17 AM, MathisMohr wrote:
>>
>>>
>>> Ok I tried 2 things, both with no luck:
>>>
>>> 1.) I inlcuded the xsd-files into the wsdl, so that everything in
>>> generated
>>> in one move. It works, all the classes are being generated in one
>>> package
>>> (ie com.foo.generated.wsdl). Yet still, my test refuses to
>>> unmarshall the
>>> "inner" elements.
>>
>> That's actually probably bad. Are you using the -p option to map
>> them all to one package? Or are all the schemas specifying the same
>> targetNamespace? (in which case it should be an include, not import)
>>
>> The -p thing is really bad with multiple schemas. I've logged a bug
>> about it:
>> https://issues.apache.org/jira/browse/CXF-1662
>>
>>> 2.) Without this inclusion, I added the ObjectFactory of the
>>> seperatly
>>> generated xsd-classes (ie com.foo.generated.xsd) to my PortType. But
>>> in this
>>> case, it doesnt work as well. Yet this may be my fault, is my
>>> placement of
>>> the annotation (at the implementation of the serviceinterface)
>>> correct?
>>
>> Maybe. Possibly on the impl instead. I'm not really sure. :-(
>>
>> If you use the 2.1.1 version that we are currently voting on, you can
>> also use spring config to add the classes:
>>
>>
>> <!-- Endpoint -->
>> <jaxws:endpoint id="testEndpoint"
>> implementor="org.apache.cxf.systest.jaxb.service.TestServiceImpl"
>> address="http://localhost:7081/service/TestEndpoint">
>>
>> <jaxws:properties>
>> <entry key="jaxb.additionalContextClasses">
>> <bean
>> class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
>> <property name="classNames">
>> <list>
>> <value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</
>> value>
>> </list>
>> </property>
>> </bean>
>> </entry>
>> </jaxws:properties>
>> </jaxws:endpoint>
>>
>> 2.1.1 can be downloaded from:
>> http://people.apache.org/~dkulp/stage_cxf/2.1.1/
>>
>> It will hopefully be released tomorrow.
>>
>> Dan
>>
>>
>>
>>
>>> Another thing that came up, yet illogical, is: Could it be, that the
>>> Elements, which are not unmarshalled simply don't match my generated
>>> classes? But that really defies logic, the testclient AND the wsdl
>>> were
>>> supplied together..
>>>
>>>
>>> dkulp wrote:
>>>>
>>>>
>>>> This is much easier with 2.1, so stick with that.......
>>>>
>>>> As you surmised, by default, the runtime only knows about the types
>>>> that are references in the generated code from the wsdl. One
>>>> solution is to add imports in the wsdl to import the other schemas
>>>> and
>>>> regenerate.
>>>>
>>>> The other option is to tell CXF about the other types that you want
>>>> it
>>>> to accept. The JAXB @XmlSeeAlso annotation is the easiest way
>>>> to do
>>>> that. If you generate objects from your other schemas with xjc,
>>>> it
>>>> probably generated a ObjectFactory class. Just add:
>>>> @XmlSeeAlso({com.foo.blah.ObjectFactory.class})
>>>> to you code to have jaxb pick that up.
>>>>
>>>> There are ways of doing it via configuration and properties and
>>>> such,
>>>> but the XmlSeeAlso is probably the easiest, at least to get started
>>>> to
>>>> make sure it will work for you.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>
>>>> On Jun 18, 2008, at 9:58 AM, MathisMohr wrote:
>>>>
>>>>>
>>>>> My Problem is:
>>>>>
>>>>> I am to create a webservice. I'm currently using CXF 2.1, but that
>>>>> doesnt
>>>>> seem to be the point, I also tried 2.0.6 and 2.0.7. with no
>>>>> different
>>>>> outcome.
>>>>> I have the WSDL and some XSD files defining the main request and
>>>>> response
>>>>> messages. Thing is, the WSDL only defines 2 elements, and then
>>>>> refers to a
>>>>> xsd:any element, so it would accept every data that follows. There
>>>>> is no
>>>>> clear connection to the XSDs. I can generate Java Code out of them
>>>>> though.
>>>>> Now when I use Jetty to start the webservice on my machine I see
>>>>> that it is
>>>>> working. I can send messages to the webservice, but CXF only seems
>>>>> to
>>>>> unmarshall the elements which are defined in the wsdl, everything
>>>>> else is
>>>>> being summed up in an instance of ElementNSImpl (from xerces).
>>>>> Thanks to
>>>>> debugging my webservice I found out that this Object actually has
>>>>> all my
>>>>> information in it, in some kind of DOM-Tree, it's just not being
>>>>> unmarshalled. As far as I see it, it seems that JaxB either doesnt
>>>>> recognize
>>>>> the generated files of the xsd's (because there is no connection
>>>>> between the
>>>>> wsdl and the xsds) or JaxB doesnt accept them. Either way, I
>>>>> have no
>>>>> solution. Can someone help me?
>>>>>
>>>>> wsdl-snippet:
>>>>>
>>>>> <s:element name="GetVehicleOwnerHolderByChassisAndDate">
>>>>> <s:complexType>
>>>>> <s:sequence>
>>>>> <s:element minOccurs="0" maxOccurs="1"
>>>>> name="VehOwnerHolderByChassisAndDate">
>>>>> <s:complexType mixed="true">
>>>>> <sequence>
>>>>> <s:any />
>>>>> </s:sequence>
>>>>> </s:complexType>
>>>>> </s:element>
>>>>> </s:sequence>
>>>>> </s:complexType>
>>>>> </s:element>
>>>>>
>>>>> Xsd-snippet:
>>>>>
>>>>> <xs:element name="VehOwnerHolderByChassisAndDate"
>>>>> type="VehOwnerHolderByChassisAndDateType"/>
>>>>>
>>>>> <xs:complexType name="VehOwnerHolderByChassisAndDateType">
>>>>> <xs:sequence>
>>>>> <xs:element name="Header" type="HeaderType"/>
>>>>> <xs:element name="Body">
>>>>> <xs:complexType>
>>>>> <xs:sequence>
>>>>> <xs:element name="Request">
>>>>> <xs:complexType>
>>>>> <xs:sequence>
>>>>> <xs:element name="VehCountryReq"
>>>>> type="xs:string" nillable="false"/>
>>>>> <xs:element
>>>>> name="VehIdentificationNumberReq" type="xs:string"/>
>>>>> <xs:element
>>>>> name="ReferenceDateTimeReq"
>>>>> type="xs:dateTime" minOccurs="0"/>
>>>>> </xs:sequence>
>>>>> </xs:complexType>
>>>>> </xs:element>
>>>>> </xs:sequence>
>>>>> </xs:complexType>
>>>>> </xs:element>
>>>>> </xs:sequence>
>>>>> </xs:complexType>
>>>>>
>>>>> Generated-code:
>>>>>
>>>>> @XmlAccessorType(XmlAccessType.FIELD)
>>>>> @XmlType(name = "", propOrder = {
>>>>> "vehOwnerHolderByChassisAndDate"
>>>>> })
>>>>> @XmlRootElement(name = "GetVehicleOwnerHolderByChassisAndDate")
>>>>> public class GetVehicleOwnerHolderByChassisAndDate {
>>>>>
>>>>> @XmlElement(name = "VehOwnerHolderByChassisAndDate")
>>>>> protected
>>>>> GetVehicleOwnerHolderByChassisAndDate
>>>>> .VehOwnerHolderByChassisAndDate
>>>>> vehOwnerHolderByChassisAndDate;
>>>>>
>>>>>
>>>>> public
>>>>> GetVehicleOwnerHolderByChassisAndDate
>>>>> .VehOwnerHolderByChassisAndDate
>>>>> getVehOwnerHolderByChassisAndDate() {
>>>>> return vehOwnerHolderByChassisAndDate;
>>>>> }
>>>>>
>>>>>
>>>>> public void
>>>>> setVehOwnerHolderByChassisAndDate
>>>>> (GetVehicleOwnerHolderByChassisAndDate
>>>>> .VehOwnerHolderByChassisAndDate
>>>>> value) {
>>>>> this.vehOwnerHolderByChassisAndDate = value;
>>>>> }
>>>>>
>>>>>
>>>>> */
>>>>> @XmlAccessorType(XmlAccessType.FIELD)
>>>>> @XmlType(name = "", propOrder = {
>>>>> "content"
>>>>> })
>>>>> public static class VehOwnerHolderByChassisAndDate {
>>>>>
>>>>> @XmlMixed
>>>>> @XmlAnyElement(lax = true)
>>>>> protected List content;
>>>>>
>>>>>
>>>>> public List getContent() {
>>>>> if (content == null) {
>>>>> content = new ArrayList();
>>>>> }
>>>>> return this.content;
>>>>> }
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17983289.html
>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>
>>>>
>>>> ---
>>>> Daniel Kulp
>>>> dkulp@apache.org
>>>> http://www.dankulp.com/blog
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17998010.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>
>> ---
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p18025827.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: CXF, trouble to find Classes to unmarshal to
Posted by MathisMohr <ma...@aol.com>.
Another day and another try, well..
1.: I'm rather new to xml/xsd/wsdl/webservice/cxf and all the files were
provided by our partner, who developed the other side of the webservice, so
I hoped it would work out of the box (I cant ask him, he's working with
.Net). The xsd-files do not define a targetNamespace at all, nor do they
contain a namespace except the XML-Schema one, this looks suspicious..could
it be that this is the reason? Here's a more accurate snippet (the original,
totally unmodified version I was supplied with). I already tried adding the
targetNamespace into the XSDs, but I had no luck. Can you give me a hint on
this?
WSDL:
<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://services.eucaris.net/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://services.eucaris.net/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema elementFormDefault="qualified"
targetNamespace="http://services.eucaris.net/">
<!-- This is were I had my imports -->
<s:element name="GetVehicleOwnerHolderByChassisAndDate">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="VehOwnerHolderByChassisAndDate">
<s:complexType mixed="true">
<s:sequence>
<s:any />
</s:sequence>
</s:complexType>
</s:element>
</s:sequence>
</s:complexType>
</s:element>
(..more elements)
XSD:
<?xml version="1.0" encoding="UTF-8"?>
<!-- XSD version v1.0.2 -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:include schemaLocation="EucarisIIHeader.xsd"/>
<xs:element name="VehOwnerHolderByChassisAndDate"
type="VehOwnerHolderByChassisAndDateType"/>
<xs:complexType name="VehOwnerHolderByChassisAndDateType">
<xs:sequence>
<xs:element name="Header" type="HeaderType"/>
<xs:element name="Body">
<xs:complexType>
<xs:sequence>
<xs:element name="Request">
<xs:complexType>
<xs:sequence>
<xs:element name="VehCountryReq" type="xs:string"
nillable="false"/>
<xs:element name="VehIdentificationNumberReq" type="xs:string"/>
<xs:element name="ReferenceDateTimeReq" type="xs:dateTime"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
2.: Here, I followed the idea of generating each schema in a different
package (horrible until now, because now I have 5-6 implementations of
basically always the same type, but anyway for now). Adding the
Objectfactories of these packages to the Serviceinterface or its Impl didnt
work either. Same error, and it's probably just related to 1.).
dkulp wrote:
>
>
> On Jun 19, 2008, at 2:17 AM, MathisMohr wrote:
>
>>
>> Ok I tried 2 things, both with no luck:
>>
>> 1.) I inlcuded the xsd-files into the wsdl, so that everything in
>> generated
>> in one move. It works, all the classes are being generated in one
>> package
>> (ie com.foo.generated.wsdl). Yet still, my test refuses to
>> unmarshall the
>> "inner" elements.
>
> That's actually probably bad. Are you using the -p option to map
> them all to one package? Or are all the schemas specifying the same
> targetNamespace? (in which case it should be an include, not import)
>
> The -p thing is really bad with multiple schemas. I've logged a bug
> about it:
> https://issues.apache.org/jira/browse/CXF-1662
>
>> 2.) Without this inclusion, I added the ObjectFactory of the seperatly
>> generated xsd-classes (ie com.foo.generated.xsd) to my PortType. But
>> in this
>> case, it doesnt work as well. Yet this may be my fault, is my
>> placement of
>> the annotation (at the implementation of the serviceinterface)
>> correct?
>
> Maybe. Possibly on the impl instead. I'm not really sure. :-(
>
> If you use the 2.1.1 version that we are currently voting on, you can
> also use spring config to add the classes:
>
>
> <!-- Endpoint -->
> <jaxws:endpoint id="testEndpoint"
> implementor="org.apache.cxf.systest.jaxb.service.TestServiceImpl"
> address="http://localhost:7081/service/TestEndpoint">
>
> <jaxws:properties>
> <entry key="jaxb.additionalContextClasses">
> <bean
> class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
> <property name="classNames">
> <list>
> <value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</value>
> </list>
> </property>
> </bean>
> </entry>
> </jaxws:properties>
> </jaxws:endpoint>
>
> 2.1.1 can be downloaded from:
> http://people.apache.org/~dkulp/stage_cxf/2.1.1/
>
> It will hopefully be released tomorrow.
>
> Dan
>
>
>
>
>> Another thing that came up, yet illogical, is: Could it be, that the
>> Elements, which are not unmarshalled simply don't match my generated
>> classes? But that really defies logic, the testclient AND the wsdl
>> were
>> supplied together..
>>
>>
>> dkulp wrote:
>>>
>>>
>>> This is much easier with 2.1, so stick with that.......
>>>
>>> As you surmised, by default, the runtime only knows about the types
>>> that are references in the generated code from the wsdl. One
>>> solution is to add imports in the wsdl to import the other schemas
>>> and
>>> regenerate.
>>>
>>> The other option is to tell CXF about the other types that you want
>>> it
>>> to accept. The JAXB @XmlSeeAlso annotation is the easiest way to do
>>> that. If you generate objects from your other schemas with xjc, it
>>> probably generated a ObjectFactory class. Just add:
>>> @XmlSeeAlso({com.foo.blah.ObjectFactory.class})
>>> to you code to have jaxb pick that up.
>>>
>>> There are ways of doing it via configuration and properties and such,
>>> but the XmlSeeAlso is probably the easiest, at least to get started
>>> to
>>> make sure it will work for you.
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>> On Jun 18, 2008, at 9:58 AM, MathisMohr wrote:
>>>
>>>>
>>>> My Problem is:
>>>>
>>>> I am to create a webservice. I'm currently using CXF 2.1, but that
>>>> doesnt
>>>> seem to be the point, I also tried 2.0.6 and 2.0.7. with no
>>>> different
>>>> outcome.
>>>> I have the WSDL and some XSD files defining the main request and
>>>> response
>>>> messages. Thing is, the WSDL only defines 2 elements, and then
>>>> refers to a
>>>> xsd:any element, so it would accept every data that follows. There
>>>> is no
>>>> clear connection to the XSDs. I can generate Java Code out of them
>>>> though.
>>>> Now when I use Jetty to start the webservice on my machine I see
>>>> that it is
>>>> working. I can send messages to the webservice, but CXF only seems
>>>> to
>>>> unmarshall the elements which are defined in the wsdl, everything
>>>> else is
>>>> being summed up in an instance of ElementNSImpl (from xerces).
>>>> Thanks to
>>>> debugging my webservice I found out that this Object actually has
>>>> all my
>>>> information in it, in some kind of DOM-Tree, it's just not being
>>>> unmarshalled. As far as I see it, it seems that JaxB either doesnt
>>>> recognize
>>>> the generated files of the xsd's (because there is no connection
>>>> between the
>>>> wsdl and the xsds) or JaxB doesnt accept them. Either way, I have no
>>>> solution. Can someone help me?
>>>>
>>>> wsdl-snippet:
>>>>
>>>> <s:element name="GetVehicleOwnerHolderByChassisAndDate">
>>>> <s:complexType>
>>>> <s:sequence>
>>>> <s:element minOccurs="0" maxOccurs="1"
>>>> name="VehOwnerHolderByChassisAndDate">
>>>> <s:complexType mixed="true">
>>>> <sequence>
>>>> <s:any />
>>>> </s:sequence>
>>>> </s:complexType>
>>>> </s:element>
>>>> </s:sequence>
>>>> </s:complexType>
>>>> </s:element>
>>>>
>>>> Xsd-snippet:
>>>>
>>>> <xs:element name="VehOwnerHolderByChassisAndDate"
>>>> type="VehOwnerHolderByChassisAndDateType"/>
>>>>
>>>> <xs:complexType name="VehOwnerHolderByChassisAndDateType">
>>>> <xs:sequence>
>>>> <xs:element name="Header" type="HeaderType"/>
>>>> <xs:element name="Body">
>>>> <xs:complexType>
>>>> <xs:sequence>
>>>> <xs:element name="Request">
>>>> <xs:complexType>
>>>> <xs:sequence>
>>>> <xs:element name="VehCountryReq"
>>>> type="xs:string" nillable="false"/>
>>>> <xs:element
>>>> name="VehIdentificationNumberReq" type="xs:string"/>
>>>> <xs:element
>>>> name="ReferenceDateTimeReq"
>>>> type="xs:dateTime" minOccurs="0"/>
>>>> </xs:sequence>
>>>> </xs:complexType>
>>>> </xs:element>
>>>> </xs:sequence>
>>>> </xs:complexType>
>>>> </xs:element>
>>>> </xs:sequence>
>>>> </xs:complexType>
>>>>
>>>> Generated-code:
>>>>
>>>> @XmlAccessorType(XmlAccessType.FIELD)
>>>> @XmlType(name = "", propOrder = {
>>>> "vehOwnerHolderByChassisAndDate"
>>>> })
>>>> @XmlRootElement(name = "GetVehicleOwnerHolderByChassisAndDate")
>>>> public class GetVehicleOwnerHolderByChassisAndDate {
>>>>
>>>> @XmlElement(name = "VehOwnerHolderByChassisAndDate")
>>>> protected
>>>> GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
>>>> vehOwnerHolderByChassisAndDate;
>>>>
>>>>
>>>> public
>>>> GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
>>>> getVehOwnerHolderByChassisAndDate() {
>>>> return vehOwnerHolderByChassisAndDate;
>>>> }
>>>>
>>>>
>>>> public void
>>>> setVehOwnerHolderByChassisAndDate
>>>> (GetVehicleOwnerHolderByChassisAndDate
>>>> .VehOwnerHolderByChassisAndDate
>>>> value) {
>>>> this.vehOwnerHolderByChassisAndDate = value;
>>>> }
>>>>
>>>>
>>>> */
>>>> @XmlAccessorType(XmlAccessType.FIELD)
>>>> @XmlType(name = "", propOrder = {
>>>> "content"
>>>> })
>>>> public static class VehOwnerHolderByChassisAndDate {
>>>>
>>>> @XmlMixed
>>>> @XmlAnyElement(lax = true)
>>>> protected List content;
>>>>
>>>>
>>>> public List getContent() {
>>>> if (content == null) {
>>>> content = new ArrayList();
>>>> }
>>>> return this.content;
>>>> }
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17983289.html
>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>
>>>
>>> ---
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17998010.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p18025827.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF, trouble to find Classes to unmarshal to
Posted by Daniel Kulp <dk...@apache.org>.
On Jun 19, 2008, at 2:17 AM, MathisMohr wrote:
>
> Ok I tried 2 things, both with no luck:
>
> 1.) I inlcuded the xsd-files into the wsdl, so that everything in
> generated
> in one move. It works, all the classes are being generated in one
> package
> (ie com.foo.generated.wsdl). Yet still, my test refuses to
> unmarshall the
> "inner" elements.
That's actually probably bad. Are you using the -p option to map
them all to one package? Or are all the schemas specifying the same
targetNamespace? (in which case it should be an include, not import)
The -p thing is really bad with multiple schemas. I've logged a bug
about it:
https://issues.apache.org/jira/browse/CXF-1662
> 2.) Without this inclusion, I added the ObjectFactory of the seperatly
> generated xsd-classes (ie com.foo.generated.xsd) to my PortType. But
> in this
> case, it doesnt work as well. Yet this may be my fault, is my
> placement of
> the annotation (at the implementation of the serviceinterface)
> correct?
Maybe. Possibly on the impl instead. I'm not really sure. :-(
If you use the 2.1.1 version that we are currently voting on, you can
also use spring config to add the classes:
<!-- Endpoint -->
<jaxws:endpoint id="testEndpoint"
implementor="org.apache.cxf.systest.jaxb.service.TestServiceImpl"
address="http://localhost:7081/service/TestEndpoint">
<jaxws:properties>
<entry key="jaxb.additionalContextClasses">
<bean
class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
<property name="classNames">
<list>
<value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</value>
</list>
</property>
</bean>
</entry>
</jaxws:properties>
</jaxws:endpoint>
2.1.1 can be downloaded from:
http://people.apache.org/~dkulp/stage_cxf/2.1.1/
It will hopefully be released tomorrow.
Dan
> Another thing that came up, yet illogical, is: Could it be, that the
> Elements, which are not unmarshalled simply don't match my generated
> classes? But that really defies logic, the testclient AND the wsdl
> were
> supplied together..
>
>
> dkulp wrote:
>>
>>
>> This is much easier with 2.1, so stick with that.......
>>
>> As you surmised, by default, the runtime only knows about the types
>> that are references in the generated code from the wsdl. One
>> solution is to add imports in the wsdl to import the other schemas
>> and
>> regenerate.
>>
>> The other option is to tell CXF about the other types that you want
>> it
>> to accept. The JAXB @XmlSeeAlso annotation is the easiest way to do
>> that. If you generate objects from your other schemas with xjc, it
>> probably generated a ObjectFactory class. Just add:
>> @XmlSeeAlso({com.foo.blah.ObjectFactory.class})
>> to you code to have jaxb pick that up.
>>
>> There are ways of doing it via configuration and properties and such,
>> but the XmlSeeAlso is probably the easiest, at least to get started
>> to
>> make sure it will work for you.
>>
>> Dan
>>
>>
>>
>>
>> On Jun 18, 2008, at 9:58 AM, MathisMohr wrote:
>>
>>>
>>> My Problem is:
>>>
>>> I am to create a webservice. I'm currently using CXF 2.1, but that
>>> doesnt
>>> seem to be the point, I also tried 2.0.6 and 2.0.7. with no
>>> different
>>> outcome.
>>> I have the WSDL and some XSD files defining the main request and
>>> response
>>> messages. Thing is, the WSDL only defines 2 elements, and then
>>> refers to a
>>> xsd:any element, so it would accept every data that follows. There
>>> is no
>>> clear connection to the XSDs. I can generate Java Code out of them
>>> though.
>>> Now when I use Jetty to start the webservice on my machine I see
>>> that it is
>>> working. I can send messages to the webservice, but CXF only seems
>>> to
>>> unmarshall the elements which are defined in the wsdl, everything
>>> else is
>>> being summed up in an instance of ElementNSImpl (from xerces).
>>> Thanks to
>>> debugging my webservice I found out that this Object actually has
>>> all my
>>> information in it, in some kind of DOM-Tree, it's just not being
>>> unmarshalled. As far as I see it, it seems that JaxB either doesnt
>>> recognize
>>> the generated files of the xsd's (because there is no connection
>>> between the
>>> wsdl and the xsds) or JaxB doesnt accept them. Either way, I have no
>>> solution. Can someone help me?
>>>
>>> wsdl-snippet:
>>>
>>> <s:element name="GetVehicleOwnerHolderByChassisAndDate">
>>> <s:complexType>
>>> <s:sequence>
>>> <s:element minOccurs="0" maxOccurs="1"
>>> name="VehOwnerHolderByChassisAndDate">
>>> <s:complexType mixed="true">
>>> <sequence>
>>> <s:any />
>>> </s:sequence>
>>> </s:complexType>
>>> </s:element>
>>> </s:sequence>
>>> </s:complexType>
>>> </s:element>
>>>
>>> Xsd-snippet:
>>>
>>> <xs:element name="VehOwnerHolderByChassisAndDate"
>>> type="VehOwnerHolderByChassisAndDateType"/>
>>>
>>> <xs:complexType name="VehOwnerHolderByChassisAndDateType">
>>> <xs:sequence>
>>> <xs:element name="Header" type="HeaderType"/>
>>> <xs:element name="Body">
>>> <xs:complexType>
>>> <xs:sequence>
>>> <xs:element name="Request">
>>> <xs:complexType>
>>> <xs:sequence>
>>> <xs:element name="VehCountryReq"
>>> type="xs:string" nillable="false"/>
>>> <xs:element
>>> name="VehIdentificationNumberReq" type="xs:string"/>
>>> <xs:element
>>> name="ReferenceDateTimeReq"
>>> type="xs:dateTime" minOccurs="0"/>
>>> </xs:sequence>
>>> </xs:complexType>
>>> </xs:element>
>>> </xs:sequence>
>>> </xs:complexType>
>>> </xs:element>
>>> </xs:sequence>
>>> </xs:complexType>
>>>
>>> Generated-code:
>>>
>>> @XmlAccessorType(XmlAccessType.FIELD)
>>> @XmlType(name = "", propOrder = {
>>> "vehOwnerHolderByChassisAndDate"
>>> })
>>> @XmlRootElement(name = "GetVehicleOwnerHolderByChassisAndDate")
>>> public class GetVehicleOwnerHolderByChassisAndDate {
>>>
>>> @XmlElement(name = "VehOwnerHolderByChassisAndDate")
>>> protected
>>> GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
>>> vehOwnerHolderByChassisAndDate;
>>>
>>>
>>> public
>>> GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
>>> getVehOwnerHolderByChassisAndDate() {
>>> return vehOwnerHolderByChassisAndDate;
>>> }
>>>
>>>
>>> public void
>>> setVehOwnerHolderByChassisAndDate
>>> (GetVehicleOwnerHolderByChassisAndDate
>>> .VehOwnerHolderByChassisAndDate
>>> value) {
>>> this.vehOwnerHolderByChassisAndDate = value;
>>> }
>>>
>>>
>>> */
>>> @XmlAccessorType(XmlAccessType.FIELD)
>>> @XmlType(name = "", propOrder = {
>>> "content"
>>> })
>>> public static class VehOwnerHolderByChassisAndDate {
>>>
>>> @XmlMixed
>>> @XmlAnyElement(lax = true)
>>> protected List content;
>>>
>>>
>>> public List getContent() {
>>> if (content == null) {
>>> content = new ArrayList();
>>> }
>>> return this.content;
>>> }
>>> --
>>> View this message in context:
>>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17983289.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>
>> ---
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17998010.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: CXF, trouble to find Classes to unmarshal to
Posted by MathisMohr <ma...@aol.com>.
Ok I tried 2 things, both with no luck:
1.) I inlcuded the xsd-files into the wsdl, so that everything in generated
in one move. It works, all the classes are being generated in one package
(ie com.foo.generated.wsdl). Yet still, my test refuses to unmarshall the
"inner" elements.
2.) Without this inclusion, I added the ObjectFactory of the seperatly
generated xsd-classes (ie com.foo.generated.xsd) to my PortType. But in this
case, it doesnt work as well. Yet this may be my fault, is my placement of
the annotation (at the implementation of the serviceinterface) correct?
Another thing that came up, yet illogical, is: Could it be, that the
Elements, which are not unmarshalled simply don't match my generated
classes? But that really defies logic, the testclient AND the wsdl were
supplied together..
dkulp wrote:
>
>
> This is much easier with 2.1, so stick with that.......
>
> As you surmised, by default, the runtime only knows about the types
> that are references in the generated code from the wsdl. One
> solution is to add imports in the wsdl to import the other schemas and
> regenerate.
>
> The other option is to tell CXF about the other types that you want it
> to accept. The JAXB @XmlSeeAlso annotation is the easiest way to do
> that. If you generate objects from your other schemas with xjc, it
> probably generated a ObjectFactory class. Just add:
> @XmlSeeAlso({com.foo.blah.ObjectFactory.class})
> to you code to have jaxb pick that up.
>
> There are ways of doing it via configuration and properties and such,
> but the XmlSeeAlso is probably the easiest, at least to get started to
> make sure it will work for you.
>
> Dan
>
>
>
>
> On Jun 18, 2008, at 9:58 AM, MathisMohr wrote:
>
>>
>> My Problem is:
>>
>> I am to create a webservice. I'm currently using CXF 2.1, but that
>> doesnt
>> seem to be the point, I also tried 2.0.6 and 2.0.7. with no different
>> outcome.
>> I have the WSDL and some XSD files defining the main request and
>> response
>> messages. Thing is, the WSDL only defines 2 elements, and then
>> refers to a
>> xsd:any element, so it would accept every data that follows. There
>> is no
>> clear connection to the XSDs. I can generate Java Code out of them
>> though.
>> Now when I use Jetty to start the webservice on my machine I see
>> that it is
>> working. I can send messages to the webservice, but CXF only seems to
>> unmarshall the elements which are defined in the wsdl, everything
>> else is
>> being summed up in an instance of ElementNSImpl (from xerces).
>> Thanks to
>> debugging my webservice I found out that this Object actually has
>> all my
>> information in it, in some kind of DOM-Tree, it's just not being
>> unmarshalled. As far as I see it, it seems that JaxB either doesnt
>> recognize
>> the generated files of the xsd's (because there is no connection
>> between the
>> wsdl and the xsds) or JaxB doesnt accept them. Either way, I have no
>> solution. Can someone help me?
>>
>> wsdl-snippet:
>>
>> <s:element name="GetVehicleOwnerHolderByChassisAndDate">
>> <s:complexType>
>> <s:sequence>
>> <s:element minOccurs="0" maxOccurs="1"
>> name="VehOwnerHolderByChassisAndDate">
>> <s:complexType mixed="true">
>> <sequence>
>> <s:any />
>> </s:sequence>
>> </s:complexType>
>> </s:element>
>> </s:sequence>
>> </s:complexType>
>> </s:element>
>>
>> Xsd-snippet:
>>
>> <xs:element name="VehOwnerHolderByChassisAndDate"
>> type="VehOwnerHolderByChassisAndDateType"/>
>>
>> <xs:complexType name="VehOwnerHolderByChassisAndDateType">
>> <xs:sequence>
>> <xs:element name="Header" type="HeaderType"/>
>> <xs:element name="Body">
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element name="Request">
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element name="VehCountryReq"
>> type="xs:string" nillable="false"/>
>> <xs:element
>> name="VehIdentificationNumberReq" type="xs:string"/>
>> <xs:element name="ReferenceDateTimeReq"
>> type="xs:dateTime" minOccurs="0"/>
>> </xs:sequence>
>> </xs:complexType>
>> </xs:element>
>> </xs:sequence>
>> </xs:complexType>
>> </xs:element>
>> </xs:sequence>
>> </xs:complexType>
>>
>> Generated-code:
>>
>> @XmlAccessorType(XmlAccessType.FIELD)
>> @XmlType(name = "", propOrder = {
>> "vehOwnerHolderByChassisAndDate"
>> })
>> @XmlRootElement(name = "GetVehicleOwnerHolderByChassisAndDate")
>> public class GetVehicleOwnerHolderByChassisAndDate {
>>
>> @XmlElement(name = "VehOwnerHolderByChassisAndDate")
>> protected
>> GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
>> vehOwnerHolderByChassisAndDate;
>>
>>
>> public
>> GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
>> getVehOwnerHolderByChassisAndDate() {
>> return vehOwnerHolderByChassisAndDate;
>> }
>>
>>
>> public void
>> setVehOwnerHolderByChassisAndDate
>> (GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
>> value) {
>> this.vehOwnerHolderByChassisAndDate = value;
>> }
>>
>>
>> */
>> @XmlAccessorType(XmlAccessType.FIELD)
>> @XmlType(name = "", propOrder = {
>> "content"
>> })
>> public static class VehOwnerHolderByChassisAndDate {
>>
>> @XmlMixed
>> @XmlAnyElement(lax = true)
>> protected List content;
>>
>>
>> public List getContent() {
>> if (content == null) {
>> content = new ArrayList();
>> }
>> return this.content;
>> }
>> --
>> View this message in context:
>> http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17983289.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17998010.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF, trouble to find Classes to unmarshal to
Posted by Daniel Kulp <dk...@apache.org>.
This is much easier with 2.1, so stick with that.......
As you surmised, by default, the runtime only knows about the types
that are references in the generated code from the wsdl. One
solution is to add imports in the wsdl to import the other schemas and
regenerate.
The other option is to tell CXF about the other types that you want it
to accept. The JAXB @XmlSeeAlso annotation is the easiest way to do
that. If you generate objects from your other schemas with xjc, it
probably generated a ObjectFactory class. Just add:
@XmlSeeAlso({com.foo.blah.ObjectFactory.class})
to you code to have jaxb pick that up.
There are ways of doing it via configuration and properties and such,
but the XmlSeeAlso is probably the easiest, at least to get started to
make sure it will work for you.
Dan
On Jun 18, 2008, at 9:58 AM, MathisMohr wrote:
>
> My Problem is:
>
> I am to create a webservice. I'm currently using CXF 2.1, but that
> doesnt
> seem to be the point, I also tried 2.0.6 and 2.0.7. with no different
> outcome.
> I have the WSDL and some XSD files defining the main request and
> response
> messages. Thing is, the WSDL only defines 2 elements, and then
> refers to a
> xsd:any element, so it would accept every data that follows. There
> is no
> clear connection to the XSDs. I can generate Java Code out of them
> though.
> Now when I use Jetty to start the webservice on my machine I see
> that it is
> working. I can send messages to the webservice, but CXF only seems to
> unmarshall the elements which are defined in the wsdl, everything
> else is
> being summed up in an instance of ElementNSImpl (from xerces).
> Thanks to
> debugging my webservice I found out that this Object actually has
> all my
> information in it, in some kind of DOM-Tree, it's just not being
> unmarshalled. As far as I see it, it seems that JaxB either doesnt
> recognize
> the generated files of the xsd's (because there is no connection
> between the
> wsdl and the xsds) or JaxB doesnt accept them. Either way, I have no
> solution. Can someone help me?
>
> wsdl-snippet:
>
> <s:element name="GetVehicleOwnerHolderByChassisAndDate">
> <s:complexType>
> <s:sequence>
> <s:element minOccurs="0" maxOccurs="1"
> name="VehOwnerHolderByChassisAndDate">
> <s:complexType mixed="true">
> <sequence>
> <s:any />
> </s:sequence>
> </s:complexType>
> </s:element>
> </s:sequence>
> </s:complexType>
> </s:element>
>
> Xsd-snippet:
>
> <xs:element name="VehOwnerHolderByChassisAndDate"
> type="VehOwnerHolderByChassisAndDateType"/>
>
> <xs:complexType name="VehOwnerHolderByChassisAndDateType">
> <xs:sequence>
> <xs:element name="Header" type="HeaderType"/>
> <xs:element name="Body">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="Request">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="VehCountryReq"
> type="xs:string" nillable="false"/>
> <xs:element
> name="VehIdentificationNumberReq" type="xs:string"/>
> <xs:element name="ReferenceDateTimeReq"
> type="xs:dateTime" minOccurs="0"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
>
> Generated-code:
>
> @XmlAccessorType(XmlAccessType.FIELD)
> @XmlType(name = "", propOrder = {
> "vehOwnerHolderByChassisAndDate"
> })
> @XmlRootElement(name = "GetVehicleOwnerHolderByChassisAndDate")
> public class GetVehicleOwnerHolderByChassisAndDate {
>
> @XmlElement(name = "VehOwnerHolderByChassisAndDate")
> protected
> GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
> vehOwnerHolderByChassisAndDate;
>
>
> public
> GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
> getVehOwnerHolderByChassisAndDate() {
> return vehOwnerHolderByChassisAndDate;
> }
>
>
> public void
> setVehOwnerHolderByChassisAndDate
> (GetVehicleOwnerHolderByChassisAndDate.VehOwnerHolderByChassisAndDate
> value) {
> this.vehOwnerHolderByChassisAndDate = value;
> }
>
>
> */
> @XmlAccessorType(XmlAccessType.FIELD)
> @XmlType(name = "", propOrder = {
> "content"
> })
> public static class VehOwnerHolderByChassisAndDate {
>
> @XmlMixed
> @XmlAnyElement(lax = true)
> protected List content;
>
>
> public List getContent() {
> if (content == null) {
> content = new ArrayList();
> }
> return this.content;
> }
> --
> View this message in context: http://www.nabble.com/CXF%2C-trouble-to-find-Classes-to-unmarshal-to-tp17983289p17983289.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog