Oh, well, it's been a long time since I have seen a user reporting such a configuration 'switch'. This used to be common about 5 to six years ago, and I was hoping that by 2008 this is past us ... ;-).
Thanks for coming back to us and letting us know. Werner PS If only IBM could make up their mind and ship Websphere with a default setting that is Servlet/JSP spec compliant .... Read, David wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
