You are on the right path, but realistically you'll need to spend more
time on checking in the debugger what is happening.
Consider extending org.apache.cxf.staxutils.DepthXMLStreamReader
instead, and may be you can simplify things by blocking this attribute,
otherwise you may also need to overwrite the methods dealing with
NamespaceContext.
Also overwrite DepthXMLStreamReader.getReader() and return 'this';
Not sure, may be we can enhance InTransformReader to be able to block
attributes too,
Hope this helps
Sergey
Hi Dan,
Thank you for your reply. I have created a 'MediatorInInterceptor' extending
'AbstractPhaseInterceptor<SoapMessage>'. Following is the class definition.
public class MediatorInInterceptor extends
AbstractPhaseInterceptor<SoapMessage>{
public MediatorInInterceptor() {
super(Phase.POST_STREAM);
addAfter(StaxInInterceptor.class.getName());
}
public void handleMessage(SoapMessage message) throws Fault {
try {
XMLStreamReader xr = message.getContent(XMLStreamReader.class);
ShaymStreamReaderDelegate ss = new
ShaymStreamReaderDelegate(xr);
message.setContent(XMLStreamReader.class, ss);
} catch (Throwable e) {
}
}
}
The 'ShaymStreamReaderDelegate' is a class that extends 'StreamReaderDelegate'.
Following is the class definition.
public class ShaymStreamReaderDelegate extends StreamReaderDelegate {
public ShaymStreamReaderDelegate(XMLStreamReader reader){
super(reader);
}
@Override
public String getNamespaceURI(String prefix) {
if(prefix.equalsIgnoreCase("xsd")){
return "http://www.w3.org/2001/XMLSchema/";;
}
return super.getNamespaceURI(prefix);
}
}
I have added the 'MediatorInInterceptor' in the jaxws in interceptors
collection.
But when I run this I am getting the same exception. Also beak point places
inside 'getNamespaceURI' did not hit.
Thanks and regards,
Shyam S
On 22-Jul-2011, at 2:01 AM, Daniel Kulp [via CXF] wrote:
You could TRY writing a CXF interceptor that would live after the
StaxInInterceptor that would grab the XmlStreamReader, wrapper it with a
StreamReaderDelegate that overrides the various namespace lookup methods (like
getNamespaceURI(String prefix)) and set that back into the message. That
may allow you to "pretend" those prefixes are there.
Dan
On Monday, July 18, 2011 1:00:37 AM Shyamranny wrote:
Hi,
I have upgraded my web service and now the new webservice uses CXF. When I
send my old soap message to the new CXF webservice, i am getting the
following response.
'Unmarshalling Error: prefix xsd is not bound to a namespace'.
In my soap request, I have the following element.
'<A700129Naam xsi:type="xsd:string">Shyam</A700129Naam>' Here I use the
prefix 'xsd' and if I add this prefix in the xmlns, this soap will go well.
But our client will not change there soap request. They need to send the old
soap request.
How can I solve this issue? Can I add namespace and prefix in the spring
configuration file? I have tried a lot like XMLFilterImpl,
AbstractInDatabindingInterceptor, NamespacePrefixMapper etc. But not worked.
Thanks and regards,
Shyam S
--
View this message in context:
http://cxf.547215.n5.nabble.com/Unmarshalling-Error-prefix-xsd-is-not-bound
-to-a-namespace-tp4598539p4598539.html Sent from the cxf-user mailing list
archive at Nabble.com.
--
Daniel Kulp
[hidden email]
http://dankulp.com/blog
Talend - http://www.talend.com
If you reply to this email, your message will be added to the discussion below:
http://cxf.547215.n5.nabble.com/Unmarshalling-Error-prefix-xsd-is-not-bound-to-a-namespace-tp4598539p4620871.html
To unsubscribe from Unmarshalling Error: prefix xsd is not bound to a
namespace, click here.
--
View this message in context:
http://cxf.547215.n5.nabble.com/Unmarshalling-Error-prefix-xsd-is-not-bound-to-a-namespace-tp4598539p4621888.html
Sent from the cxf-user mailing list archive at Nabble.com.
