All, Just to close the loop on this, the issue was classpath related. We ended up using the WebSphere classpath configuration option of "parent last" so that the JAR files deployed in the WAR are placed on the classpath first. Once this was done the application worked fine.
Regards, -Dave -----Original Message----- From: Werner Guttmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2008 4:29 PM To: [email protected] Subject: Re: [castor-user] [XML] Marshalling Behavior Change Between Tomcat/Windows and WebSphere/AIX Environments Read, David wrote: > Good day! > > I'm sending this out wondering whether anyone has seen similar > behavior and might have an idea how I might resolve the issue. > > I have a web application built using Spring and Castor. Spring > front-ends SOAP requests and then Castor does all the > marshalling/unmarshalling. I have a mapping file that defines the > XML-to-bean relationships. > > Here is a piece of the mapping file that defines an mapping for Agent > Phone data (call center rep registering with their soft phone). > > <!-- > Mapping for AgentPhoneRequest - Abstract Class holding common Phone > request data > Since this class is abstract, there is no <map-to> element. > --> > <class name="com.ba.servicegovernor.webservice.AgentPhoneRequest"> > <field name="agentPhoneExtension" > type="string" > required="false"> > <bind-xml name="phone:AgentPhoneExtension" node="element"/> > </field> > <field name="agentUserId" > type="string" > required="false"> > <bind-xml name="phone:AgentUserID" node="element"/> > </field> > </class> > > <!-- > Mapping for AgentRegister request - Agent Phone Register request data > --> > <class > name="com.ba.servicegovernor.webservice.AgentPhoneRegisterRequest" > extends="com.ba.servicegovernor.webservice.AgentPhoneRequest" > auto-complete="false"> > <map-to xml="AgentRegister" > ns-uri= > "urn:RE:SOAP:CGBACTI:Event" > ns-prefix="tns"/> > <field name="agentWorkstationIPAddress" > type="string" > required="false"> > <bind-xml name="phone:AgentWorkstationIPAddress" node="element"/> > </field> > </class> > > All works great on my local machine (Tomcat/Windows/JDK 1.4). Here is > the XML sent in the SOAP request: > > <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> > <tns:AgentRegister xmlns:tns="urn:RE:SOAP:CGBACTI:Event"> > <tns:AgentPhoneExtension>phoneExt</tns:AgentPhoneExtension> > <tns:AgentUserID>agentID</tns:AgentUserID> > > <tns:AgentWorkstationIPAddress>ipAddress</tns:AgentWorkstationIPAddress> > </tns:AgentRegister> > </soapenv:Body> > </soapenv:Envelope> > > > However, when I deploy on the server (WebSphere/AIX/JDK 1.4) the > resulting XML is: > > <soapenv:Envelope > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > <soapenv:Header/> > <soapenv:Body> > <tns:AgentRegister> > <tns:AgentPhoneExtension>phoneExt</tns:AgentPhoneExtension> > <tns:AgentUserID>agentID</tns:AgentUserID> > > <tns:AgentWorkstationIPAddress>ipAddress</tns:AgentWorkstationIPAddress> > </tns:AgentRegister> > </soapenv:Body> > </soapenv:Envelope> > > Notice that the namespace definition is not provided on the > AgentRegister element which causes a parser exception. Also, the > message now has an additional namespace definition for "soapenc" on > the envelope and adds the <Header> element, but those don't break anything. > > Has anyone seen different environments alter the generated XML? No, not really. What I have seen, though, especially when I used to work for one of the biggest investment banks a few years ago, is classpath configuration problems with both WebLogic and Websphere. Most of the time, I have seen one of the following two issues: a) There was already a different version of (in your case) Castor on the classpath, most of the time configured on either the system classpath of the server or a server-wide classpath. Frequently, that would prevent your Castor JAR (as shipped with either a WAR or EAR file) from being loaded. A tricky issue, indeed. b) Non-compliant configuration of your deployment units (again, either WAR or EAR). Products like Websphere allow e.g web app deployment where you can define custom classloader strategies, that do not comply with standard classloading semantics of web applications, and are used to 'tune' things. Apart from this, I cannot think of anything. > Any idea how to workaround this? Yes and no. Personally, I won't be able to replicate your environment, as no AIX, no Websphere, etc. here at home. But if you are willing to engage through professional services, I am more than willing to spend time with you. > > Appreciate any guidance you can offer. > > Regards, > > -Dave > > > > > > This e-mail and any files transmitted with it are for the sole use of > Blue Slate Solutions and the intended recipient(s) and may contain > confidential and privileged information. If you are not the intended > recipient, please contact the sender by reply e-mail and destroy all > copies of the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this > email or any action taken in reliance on this e-mail is strictly > prohibited and may be unlawful. > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email This e-mail and any files transmitted with it are for the sole use of Blue Slate Solutions and the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
