Hi David, Read, David wrote: > Werner, > > I truly appreciate the difficulty of debugging something you cannot > touch. And so do I, in terms of the time you spend to make this readable and understandable.
> 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. That's what I though might happen .. :-(. Looks like you are about to confirm this. But that makes me wonder how any ws framework is successfully using Castor (or any other data binding tool, that is) internally. > 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). Which might be a valid work-around for you .. ;-). > 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. As already mentioned, I know need somthing *substantial* to work with, as I'd liek to be able to find a more geenral solution (as dropping an attribute somehow does not seem to be a valid option to me). Can you make something available to us ? > > Thank you for your time in helping me work through this issue. You are welcome. > > 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. > > > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > 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
