Axis bean deserializer problem with custom bean class.

[ja...@accenture.com]

To the group,
 
I apologize in advance for the length of this email but please read
through and let me know if you can help.
I gave up on the WSDL2Java problem I had mentioned in
<http://marc.theaimsgroup.com/?l=axis-user&m=107527423219447&w=2>
http://marc.theaimsgroup.com/?l=axis-user&m=107527423219447&w=2 but now
have a new namespace issue regarding my WSDL and a client generated Soap
message.
 
I have a Web Service that I am trying to create that mirrors an existing
BEA Weblogic Server 6.1 SP4 Web Service. I was able to deploy the Web
Service to Axis/Tomcat using the exact same WSDL and Java classes from
WLS. The Web Service works correctly with the custom client app I built
using Axis APIs. I receive back the expected response.
 
The problem:
The existing client application generates a Soap message for the WLS Web
Service that is slightly different than the Soap message generated by
the Axis client. Same WSDLs, but different messages. The Axis client
application can send and receive to both Web Services with no problems.
The existing client application fails when submitting data to the Axis
Web Service. Both clients are submitting a custom Java class
(MeterEvent) that follows the JavaBean specification. I am using Axis'
built in Bean deserializer to handle this complex type.
 
Existing Client: Works with WLS, fails with Axis
AXIS Client: Works with WLS and Axis
 
Here is the difference between the Soap messages for each client. The
full Soap messages are below:
<arg0 s:type="MeterEvent"> -- Fails with AXIS, works with WLS
 
<arg0 s:type="m:MeterEvent"> -- Works with AXIS and WLS
<arg0: m:type="MeterEvent"> -- Works with AXIS and WLS
<arg0 (A or E or y):type="MeterEvent"> -- Works with AXIS and WLS
 
The error:
I get the following error with Axis' Bean deserializer when the <arg0
s:type="MeterEvent"> line is used in the Soap message.
<faultstring>org.xml.sax.SAXException: Deserializing parameter
&apos;arg0&apos;:  could not find deserializer for type
MeterEvent</faultstring>
 
The questions:
Can anyone tell me the difference between Weblogic's and AXIS' Web
Service that would cause this discrepency? Can I change my WSDL
(attached) to accept all of the above forms and avoid a bean
deserializer error? I am not an XML or Soap expert and am hoping their
is a simple explanation to fix this problem. Unfortunately, it is easier
for me to change the Web Service on AXIS than to change the existing
client application so I have to resort to looking for a workaround. Any
help is greatly appreciated.
 
Thanks,
 
--Jason
Jason Thompson
 
Existing Client App Soap message:
<?xml version="1.0" encoding="UTF-8"?>
<E:Envelope xmlns:E="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:A="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:s="http://www.w3.org/2001/XMLSchema-instance"
xmlns:y="http://www.w3.org/2001/XMLSchema" 
E:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <E:Body>
 <m:submitEvent xmlns:m="java:com.dsn.centralizedmeter.domain">
  <arg0 s:type="MeterEvent">
   <partyId s:type="y:int">1</partyId>
   ...
   <fulfillmentLocation s:type="y:string">11111111</fulfillmentLocation>
  </arg0>
 </m:submitEvent>
 </E:Body>
 </E:Envelope>
 
AXIS Client App Soap message:
<?xml version="1.0" encoding="UTF-8"?>
 <E:Envelope xmlns:E="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:A="http://schemas.xmlsoap.org/soap/encoding/" 
  xmlns:s="http://www.w3.org/2001/XMLSchema-instance"
xmlns:y="http://www.w3.org/2001/XMLSchema" 
  E:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <E:Body>
 <m:submitEvent xmlns:m="java:com.dsn.centralizedmeter.domain">
  <arg0 s:type="m:MeterEvent">
   <partyId s:type="y:int">1</partyId>
   ...
   <fulfillmentLocation s:type="y:string">11111111</fulfillmentLocation>
  </arg0>
 </m:submitEvent>
 </E:Body>
 </E:Envelope>

Jason Thompson
Accenture
Office: 973.644.7850
jason.e.thompson@accenture.com

 

 


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.  If you have received it in error, please notify the sender immediately and delete the original.  Any other use of the email by you is prohibited.