Hi Clint, I might have gotten something wrong here, but I believe that the code "consuming" the web service (client), might be correct, but have problems converting the response XML to a proper java-bean.
And that the flawed part is the web-service, not appending the xsi:type to the abstract element in the *response*. The object that gets passed *to* the web-service is just the primary key of the object in the data storage, I'm interested in information on. I'm I confused here ? G -----Original Message----- From: Dovholuk, Clint [mailto:[EMAIL PROTECTED] Sent: 4. oktober 2005 15:16 To: [email protected] Subject: RE: Serialization of abstract classes hmmm, I think I can say "definitely" that the problem with the deserialization is because the xsi:type is NOT being appended to the GetMODefinition element.... I think you just need to focus on WHY the consuming code isn't generating the proper xml. I'd like to see the code that you're using to create the object that gets passed to the web service... I.e, are you instantiating the full object or are you just writing 'test code' to see if it's 'working'... A tool I use all the time to test my web services (built in .net, thus good for testing some interop issues) is web service studio... it's freeware and found at: http://www.gotdotnet.com/team/tools/web_svc/default.aspx try hitting the webservice with that and see if it's axis deserializing or the client creation... also see if you get the "right" xml too... just some thoughts... clint -----Original Message----- From: glenn bech [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 04, 2005 8:55 AM To: [email protected] Subject: RE: Serialization of abstract classes Hey Clint, First of all, thank you for taking the time to reply. It is Very interesting to learn that that the "xsi:type" attribute is required on the abstract element in the response xml. From what you are saying, the problem might be that axis does not append this to my Base element. As you can see from my response (using tcpmon), the "GetMODefinition" (base element) has no such attribute. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> <soapenv:Body> <GetResponse xmlns="ns"> <MOId/> <MOAttributes> <GetMODefinition> <ns1:companyName xmlns:ns1="ns1</ns1:companyName> <ns2:serviceProviderId xmlns:ns2="ns2</ns2:serviceProviderId> <ns3:companyId xmlns:ns3="ns3</ns3:companyId> </GetMODefinition> </MOAttributes> </GetResponse> </soapenv:Body> </soapenv:Envelope> I'm using a JAX-RPC approach, Document/Literal style for consuming the web service. I.E my code looks like this; URL wsdlURL = "http://localhost:888/etc/etc/etc"; ServiceFactory serviceFactory = ServiceFactory.newInstance(); Service service = serviceFactory.createService(wsdlURL, qServiceName) ProvisioningStub stub = new ProvisioningStub(new URL("http://localhost:8888/axis/services/Provisioning";), service) ; Object result = stub.get(new Get(...,... ) ); The Schema is a bit complex, and I'm not allowed to change it. It utilizes both abstract types and substitution groups. However, I've done some experimentation, and Axis displays the same behavior when I modify the schema, to only use a "pure" abstract approach, factoring out the substitution groups from the equation. This is the schema for the response of a very generic "Get" request to the system. <xs:element name="GetResponse"> <xs:complexType> <xs:sequence> <xs:element name="MOId" type="AnyMOIdType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="MOAttributes" type="GetResponseMOAttributesType" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> The "GetResponseMOAttributesType" (MO means "Managed object") As you can see, a "Head" element, for a substitution group. Never mind this, it doesn't affect anything.... <xs:complexType name="GetResponseMOAttributesType"> <xs:sequence> <xs:element ref="GetMODefinition"/> </xs:sequence> </xs:complexType> It's the GetMODefinition that is declared abstract.... <xs:element name="GetMODefinition" type="AbstractGetAttributeType" abstract="true"/> <xs:complexType name="AbstractGetAttributeType" abstract="true"/> Any suggestions or light-sheding would be warmly welcome !! Best regards, Glenn Richard Bech Seniorkonsulent Mob: 99356459 Tel: 40003325 Lysaker torg 2, 1366 Lysaker http://www.webstep.no Bergen - Oslo - Stavanger -----Original Message----- From: Dovholuk, Clint [mailto:[EMAIL PROTECTED] Sent: 4. oktober 2005 14:18 To: [email protected] Subject: RE: Serialization of abstract classes glenn, the "problem" isn't actually a problem... if one uses an abstract type in one's schema, when creating a valid xml document one must ALWAYS use the "base type" as the element and also must provide the type that this element will be validated against by using the xsi:type attribute on that element. can you post the wsdl, actual schema, or a snippet of it which has the abstract types you can't serialize? how are you passing the message to axis? are you consuming the web service with "something" or are you editing the xml by hand and passing that? I've never encountered a problem with abstract serialization... remember though that if you pass in a abstract type, axis won't be able to instantiate it because it's abstract. I'd like to see the wsdl / schema and know how you're consuming the service, that'd help... cheers -----Original Message----- From: glenn bech [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 04, 2005 8:05 AM To: [email protected] Subject: RE: Serialization of abstract classes Well, I've removed substitution groups from the equation and the exception is still thrown during deserialization of my response. The exception looks like this ; org.xml.sax.SAXException: Invalid element in com.someschema.schemas.application1_0._2004._01._22.AbstractGetAttribute Type - companyName at org.apache.axis.encoding.ser.BeanDeserializer.onStartChild(BeanDeseriali zer. java:258) at org.apache.axis.encoding.DeserializationContext.startElement(Deserializa tion Context.java:1035) at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java: 165) at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.j ava: 1141) at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:236) at org.apache.axis.message.RPCElement.getParams(RPCElement.java:384) at org.apache.axis.client.Call.invoke(Call.java:2448) at org.apache.axis.client.Call.invoke(Call.java:2347) at org.apache.axis.client.Call.invoke(Call.java:1804) at com.someschema.schemas.application1_0._2004._01._22.ProvisioningStub.get (Pro visioningStub.java:636) at TestProvisioning.main(TestProvisioning.java:26) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:78) The Response looks like this ; <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> <soapenv:Body> <GetResponse xmlns="http://schemas.mycompany.com/application1.0/2004/01/22/";> <MOId/> <MOAttributes> <GetMODefinition> <ns1:companyName xmlns:ns1="http://www.my-ohter-company.com/schemas/vpbx1.0/";>1</ns1:comp anyN ame> <ns2:serviceProviderId xmlns:ns2="http://www.my-ohter-company.com/schemas/vpbx1.0/";>2</ns2:serv iceP roviderId> <ns3:companyId xmlns:ns3="http://www.my-ohter-company.com/schemas/vpbx1.0/";>3</ns3:comp anyI d> </GetMODefinition> </MOAttributes> </GetResponse> </soapenv:Body> The question is really why the serializer is naming the XML element "GetMODefinition", and not using the name of the concrete schema type "GetEmployeeAttributes". I suspect this is why the deserializer is having trouble. If I understand things correctly ; Right now, it's not possible to predict, from the response, which concrete bean class that is to be instantiated, and populated with data! So... If anyone can shed some light on what the problem is with my *Serilizer*, I'd be very pleased! :-) Best regards, Glenn Richard Bech Seniorkonsulent Mob: 99356459 Tel: 40003325 Lysaker torg 2, 1366 Lysaker http://www.webstep.no Bergen - Oslo - Stavanger -----Original Message----- From: Dovholuk, Clint [mailto:[EMAIL PROTECTED] Sent: 30. september 2005 20:41 To: [email protected] Subject: RE: Serialization of abstract classes glenn, I don't think the problem lies with the xsi:type attribute use instead of the 'concrete' tag use... I successfully serialize/deserialize derived types from .net to java routinely... the problem though might lie in axis deserializing a substitution group... I've never actually tried to use a substitution group and frankly, since you're using abstract types I don't see why you'd WANT to use a substitution group... from my perspective, everything a substitution group does is 'covered' by using derived types... I'd try to serialize/deserialize something simple first... something like: <xs:complexType name="AbstractTestObject" abstract="true"/> <xs:complexType name="DerivedType"> <xs:complexContent> <xs:extension base="AbstractTestObject"> <xs:sequence> <!-- etc. --> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> I'd guess that somehow the substitution group is coming into play... but that's just a guess... :) hth, cwd -----Original Message----- From: glenn bech [mailto:[EMAIL PROTECTED] Sent: Friday, September 30, 2005 11:02 AM To: [email protected] Subject: Serialization of abstract classes Hi, I have some issues with serialization/deserialization of concrete implementation of abstract schema types. I have a schema with a concrete and an abstract element, aproxemately like this; <xs:complexType name="AbstractGetAttributeType" abstract="true"/> <xs:element name="GetDefinition" type="AbstractGetAttributeType" abstract="true"/> <xs:complexType name="GetResponseAttributesType"> <xs:sequence> <xs:element ref="GetDefinition"/> </xs:sequence> </xs:complexType> <xs:element name="GetResponse"> <xs:complexType> <xs:sequence> <xs:element name="primaryKey" type="xs:strig"> <xs:element name="Values "type="GetResponseAttributesType"/> </xs:sequence> </xs:complexType> </xs:element> My Concreate implementation looks something like this ; <xs:element name="GetEmployee" substitutionGroup="GetDefinition"> <xs:complextype> <xs:complexContent> <xs:extension base="AbstractGetAttributeType"/> <xs:sequence name="firstname /> <xs:sequence name="lastname /> </xs:complexcontent> <xs:complextype> </xs:element> After compiling and building everythig, and writing a test client, a typical response from the service looks something like this ; <?xml version="1.0" encoding="utf-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> <soapenv:Body> <GetResponse xmlns="http://schemas.mycompany.com/application1.0/2004/01/22/";> <primarykey/> <values > <GetDefinition xsi:type="ns1:AbstractGetAttributeType" xmlns:ns1="http://schemas.mycompany.com/application1.0/2004/01/22/";> <firstname> me </firstname> <lastname> me </lastname> </GetDefinition> </ values > </GetResponse> </soapenv:Body> </soapenv:Envelope> As you can see, the tag enclosed in the <values> tag, is <GetDefinition> and not my concrete type <getEmployee> This causes problems in deserialization. Axis (BeanDeserializer) tries to populete the abstract generated class with values firstname and lastname.... All XML and schemas were modified and cut out of context to make a better example of it, and might be inaccurate... But, should prove my point. Any Ideas on this ? G -----Original Message----- From: karusala kiranbabu [mailto:[EMAIL PROTECTED] Sent: 30. september 2005 15:34 To: [email protected] Subject: class-cast exception while writing the client for the webservice which takes datahandler as input parameters. Hi, I have created one webservice and deployed that webservice jar file in AXIS/WEB-INF/lib/ directory. I have accessed the wdsl of the webservice by giving the url for the webservice.here there is no problem. After that, we have written the client and passing the datahandlers to the webservice . 1.It is not invoking the method of the webservice and it is giving the exception as mentioned below. HOW CAN WE RESOLVE THIS ISSUE? plz help me in this regard, it's very urgent for me. THE EXCEPTION COMING IS: C:\Documents and Settings\Administrator\Desktop\Downloads\webservice\newwebservice_client \cli ent>javac -d . XSLTClient.java C:\Documents and Settings\Administrator\Desktop\Downloads\webservice\newwebservice_client \cli ent>java xsltransform/XSLTClient sample.xml sample.xsl the inFileDataHandler [EMAIL PROTECTED] the xslFileDataHandler [EMAIL PROTECTED] AxisFault faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException faultSubcode: faultString: java.lang.ClassCastException faultActor: faultNode: faultDetail: {http://xml.apache.org/axis/}hostname:SGSC1 java.lang.ClassCastException at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.ja va:2 21) at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.jav a:12 8) at org.apache.axis.encoding.DeserializationContext.endElement(Deserializati onCo ntext.java:1087) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDis patc her.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno wn Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(Unknown Source) at org.apache.axis.encoding.DeserializationContext.parse(DeserializationCon text .java:227) at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696) at org.apache.axis.Message.getSOAPEnvelope(Message.java:424) at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstan dChe cker.java:62) at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206) at org.apache.axis.client.Call.invokeEngine(Call.java:2765) at org.apache.axis.client.Call.invoke(Call.java:2748) at org.apache.axis.client.Call.invoke(Call.java:2424) at org.apache.axis.client.Call.invoke(Call.java:2347) at org.apache.axis.client.Call.invoke(Call.java:1804) at xsltransform.XSLTClient.main(XSLTClient.java:72) C:\Documents and Settings\Administrator\Desktop\Downloads\webservice\newwebservice_client \cli ent> __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
BEGIN:VCARD VERSION:2.1 N:Bech;Glenn;Richard FN:[EMAIL PROTECTED] ORG:Webstep Consulting AS TITLE:Seniorkonsulent TEL;WORK;VOICE:99356459 TEL;CELL;VOICE:99356459 ADR;WORK:;;P.O. Box 66;;Lysaker;1324;Norway LABEL;WORK;ENCODING=QUOTED-PRINTABLE:P.O. Box 66=0D=0ALysaker 1324=0D=0ANorway EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20050923T071750Z END:VCARD
