I have JAX-WS endpoint defined with #MTOM annotation and set threshold as below. So I expect any attachments less 5MB shall be sent inline as base64binary. But the soap response is always returned as MTOM for even small files.
Is this expected behavior? How can I enforce this flexibility otherwise ?
#HandlerChain(file="/handler-chain.xml")
#MTOM(threshold=5242880) // 5MB limit for inline soap attachements else MTOM
public class WSImpl {
I'm interested in this behavior. This is not the spec, but at least Metro implementation behaves like that (at least old version) in jboss 5. The Apache CXF does always sends as MTOM if enabled and does not care about threshold.
Related
I'm using OpenIAM as an SSO platform in my working environment.
When I try to integrate another web system that supports SAML 2.0,
I got an error saying that "the SAMLRequest parameter exceeds 2000 characters limitation"
OpenIAM support says that ESAPI has a 2,000 characters limitation in its validator and there's no way to extend it.
Is there any way to extend the limitation of HTTP request parameter length in ESAPI using .properties file or java command-line arguments so I can integrate my web applications?
This was a bug we fixed 5yrs ago ESAPI. If OpenIAM upgrades to >= 2.2.3.1 this becomes a configurable parameter in ESAPI.properties
Specifically MaxHeaderValueSize.
The default value is 4096 which is quite liberal for most applications. Prior to this the default size was 2000, and before that 100. I recommend reviewing the actual need for values this large.
We are in process of migraring from Jersey 1 to 2. As part of this, I am trying to move caching configurations in Jersey 1.
With Jersey 1, we were using ApacheHttpClient4 which internally was using a ApacheHttpClient4Handler built using CachingHttpClient.
ApacheHttpClient4Handler httpClientHandler = new ApacheHttpClient4Handler(cachingHttpClient, null, false);
javax.ws.rs.client.Client client = new ApacheHttpClient4(httpClientHandler, clientConfig);
But looks like ApacheHttpClient4Handler is not available in Jersey 2.
Question here is, is there an alternative to ApacheHttpClient4Handler available?
I know how caching works as a server (Setting response headers etc). My question here is executing the external cacheable REST requests which my Jersey Client can cache.
Long term goal is to move away with Jersey comletely and use something like RestTemplate. But for now I am trying for a short term solution.
Any help here will be much appreciated.
I am calling a SOAP web service as client.
Following is content-type value of response
Content-Type: text/xml
I requested customer to add UTF-8 to response as follow:
Content-Type: text/xml;charset=utf-8
But customer says that it can be from client side. Is this possible? Can I determine content type of server as client?
PS: I noticed that the cited RFC2376 is obsolete by RFC3023 (conservative enough) and then RFC7303 that I'm omitting to evaluate now in involved current use and content, so the relevance of the following might not be that definitive, I'm feeling to delete it.
You have everything formal in RFC2376 XML Media Types: Section 3.1 text/xml Registration
See also Section 6 Examples of that RFC, particularly Section 6.4 text/xml with Omitted Charset
The server side (your customer) is STRONGLY RECOMMENDED to use charset parameter that they are not currently using.
And if charter is omitted XML processors MUST use the default charset value of "us-ascii"
You are right asking the customer to specify charset, the "MUST" in the RFC is a strong requirement that limits also your adaptability from client side when they are not sending us-ascii.
Since REST doesn't have faults like SOAP does, what would I use in replace of a FaultException?
Since you use SOAP as an example, I'll use SOAP metaphors.
The fault code ("faultcode" in SOAP 1.1, "code" in SOAP 1.2) becomes your HTTP Status-Code. You're constrained a little bit by the HTTP standard for codes here: errors that happened because of something the client did should be in the 4xx range, while completely server-side errors should be in the 5xx range. The generic fallbacks here are 400 and 500, respectively, and you should use the numbers from the HTTP standard when (but only when) they make sense for the resource being requested and the error that occurred.
The fault string ("faultstring" in SOAP 1.1, "Reason" in SOAP 1.2) becomes your HTTP Reason-Phrase. This is text.
The details ("detail" in SOAP 1.1, "Detail" in SOAP 1.2) goes in the HTTP entity-body. As long as the format is one that the client will accept (and you return the proper Content-Type header for it), this can be in any format that makes sense for your application.
Are there any resources / libraries I should look into if trying to implement client and server side components for a SOAP web service in Java (defined in WSDL) but not wishing to use the WSDL/JAXB-based code generation for client and server stubs?
For the record, the reason I am trying to eschew wsimport for stub generation is that both wsimport and xjc fail to properly generate Java code for the schema files I have to use - which are numerous and rather complex - and despite using episodic compilation I still hit what may likely be bugs in JAXB code generation logic (e.g. see here and here) and overall I have the impression that this technology is not very solid, when it comes to complex schemas.
So, are there any resources or libraries I should look into to help be build SOAP services by writing and reading XML content directly on the HTTP connection? Currently I am just calling write on a java.net.URLConnection like:
URLConnection connection = url.openConnection();
connection.setDoOutput(true); // Triggers POST.
connection.setRequestProperty("Accept" , "text/xml, multipart/related");
connection.setRequestProperty("Content-Type" , "text/xml; charset=utf-8");
connection.setRequestProperty("Host" , url.getHost());
connection.setRequestProperty("Proxy-Connection", "keep-alive");
connection.setRequestProperty("Content-Length" , String.valueOf(postContent.length()));
OutputStream output = connection.getOutputStream();
output.write(postContent.getBytes("UTF-8"));
If you need something "low level" (but not as extreme as writing the messages as strings) have a look at SAAJ.
Reference implementation is here and you can find a starting tutorial in The Java EE 5 Tutorial.