I've got problem with character encoding of my http responses. I read many tips, tutorials etc., but I can't resolve my problem. We are using Spring MVC with Hibernate and ExtJS as view technology. All data are returns as JSON using #ResponseBody on controllers method. Example method:
#RequestMapping(method = RequestMethod.POST, value = "dispatcher")
#ResponseBody
public String dispatcherPost(HttpServletRequest req, HttpServletResponse resp, HttpSession session) {
return process(req, resp, session);
}
There is simple dispatching mechanism for dispatching url commands (not really important in this case). Process method is doing something with parameters and return JSON. This JSON contains for example data from database (PostgreSQL 9.1.4). Data in Postgres are stored in UTF-8 and are 'visible correctly' for example in pgAdmin. We can also see valid data (from database) while debuging in eclipse. It all looks like there is everything ok with getting data from the Postgres. Problem starts when we want to return them via #ResponseBody annotated method. Method 'process' returns valid string (I can see in debugging mode) with utf-8 characters but in web browser (chrome, firefox) there are '?' instead of polish characters which are stored in database. Looking into firebug I can see that response headers are partially valid: 'Content-type: text/html;charset=UTF-8'. I told 'partially', because I have this line of code in process method:
`resp.setContentType("application/json;charset=UTF-8");`
where resp is HttpServletResponse. I've tried adding springs bean post processor from this solution: http://stackoverflow.com/questions/3616359/who-sets-response-content-type-in-spring-mvc-responsebody/3617594#3617594 but it doesn't works. I've got also character encoding filter in web.xml
<!-- Force Char Encoding -->
<filter>
<filter-name>encodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>encodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
So basically the problem is with returning well encoded JSON from server. Any idea?
EDIT:
I paste code into proccess method:
System.err.println("TEST " + System.getProperty("file.encoding"));
System.err.println("TEST normal: " + response);
System.err.println("TEST cp1250: " + new String(response.getBytes(),"cp1250"));
System.err.println("TEST UTF-8: " + new String(response.getBytes(),"UTF-8"));
And result is something like this:
TEST Cp1250
TEST normal: {"users":[{"login":"userąęśćółżń"}]}
TEST cp1250: {"users":[{"login":"userąęśćółżń"}]}
TEST UTF-8: {"users":[{"login":"user?????"}]}
Thanks, Arek
Ok, it seems to be something weird with http://static.springsource.org/spring/docs/3.0.x/reference/remoting.html#rest-message-conversion and #ResponseBody annotation which is using springs http message converters. I don't have time for go into creating custom message converters, so solution for me is remove #ResponseBody annotation and use something like this:
#RequestMapping(method = RequestMethod.GET, value = "dispatcher")
public void dispatcherGet(HttpServletRequest req, HttpServletResponse resp, HttpSession session) {
String response = process(req, resp, session);
try {
resp.getWriter().write(response);
resp.getWriter().flush();
} catch (IOException e) {
e.printStackTrace();
}
}
Maybe this will helps someone. Thanks, Arek
Related
I'm working on a spring-boot (1.4.0-RELEASE) MVC Groovy app which will present an XML api. By default Spring seems to wire up Jackson which marshalls my response objects to JSON, however I want it to default to responding in XML without requiring any Accept header from clients, hence I configured the default content type as follows:
#Configuration
class SpringWebMvcConfig extends WebMvcConfigurerAdapter {
#Override
public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
configurer.defaultContentType(MediaType.APPLICATION_XML);
}
}
This works just fine, however when running our tests I discovered that calling /health now returns a 406 status code and no content (it previously returned a 200 and a JSON response).
Having reverted the above change I thought perhaps I could force each controller to explicitly set the response content type via the use of a ResponseEntity, in doing so I tried the following in my controller method:
#RequestMapping(value = "/blah",
method = RequestMethod.GET)
ResponseEntity<MyResponseObject> getProgrammeRestrictions(#PathVariable String coreNumber) {
// Generate response object (code snipped)...
new ResponseEntity<MyResponseObject>(myResponseObject,
new HttpHeaders(contentType: MediaType.APPLICATION_XML),
HttpStatus.OK)
}
However this doesn't seem to influence the response type, which still defaults to JSON.
In a nutshell it seems that setting a default non-json content type breaks the actuator healthcheck. Is there someway to force the healthcheck bits and bobs to disregard the default setting and always be generated in JSON?
Has anyone else experienced this? Grateful for any pointers as I'm a bit stuck here.
Many thanks,
Edd
You need to add jackson-dataformat-xml dependency:
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-xml</artifactId>
</dependency>
Then, make its XmlMapper available:
#Autowired
private MappingJackson2XmlHttpMessageConverter mappingJackson2XmlHttpMessageConverter;
#Bean
public ObjectMapper objectMapper(){
// this returns an XmlMapper, which is a subclass of ObjectMapper
return mappingJackson2XmlHttpMessageConverter.getObjectMapper();
}
It works when sending a request from the browser (http://localhost:8080/health), the returned result is in XML (chrome sends the header Accept: */*).
When sending the request programmatically, you still have to pass Accept: application/json in your header since the service expects this media type, but the returned result will be XML.
When we configure Spring AOP the JSON Results disappear for : AOPExression1
<aop:pointcut id="dmhMethodExecution"
expression="within(com.aditya.dmh..*)" />
So I added an exclusion for : AOPExpression1 as AOpExpression2
<aop:pointcut id="dmhMethodExecution"
expression="within(com.aditya.dmh..*)
and !within(com.aditya.dmh.controller..*)" />
in the ASPECTJ Expression
Still I donot see my JSON results from the controller which is a restful implementation.
package com.aditya.dmh.controller;
#Controller
public class EmployeeController {
private EmployeeServiceInterface employeeService;
#Autowired
public void setEmployeeService(EmployeeServiceInterface employeeService) {
this.employeeService = employeeService;
}
#RequestMapping("/employeeservices/1/allemployees.view")
public #ResponseBody Result<EmployeeModel> getEmployees(){
return employeeService.getEmployees(0, 10);
}
}
When I use log4j for the DEBUG messages I see the following:
15:37:04.214 [http-8090-1] DEBUG o.s.web.servlet.DispatcherServlet - Null ModelAndView returned to DispatcherServlet with name 'dmhServiceDispatcher': assuming HandlerAdapter completed request handling
15:37:04.214 [http-8090-1] DEBUG o.s.web.servlet.DispatcherServlet - Successfully completed request
When I remove the AOP the JSON results start to appear and I see that the additional Debug Message.
17:11:36.270 [http-8090-2] DEBUG o.s.w.s.m.m.a.RequestResponseBodyMethodProcessor - Written [com.aditya.Result#8a85268] as "application/json;charset=UTF-8" using [org.springframework.http.converter.json.MappingJackson2HttpMessageConverter#62ba2e48]
Looking at the Spring forums I understand that the Convertor is automatically configured when the
<mvc:annotation-driven/>
is used.
Is my problem of configuring AOP have anything to do with the RequestResponseBodymethodProcessor not being called.
Does this have anything to do with the proxies created around my controller when I use AOPExpression1. Why would an exclusion as in AOPExpression2 still have the problem.
Anyhelp would be appreciated
I belive that to intercept a request to a controller you should do it with MVC interceptors and not with aspects. What I did is to put into the applicationContext.xml this:
<mvc:interceptors>
<mvc:interceptor>
<mvc:mapping path="/employeeservices/1/allemployees.view"/>
<bean class="com.aditya.dmh.interceptor.ResultInterceptor" />
</mvc:interceptor>
</mvc:interceptors>
Now, the class ResultInterceptor is where you put the code you want to be done, for instance:
#Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
log.info("--- preHandle --- ");
return true;
}
At least this is the way I did it.
Hope it helps.
This is a bit of a speculation:
I think what is happening is a CGLIB based dynamic proxy is getting created for your controller (although you have excluded it explicitly in your new pointcut expression), if this happens then #RequestMapping annotations are not correctly detected(by `) and so the controller is not there to handle your REST request.
Can you try a few things:
Have an interface for the controller with the exact same methods that the controller handles, and put the #RequestMapping annotations there, this will handle cases where the dynamic proxy is created and should work as expected even if the dynamic proxy gets created..
Play around a little more with your pointcut expression to see why a proxy for you controller may be getting created.
THE SOLUTION FOR OUR PROBLEM IN THIS CONTEXT
We found out that the whole thing was with the Around Advice in AOP Configuration that we have had.
Before Fix
public void logAround(ProceedingJoinPoint joinPoint) throws Throwable {
long startTime = System.currentTimeMillis();
joinPoint.proceed();
long totalTime = System.currentTimeMillis() - startTime;
log.debug(buildLogMessage(new StringBuilder().append(METHOD_AROUND_ID)
.append("[").append(totalTime).append("] ").toString(),
joinPoint));
return returnValue;
}
After Fix
public Object logAround(ProceedingJoinPoint joinPoint) throws Throwable {
long startTime = System.currentTimeMillis();
Object returnValue = joinPoint.proceed();
long totalTime = System.currentTimeMillis() - startTime;
log.debug(buildLogMessage(new StringBuilder().append(METHOD_AROUND_ID)
.append("[").append(totalTime).append("] ").toString(),
joinPoint));
return returnValue;
}
the void effectively made sure that the Response Object sent by the logAround was not passed on back to the RequestResponseBodyMethodProcessor
Once we had it captured & returned the cglib proxies sent the response back to the processor & had the response sent back to the client.
I face this problem. I have a filter that sets the character encoding of the request according to the filter's config (for example, to UTF-8). This works with forms coded using the struts html:form tag. However, if I use the ordinary HTML form tag, the data are not encoded correctly.
This is the filter definition in the web.xml:
<filter>
<filter-name>Encoding Filter</filter-name>
<filter-class>EncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>Encoding Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Here's the filter :
public class EncodingFilter implements javax.servlet.Filter {
private String encoding;
public void init(FilterConfig filterConfig) throws ServletException {
this.encoding = filterConfig.getInitParameter("encoding");
}
public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException {
request.setCharacterEncoding(encoding);
filterChain.doFilter(request, response);
}
public void destroy() {
}
}
If you use a Struts tag <html:form> and omit the METHOD attribute it defaults to POST.
If you use a standard HTML <form> and omit the METHOD attribute it defaults to GET.
Tomcat will process your POST and GET parameters differently:
POST: your filter will be used. Note that you should really only set the request character encoding if it has not been specified by the client (your filter is always setting it to UTF-8). Tomcat comes with a filter SetCharacterEncodingFilter.java that does this.
GET: Tomcat will use ISO-8859-1 as the default character encoding. There are two ways to specify how GET parameters are interpreted:
Set the URIEncoding attribute on the element in server.xml to something specific (e.g. URIEncoding="UTF-8").
Set the useBodyEncodingForURI attribute on the element in server.xml to true. This will cause the Connector to use the request body's encoding for GET parameters.
This is all in: http://wiki.apache.org/tomcat/FAQ/CharacterEncoding
I am using Spring 3.0.6 and i have a single controller for uploading files to the server. I am using a script to upload using XmlHttpRequest for browsers that support it while the rest of the browsers submit a (hidden) multipart form. The problem however is that when a form is submitted it sends the following header:
Accept text/html, application/xhtml+xml, */*
I figure that due to this header the Controller which is marked with #ResponseBody replies with the response been converted to XML instead of JSON. Is there a way to get around this without hacking the form submit request?
You can force JSON using #RequestMapping(produces = "application/json"). I don't remember if this is available in 3.0 but it is available in 3.1 and 3.2 for sure.
As others noted, Jackson needs to be on your classpath.
Thank you! I was having exactly the same issue and your post resolved my problem.
On the UI I'm using JQuery with this file upload plugin:
https://github.com/blueimp/jQuery-File-Upload/wiki
Here's my completed method (minus the biz logic):
#RequestMapping(value = "/upload", method = RequestMethod.POST)
public void handleUpload( #RequestParam("fileToUpload") CommonsMultipartFile uploadFile, ServletResponse response){
List<UploadStatus> status = new ArrayList<UploadStatus>();
UploadStatus uploadStatus = new UploadStatus();
status.add(uploadStatus);
if(uploadFile == null || StringUtils.isBlank(uploadFile.getOriginalFilename())){
uploadStatus.setMessage(new Message(MessageType.important, "File name must be specified."));
}else{
uploadStatus.setName(uploadFile.getOriginalFilename());
uploadStatus.setSize(uploadFile.getSize());
}
ObjectMapper mapper = new ObjectMapper();
try {
JsonGenerator generator = mapper.getJsonFactory().createJsonGenerator(response.getOutputStream(), JsonEncoding.UTF8);
mapper.writeValue(generator, status);
generator.flush();
} catch (Exception e) {
e.printStackTrace();
}
}
If you want a JSON response, you can easily accomplish that by having the Jackson JARs on your classpath. Spring will auto-magically pick up on them being there and will convert your #ResponseBody to JSON.
I made it work by getting rid off #ResponseBody and instead doing manually the conversion (always using Jackson), i.e.
Response r = new Response();
ObjectMapper mapper = new ObjectMapper();
JsonGenerator generator = mapper.getJsonFactory().createJsonGenerator(response.getOutputStream(), JsonEncoding.UTF8);
try {
File f = uploadService.getAjaxUploadedFile(request);
r.setData(f.getName());
} catch (Exception e) {
logger.info(e.getMessage());
r = new Response(new ResponseError(e.getMessage(), ""));
}
mapper.writeValue(generator, r);
generator.flush();
Does anyone know another way? I tried setting up a ContentNegotiatingViewResolver but i don't want to break any other controllers by assigning all hmtl to json. Also, i tried to do it for this method only via a custom viewresolver but when i setup a jsonview and use BeanNameViewResolver although the response is correctly converted to JSON the server throws an
HttpRequestMethodNotSupportedException: exception, with Request method 'POST' not supported and set status to 404.
I have jersey implementation of web service. The response per requirements must be gzip-ed.
Client side contains following bootstrap code to switch gzip on:
Client retval = Client.create();
retval.addFilter(
new com.sun.jersey.api.client.filter.GZIPContentEncodingFilter());
For Tomcat web.xml gzip is configured as follow
<servlet>
<display-name>JAX-RS REST Servlet</display-name>
<servlet-name>JAX-RS REST Servlet</servlet-name>
<servlet-class>
com.sun.jersey.spi.container.servlet.ServletContainer
</servlet-class>
<load-on-startup>1</load-on-startup>
<init-param>
<param-name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name>
<param-value>com.sun.jersey.api.container.filter.GZIPContentEncodingFilter</param-value>
</init-param>
<init-param>
<param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>
<param-value>com.sun.jersey.api.container.filter.GZIPContentEncodingFilter</param-value>
</init-param>
And everything works fine!
But I need write unit test that invokes my service. I'm using JerseyTest as base and in practice way it was shown that grizzly is not correctly handles gzip without explicit declaration. I have found code snippet how to switch it on similar problem, but I have no idea how to combine it with JerseyTest.
Thank you in advance
Here is a sample test case if you're using the jersey test Framwork:
#Test
public void testGet(){
WebResource webResource = resource();
ClientResponse result = webResource
.path("pathToResource")
.header("Accept-Encoding", "gzip")
.head();
assertEquals(
"response header must contain gzip encoding",
"[gzip]",
result.getHeaders().get("Content-Encoding").toString());
}
AS the client API changed in the current Jersey versions, this is a sample test which works with Jersey 2.6:
public class WebServicesCompressionTest extends JerseyTest {
#Path("/")
public static class HelloResource {
#GET
public String getHello() {
return "Hello World!";
}
}
#Override
protected Application configure() {
enable(TestProperties.LOG_TRAFFIC);
return new ResourceConfig(
HelloResource.class,
EncodingFilter.class,
GZipEncoder.class,
DeflateEncoder.class
);
}
#Test
public void testGzip() {
Response response = target().request().acceptEncoding("gzip").get(Response.class);
assertThat(response.getStatus(), is(200));
assertThat(response.getHeaderString("Content-encoding"), is("gzip"));
}
}