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 >>>>>>> [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-tp17983289p18085999.html Sent from the cxf-user mailing list archive at Nabble.com.
