I have a SOAP client and I need to set the default namespace - which I am doing with a TransformOutInterceptor as such:
Map<String, String> outTransformMap = Collections.singletonMap("Test", "Test");
org.apache.cxf.interceptor.transform.TransformOutInterceptor transformOutInterceptor = new org.apache.cxf.interceptor.transform.TransformOutInterceptor();
transformOutInterceptor.setDefaultNamespace("http://test");
transformOutInterceptor.setOutTransformElements(outTransformMap);
ClientProxy.getClient(client).getEndpoint().getOutInterceptors().add(transformOutInterceptor);
This is working fine in terms of changing the default namespace, and the SOAP message is being successfully received and parsed by the server, however, by running the transformation it is removing all the SOAP attachments and changing the Content Type of the message from mime to text/xml.
Can anyone help? Is this a bug or am I missing something? I've tried changing the phases at which the interceptor is run, but with to avail.
Many thanks
Matt
Related
In Java, I need to add a SOAP header containing authentication data for a client-side SOAP request to a 3rd party web service that I have no control over. I have set up a SOAPHandler, and am monitoring the actual code sent to the server-side to see what is going on. The authentication is not working.
What I precisely need is:
<soap12:Header>
<AuthenticationHeader xmlns="http://abc.xyz.com/">
<UserName>uname</UserName>
<Password>pwd</Password>
</AuthenticationHeader>
</soap12:Header>
I can create the AuthenticationHeader element and add it with the SOAPHeader.addHeaderElement method without issue, but I can't get the username and password content added properly. What I can get from using the various commands to set the text for a SOAPElement (setValue, setTextContent, addTextNode), and then using SOAPHeaderElement.addChildElement is
<soap12:Header>
<AuthenticationHeader xmlns="http://abc.xyz.com/">
<UserName xmlns="">uname</UserName>
<Password xmlns="">pwd</Password>
</AuthenticationHeader>
</soap12:Header>
The server side can't cope with the extra xmlns="" that all the commands I have tried seem to add to the UserName and Password tag names.
If I try to construct a string and add that text directly to the AutheticationHeader element, the < and > characters are escaped. I've also tried CDATA tags...that prevents escaping of the < and > characters, but the server still doesn't like it.
I found a solution constructing a Document to hold the raw text (which prevents escaping the characters), and then adding that, but unfortunately, it seems that Document can only be added to the SOAP body, not the SOAP header.
Does anyone have any suggestions how to overcome this? The server people are programming in .NET, not Java, so they aren't able to help.
I am getting the proper response back from the server, with all off the correct SOAP output tags, but the error message contained in the tag is "Can't Authenticate".
Thanks!
Following code will generate the correct Authentication Header that you would like to generate.
SOAPHeader header = request.getSOAPHeader();
Document doc = header.getOwnerDocument();
Element el1 = doc.createElementNS("http://abc.xyz.com/","UserName");
el1.setTextContent("MyName");
Element el2 = doc.createElementNS("http://abc.xyz.com/","Password");
el2.setTextContent("pass******");
Element el0 = doc.createElementNS("http://abc.xyz.com/", "AuthenticationHeader");
el0.appendChild(el1);
el0.appendChild(el2);
header.appendChild(el0);
I have some Java code which sends out an email with code somewhat like the following: Actually i got Mimemessage from Httprequest param and in that mimemessage i'm going to append some content to existing body.
If Mimemessage is of Multipart content-type , i'm not facing any issue while sending message.
If the message is of text/plain and text/html content-type, the content-transfer encoding which i set didn't applied to body.
Based on this docs
Q: Even though JavaMail does all the encoding and decoding for me, I need to manually control the encoding for some body parts. A: In the rare case that you need to control the encoding, there are several ways to override JavaMail's default behavior. A simple approach is as follows. After creating the entire message, call msg.saveChanges() and then use something like mbp.setHeader("Content-Transfer-Encoding", "base64") to force base64 encoding for the given body part.
Another approach is to subclass MimeBodyPart and override the updateHeaders method so that it first calls super.updateHeaders() and then sets the Content-Transfer-Encoding header as above.
Applied above also. But it doesn't works for me.
InputStream ins = request.getInputStream();
MimeMessage msg = new MimeMessage(session,ins);
msg.setContent("some non-Ascii content","text/plain; charset="UTF-8"");
//Tried setheader before saveChanges() method, also doesn't work for me
//msg.setHeader("Content-Transfer-Encoding","base64");
msg.saveChanges();
//Now tried based on above docs after saveChanges method, also doesn't work
msg.setHeader("Content-Transfer-Encoding","base64");
please help to solve this.
You duplicated most of this question in your other post, and I answered part of it there.
You would probably be better off sending the content for the mail message in the http request, then creating a new message on the server based on that content, instead of trying to send a complete MIME message to the server that you then edit.
Is there a way to retrieve the full SOAP message to handle it (envelope and all) when using the javax.xml.soap.SOAPMessage class?
I am using JMX-WS and want to edit the outbound SOAP Message from the server, in order to append two characters to the message AFTER the end closing tag of the envelope, as the client legacy code is expecting it. So ideally I would like to be able to edit the full message as a String, is this possible?
You can do this with cxf :
http://www.mastertheboss.com/web-interfaces/337-apache-cxf-interceptors.html
Take a look at the LogInterceptor example
I'm trying to send an attachment to client from Axis2 web service. The problem is that the message context, which client receives from the service, does not contain any attachments, though the last one seems to add it.
Here is the brief code of both sides.
Service:
MessageContext inMC = MessageContext.getCurrentMessageContext();
OperationContext operationContext = inMC.getOperationContext();
MessageContext outMC = operationContext.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
DataHandler handler = new DataHandler (new FileDataSource("C://goods.xml"));
String attachID = outMC.addAttachment(handler);
OMElement idElem = factory.createOMElement("doc", ns);
idElem.addAttribute("href", "cid:" + attachID, ns);
Client (trying to receive attachment):
MessageContext mcResponse = operationClient.getMessageContext(WSDLConstants.MESSAGE_LABEL_IN_VALUE);
SOAPBody body = mcResponse.getEnvelope().getBody();
OMElement attachElem = body.getFirstChildWithName (new QName("doc"));
String attachID = attachElem.getAttributeValue (new QName("href"));
attachID = attachID.replaceFirst("cid:", "");
DataHandler dataHandler = mcResponse.getAttachment(attachID);
getAttachment() method returns null. In case of debugging the client application, IDE shows, that attachment map in input message context does not contain any elements (size=0). The OMElement object (idElem), which contains attachment id, is received and read by client normally (debug showed cid). The parameters enableSwA, cacheAttachments, attachmentDIR, sizeThreshold are set both in services.xml and programming part of client. What is wrong with the message context?
Thanks a lot for any suggestions.
Upd: TCPmon showed the following content.
Request to service:
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><getXMLFile xmlns="http://axis2.apache.org"><filename>goods.xml</filename></getXMLFile></soapenv:Body></soapenv:Envelope>
I guess it's ok :)
Response from service:
109
<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><doc href="cid:d06f3b36afdfcbd2e135ecfbcad05ee602661262b059ed38#apache.org"></doc></soapenv:Body></soapenv:Envelope>
0
I apologize for a bit simple questions, but where the attachment should be reflected? I guess, if the service send an attachment, the SOAP message contains binary data, isn't it?
I checked also for putting the attachment into message context on service side - it's OK, I can get it there back from context after adding.
you can use tcpmon[1] to trace the http message and isolate the problem.
Anyway the better method for handling attachments is to use MTOM. Which can be used with data binding frameworks like ADB[2], or with POJO as well.
thanks,
Amila.
[1] http://ws.apache.org/commons/tcpmon/
[2] http://amilachinthaka.blogspot.com/2009/01/using-mtom-with-axis2.html
The problem was solved. The trouble was on the service side. TCPmon showed there was no attachments in responce message. However, the same example service works fine. After checking and comparing every operation on my service, it came out that programming part is not the reason either. The only one was left - service settings. So, the reason is that settings fields in service.xml file on the service, which require boolean type, does not allow any additional symbols. My mistake:
Incorrect:
<parameter name="enableSwA">
true
</parameter>
Correct:
<parameter name="enableSwA">true</parameter>
I'm working on a RESTful web service in Java. I need a good way to send error messages to the client if something's wrong.
According to the Javadoc, HttpServletResponse.setStatus(int status, String message) is deprecated "due to ambiguous meaning of the message parameter."
Is there a preferred way to set the status message or "reason phrase" of the response? The sendError(int, String) method doesn't do it.
Edit: To clarify, I want to modify the HTTP status line, i.e. "HTTP/1.1 404 Not Found", not the body content. Specifically, I'd like to send responses like "HTTP/1.1 400 Missing customerNumber parameter".
Or I want to modify the HTTP status line to say something like 227 IM Used - in other words: an HTTP Status Description different from what the web-server would know to send.
I don't think any RESTful client would expect to look at the reason phrase to figure out what went wrong; most RESTful services I've seen/used will send the standard status info and an expanded message in the body of the response. sendError(int, String) is ideal for that situation.
If you're using Tomcat, see the setting org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER:
http://tomcat.apache.org/tomcat-5.5-doc/config/systemprops.html
If this is true custom HTTP status messages will be used within HTTP headers. Users must ensure that any such message is ISO-8859-1 encoded, particularly if user provided input is included in the message, to prevent a possible XSS vulnerability. If not specified the default value of false will be used.
See this page for some detail on the original vulnerability:
http://www.securityfocus.com/archive/1/archive/1/495021/100/0/threaded
After your clarification, I tried this in Tomcat. Executing
response.sendError(HttpServletResponse.SC_BAD_REQUEST, "message goes here");
returns
HTTP/1.1 400 message goes here
as the first line in the response.
There must be a problem with the servlet container you are using.
I'm not quite familiar with the 'best practices' around REST. But I know the concept is based on HTTP and how it is supposed to work out naturally. So how about using a mime type and simple text inside the body for an application error, like 'application/myapp-exception' and some 'Bla bla'? You can provide a client library for that.
I would not use HTTP response codes for application errors. Because I like to know what's failing: whether it is my application or my HTTP server.
(I hope, I'll see some best practice advices here, too.)
It's not really clear what you are trying to accomplish. My first thought was the sendError but you say that does not do what you want... have you looked at creating a set of "error responses", meaning specific xml or JSON content (or whatever you are using as a transfer language) that contains the error message or code and any other useful information?
I did something like that for Spring-mvc based RESTful services a while back and it worked well but you have to pretty much catch and handle every exception to keep the client from getting a generic 500 message or something. The Spring Exception Resolvers worked well for that.
Hope this helps... if not, maybe a little more clarity on what you are trying to accomplish. Sorry if I am being dense and missing something obvious.
I think the sendError should do it, but your application server may be failing... IBM WebSphere 3.5 failed on me a long time ago while Tomcat would propagate the message just fine; see JavaServer Pages (JSP) and JSTL - Error page: preserve header "HTTP/1.x 400 My message"? on the Sun forums.
Eventually I used the following workaround, but this is kind of JSP specific, and may in fact be old:
<%# page isErrorPage="true" %>
<%
// This attribute is NOT set when calling HttpResponse#setStatus and then
// explicitely incuding this error page using RequestDispatcher#include()
// So: only set by HttpResponse#sendError()
Integer origStatus =
(Integer)request.getAttribute("javax.servlet.error.status_code");
if(origStatus != null) {
String origMessage =
(String)request.getAttribute("javax.servlet.error.message");
if(origMessage != null) {
response.reset();
response.setContentType("text/html");
// deprecated, but works:
response.setStatus(origStatus.intValue(), origMessage);
// would yield recursive error:
// response.sendError(origStatus, origMessage);
}
}
%>
And if you happen to test with Internet Explorer: disable "Show friendly HTTP error messages". (When not disabling that, IE has some odd requirement of some minimum length of the HTML content which, if not met, would —or will— make IE show its own error message instead. See also the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\ErrorThresholds at Microsoft's Description of Hypertext Transport Protocol Error Messages.)
In Spring powered web application, running on Tomcat I use following bean:
import java.util.Map;
import java.util.Set;
import java.util.Map.Entry;
import org.springframework.beans.factory.InitializingBean;
public class SystemPropertiesInitializingBean implements InitializingBean {
private Map<String, String> systemProperties;
#Override
public void afterPropertiesSet() throws Exception {
if (null == systemProperties || systemProperties.isEmpty()) {
return;
}
final Set<Entry<String, String>> entrySet = systemProperties.entrySet();
for (final Entry<String, String> entry : entrySet) {
final String key = entry.getKey();
final String value = entry.getValue();
System.setProperty(key, value);
}
}
public void setSystemProperties(final Map<String, String> systemProperties) {
this.systemProperties = systemProperties;
}
}
And in applicationContext.xml:
<bean class="....SystemPropertiesInitializingBean">
<property name="systemProperties">
<map>
<entry key="org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER" value="true"/>
</map>
</property>
</bean>