Werner, I truly appreciate the difficulty of debugging something you cannot touch.
In the short term here is what I have done. Not sure if it will help in figuring out where the problem resides, but I thought it might benefit anyone else who encounters a similar situation. I tracked the exception down to the UnmarshalHandler's processAttributeList() method (I know, tell you something you didn't know :) ). Specifically the problem is that the namespace of the attribute (SOAP-ENV:encodingstyle) is not found in the _namespaces instance. I added some logging to the Namespaces class and found that it is never given the namespaces from the SOAP envelope. My workaround was to change the code which throws an exception when the namespace isn't found for an attribute to just continue the loop, effectively dropping the attribute but allowing the response to be processed. It now allows me to retrieve the response message and is working fine (since I don't need that attribute anyway). I've attached some log output showing the namespaces behavior (logged creation of Namespaces instances, addition/deletion of namespace entries, and reporting attributes as it loops through the attribute collection). My guess is that when the SOAP:Envelope is encountered those namespace definitions should be added to a Namespaces instance that would become a parent namespace to the SOAP Body and ultimately the body content. Thank you for your time in helping me work through this issue. Regards, -Dave -----Original Message----- From: Werner Guttmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 4:57 AM To: [email protected] Subject: Re: [castor-user] [XML] SOAP Response Causes Namespace-related Exception David, remote-analysis in this case is almost impossible. Here's two things I can offer: a) You create a project that includes everything I need to replay your problem. I know this will not be easy to achieve, but without a complete environment, I won't be able to look at things. b) We engage as part of professional services, and I try to come to your place and we (again) engage, with the benefit that we 'd cut out any side-effects due to the remoteness. Regards Werner Read, David wrote: > Werner, > > I've been trying various options to see if I can workaround the issue, > but to no avail. > > A couple of things I've tried were: > > 1) Used castor properties to turn on/off namespace support, ignore > errors, and force use of the Xerxes SAX parser. > > 2) Swapped the StAX implementation between the reference > implementation > (BEA) and Woodstox. > > The exception is consistent throughout. > > Is there other logging information that would help in determining > where the issues lies? For instance I see in the log that the Apache > Axis classes show the namespace definitions being encountered, > including SOAP-ENV, while processing the envelope. They then show the > AgentRegisterResponse element being processed. Finally I see the > endPrefixMapping calls, popping the namespaces off the stack, > including the SOAP_ENV. So from that point of view it seems like > everything is fine. It is after that, when Castor is invoked, that > the exception is thrown. > > Here are the last few lines before the exception: > > 2008-07-01 17:39:29,078 [Thread-00000] (ProjectResourceBundle.java:72) > DEBUG org.apache.axis.i18n.ProjectResourceBundle - > org.apache.axis.i18n.resource::handleGetObject(setMsgForm) > 2008-07-01 17:39:29,078 [Thread-00000] (SOAPPart.java:374) DEBUG > org.apache.axis.SOAPPart - Setting current message form to: > FORM_SOAPENVELOPE (currentMessage is now > org.apache.axis.message.SOAPEnvelope) > 2008-07-01 17:39:29,078 [Thread-00000] (SOAPPart.java:724) DEBUG > org.apache.axis.SOAPPart - Exit: SOAPPart::getAsSOAPEnvelope > 2008-07-01 17:39:29,078 [Thread-00000] (Configuration.java:190) DEBUG > org.castor.core.util.Configuration - Configuration loaded from > classpath: /org/castor/core/castor.core.properties > 2008-07-01 17:39:29,093 [Thread-00000] (Configuration.java:190) DEBUG > org.castor.core.util.Configuration - Configuration loaded from > classpath: /org/castor/xml/castor.xml.properties > 2008-07-01 17:39:29,093 [Thread-00000] (Configuration.java:190) DEBUG > org.castor.core.util.Configuration - Configuration loaded from > classpath: /castor.properties > 2008-07-01 17:39:29,109 [Thread-00000] > (WorkflowServiceGateway.java:162) INFO > com.cahabagba.servicegovernor.webservice.WorkflowServiceGateway - > Undefined Error: Parsing error on Response, will accept as success (Class of Error: > org.springframework.oxm.castor.CastorUnmarshallingFailureException > Error > Message: Castor unmarshalling exception: The namespace associated with > the prefix 'SOAP-ENV' could not be resolved.; nested exception is > org.exolab.castor.xml.MarshalException: The namespace associated with > the prefix 'SOAP-ENV' could not be resolved.) > > Thank you, > > -Dave > > > -----Original Message----- > From: Werner Guttmann [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 12, 2008 1:57 PM > To: [email protected] > Subject: Re: [castor-user] [XML] SOAP Response Causes > Namespace-related Exception > > Hi David, > > Read, David wrote: >> Werner, >> >> I am using a mapping file. The classes were developed independently >> from the services. >> >> Is there a way to coerce Spring or Castor to parse using SAX instead >> of DOM? ... > Not sure. That's a question I would ask at the spring-ws mailing > lists, as they should know the answer. > >> I didn't make a conscious decision either way and dont' believe that >> it matters to me. > Well, it depends on the size of the payload, to be honest, and whether > you are deploying to a high load environment. In that case I would not > want to use DOM. > >> I can send the WS portion of my Spring configuration file and castor >> mappings if that would be helpful. > Hmm. Why not. Are you by any chance using Maven ? If so, can you push > a small (sic!) project to me (read > http://jira.codehaus.org/browse/CASTOR) > so that I can replay the problem at hand ? > >> Thank you, >> >> -Dave >> >> >> -----Original Message----- >> From: Werner Guttmann [mailto:[EMAIL PROTECTED] >> Sent: Thursday, June 12, 2008 5:54 AM >> To: [email protected] >> Subject: Re: [castor-user] [XML] SOAP Response Causes >> Namespace-related Exception >> >> Hi David, >> >> I guess I will need something to play around a bit in order to have a >> full understanding of what's going wrong. But I have got a few >> questions >> first: >> >> a) Are you using a mapping file ? Or >> b) Did you start with an XML schema and generate domain/descriptor >> classes from it ? >> >> Having said that, looking at the stack trace, you might be right with >> you initial assessment about Castor not knowing about the SOAP-ENV >> namespace (prefix) at unmarshalling time. >> >> One general observation as well: looking at some (fully qualified) >> class names in the (quite complete) stack trace, it looks like you >> are > >> using DOM (rather than SAX for (un-)marshalling. That would be an >> issue to me .... >> >> Regards >> Werner >> >> Read, David wrote: >>> Good day, >>> >>> I am successfully using Castor to marshall data to a SOAP endpoint. >>> The endpoint accepts the data, runs its processing and returns what >>> appears to be a valid response. However, Castor throws and >>> unmarshalling exception. >>> >>> I am on Java 1.4 using Castor 1.2, Spring WS 1.5.2, Spring Core >>> 2.5.4, and Axoim 1.2 6. >>> >>> I noticed that the last line before the exception is: >>> >>> 2008-06-11 19:14:54,437 [Thread-00000] (UnmarshalHandler.java:1434) >>> DEBUG org.exolab.castor.xml.UnmarshalHandler - #startElement: >>> ns:AgentRegisterResponse >>> >>> So it seems that something doesn't like the SOAP-ENV namespace being >>> used within the Body. >>> >>> Here is the response I am receiving: >>> >>> <SOAP-ENV:Envelope >>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"; >>> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"; >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; >>> xmlns:ns="urn:RuleEngine:SOAP:TI:Event"> >>> <SOAP-ENV:Body> >>> <ns:AgentRegisterResponse >>> SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";> >>> </ns:AgentRegisterResponse> >>> </SOAP-ENV:Body> >>> </SOAP-ENV:Envelope> >>> >>> And the stack trace: >>> >>> org.springframework.oxm.castor.CastorUnmarshallingFailureException: >>> Castor unmarshalling exception: The namespace associated with the >>> prefix 'SOAP-ENV' could not be resolved.; nested exception is >>> org.exolab.castor.xml.MarshalException: The namespace associated >>> with > >>> the prefix 'SOAP-ENV' could not be resolved. >>> at >>> org.springframework.oxm.castor.CastorUtils.convertXmlException(Casto >>> r >>> U >>> ti >>> ls.java:50) >>> at >>> org.springframework.oxm.castor.CastorMarshaller.convertCastorExcepti >>> o >>> n >>> (C >>> astorMarshaller.java:431) >>> at >>> org.springframework.oxm.castor.CastorMarshaller.unmarshalDomNode(Cas >>> t >>> o >>> rM >>> arshaller.java:335) >>> at >>> org.springframework.oxm.AbstractMarshaller.unmarshalDomSource(Abstra >>> c >>> t >>> Ma >>> rshaller.java:292) >>> at >>> > org.springframework.oxm.AbstractMarshaller.unmarshal(AbstractMarshaller. >>> java:122) >>> at >>> org.springframework.ws.support.MarshallingUtils.unmarshal(Marshallin >>> g >>> U >>> ti >>> ls.java:65) >>> at >>> org.springframework.ws.client.core.WebServiceTemplate$2.extractData( >>> W >>> e >>> bS >>> erviceTemplate.java:337) >>> at >>> org.springframework.ws.client.core.WebServiceTemplate.doSendAndRecei >>> v >>> e >>> (W >>> ebServiceTemplate.java:523) >>> at >>> org.springframework.ws.client.core.WebServiceTemplate.sendAndReceive >>> ( >>> W >>> eb >>> ServiceTemplate.java:465) >>> at >>> org.springframework.ws.client.core.WebServiceTemplate.marshalSendAnd >>> R >>> e >>> ce >>> ive(WebServiceTemplate.java:314) >>> at >>> org.springframework.ws.client.core.WebServiceTemplate.marshalSendAnd >>> R >>> e >>> ce >>> ive(WebServiceTemplate.java:308) >>> at >>> com.ba.servicegovernor.webservice.WorkflowServiceGateway.sendPhoneRe >>> q >>> u >>> es >>> t(WorkflowServiceGateway.java:130) >>> at >>> com.ba.servicegovernor.webservice.WorkflowServiceGateway.sendRequest >>> ( >>> W >>> or >>> kflowServiceGateway.java:63) >>> at >>> > com.ba.servicegovernor.handler.EventHandler.sendToWorkflow(EventHandler. >>> java:175) >>> at >>> > com.ba.servicegovernor.handler.EventHandler.processEvent(EventHandler. >>> ja >>> va:151) >>> at >>> com.ba.servicegovernor.handler.EventHandler.run(EventHandler.java:11 >>> 7 >>> ) >>> at >>> com.ba.servicegovernor.thread.ReusableThread.run(ReusableThread.java: >>> 1 >>> 60 >>> ) >>> Caused by: org.exolab.castor.xml.MarshalException: The namespace >>> associated with the prefix 'SOAP-ENV' could not be resolved. >>> at >>> org.exolab.castor.xml.Unmarshaller.convertSAXExceptionToMarshalExcep >>> t >>> i >>> on >>> (Unmarshaller.java:761) >>> at >>> org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:640) >>> at >>> org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:747) >>> at >>> org.springframework.oxm.castor.CastorMarshaller.unmarshalDomNode(Cas >>> t >>> o >>> rM >>> arshaller.java:332) >>> ... 14 more >>> Caused by: org.xml.sax.SAXException: The namespace associated with >>> the prefix 'SOAP-ENV' could not be resolved. >>> at >>> org.exolab.castor.xml.UnmarshalHandler.processAttributeList(Unmarsha >>> l >>> H >>> an >>> dler.java:3321) >>> at >>> org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler. >>> j >>> av >>> a:1471) >>> at >>> org.exolab.castor.xml.util.DOMEventProducer.process(DOMEventProducer. >>> j >>> av >>> a:246) >>> at >>> org.exolab.castor.xml.util.DOMEventProducer.process(DOMEventProducer. >>> j >>> av >>> a:183) >>> at >>> > org.exolab.castor.xml.util.DOMEventProducer.start(DOMEventProducer.java: >>> 111) >>> at >>> org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:637) >>> ... 16 more >>> >>> >>> I appreciate any guidance you can provide on where to look for a >>> root > >>> cause. >>> >>> Thank you, >>> >>> -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 > > > > > > > > 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 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.
SOAPEnvelopeNamespacesAndCastor.LogExcerpt.txt
Description: Binary data
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
