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
>>>>> [EMAIL PROTECTED]
>>>>> 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
>>> [EMAIL PROTECTED]
>>> 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
> [EMAIL PROTECTED]
> 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.
