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
> [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.
