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(Castor >>> U >>> ti >>> ls.java:50) >>> at >>> org.springframework.oxm.castor.CastorMarshaller.convertCastorExceptio >>> n >>> (C >>> astorMarshaller.java:431) >>> at >>> org.springframework.oxm.castor.CastorMarshaller.unmarshalDomNode(Cast >>> o >>> rM >>> arshaller.java:335) >>> at >>> org.springframework.oxm.AbstractMarshaller.unmarshalDomSource(Abstrac >>> t >>> Ma >>> rshaller.java:292) >>> at >>> > org.springframework.oxm.AbstractMarshaller.unmarshal(AbstractMarshaller. >>> java:122) >>> at >>> org.springframework.ws.support.MarshallingUtils.unmarshal(Marshalling >>> 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.doSendAndReceiv >>> 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.marshalSendAndR >>> e >>> ce >>> ive(WebServiceTemplate.java:314) >>> at >>> org.springframework.ws.client.core.WebServiceTemplate.marshalSendAndR >>> e >>> ce >>> ive(WebServiceTemplate.java:308) >>> at >>> com.ba.servicegovernor.webservice.WorkflowServiceGateway.sendPhoneReq >>> 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:117 >>> ) >>> 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.convertSAXExceptionToMarshalExcept >>> 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(Cast >>> 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(Unmarshal >>> 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
