In my dropwizard resource, I'm using the built in Jackson JSON object mapping to bind my data.
public class WidgetServiceResource {
#POST
#Path("/widget")
#Produces(MediaType.APPLICATION_JSON)
public Response foo(ModelParameters c) {
return Response.ok(c.value).build();
}
What I noticed however, is when I POST a bad body, the JSON doesn't parse, and I'm served with a response that doesn't meet my company's communication standards. How can I customize the response?
You need to deregister all default exception mappers and then register your own to handle the exception you want:
For example, in your yaml, you need:
server:
registerDefaultExceptionMappers: false
rootPath: /api/*
requestLog:
appenders: []
applicationConnectors:
- type: http
port: 9085
logging:
level: INFO
Note: registerDefaultExceptionMappers: false will tell DW to not register any ExceptionMappers.
Then, you can implement them yourself. In my case, I will just do a catch-all handler:
public class MyExceptionMapper implements ExceptionMapper<Exception> {
#Override
public Response toResponse(Exception exception) {
return Response.status(400).entity("This makes no sense").build();
}
}
This reacts to any exception and responds with a 400 and a String.
Finally, registering in the main class:
environment.jersey().register(MyExceptionMapper.class);
And a test for proof:
artur#pandaadb:~/dev/eclipse/eclipse_jee$ curl -v "http://localhost:9085/api/viewTest"
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9085 (#0)
> GET /api/viewTest HTTP/1.1
> Host: localhost:9085
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Date: Wed, 12 Oct 2016 10:16:44 GMT
< Content-Type: text/html
< Content-Length: 19
<
* Connection #0 to host localhost left intact
This makes no sense
Hope that helps,
-- Artur
Related
The application return redirect (302) when i make a POST in base context path, and i get a error.
My application.properties
...
server.servlet.context-path=/api/v1/application
...
My controler
#RestController
public class RestService {
#PostMapping
#ResponseStatus(HttpStatus.CREATED)
public ResponseDTO myMethod(#RequestBody RequestDTO requestDTO) {
log.trace("m=myMethod");
return service.insert(requestDTO);
}
}
If I make POST in http://localhost:8080/api/v1/application
I get a Redirect 302 to http://localhost:8080/api/v1/application/ and if the client follow redirect the application return 405 (method not allowed)
Curl
C:\>curl -v -X POST http://localhost:8080/api/v1/customer
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
> POST /api/v1/customer HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 302
< Location: http://localhost:8080/api/v1/customer/
< Transfer-Encoding: chunked
< Date: Mon, 31 Aug 2020 23:34:07 GMT
<
* Connection #0 to host localhost left intact
I am building a basic Spring Boot app, using the built is resource handler.
registry.addResourceHandler("/**")
.addResourceLocations("classpath:/public/")
.setCachePeriod(60 * 60 * 24 * 365)
.resourceChain(true)
.addResolver(versionResourceResolver);
The file structure is as follows:
src
main
java
..
resources
public
js
app.js
Making a request to localhost:8080/js/app.js works as expected, returning the contents of the file with the correct MIME type.
However, making a request to the container directory also returns 200 OK and an empty response!
$ curl -v http://localhost:8080/js/
* Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
> GET /js/ HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.49.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 28 Nov 2016 21:13:26 GMT
< X-Application-Context: application
< Last-Modified: Mon, 28 Nov 2016 21:06:28 GMT
< Cache-Control: max-age=31536000
< Accept-Ranges: bytes
< Content-Type: application/octet-stream
< Content-Length: 0
<
* Connection #0 to host localhost left intact
How can I get this to return 404 Not Found instead? It's not a huge issue, but definitely not what I'd expected.
I've encountered the same issue as in this question, using Spring Boot 1.3.0 and not having my controllers annotated with #RestController, just #Path and #Service. As the OP in that question says,
this is, to me, anything but sensible
I also can't understand why would they have it redirect to /error. And it is very likely that I'm missing something, because I can only give back 404s or 200s to the client.
My problem is that his solution doesn't seem to work with 1.3.0, so I have the following request flow: let's say my code throws a NullPointerException. It'll be handled by one of my ExceptionMappers
#Provider
public class GeneralExceptionMapper implements ExceptionMapper<Throwable> {
private static final Logger LOGGER = LoggerFactory.getLogger(GeneralExceptionMapper.class);
#Override
public Response toResponse(Throwable exception) {
LOGGER.error(exception.getLocalizedMessage());
return Response.status(Response.Status.INTERNAL_SERVER_ERROR).build();
}
}
And my code returns a 500, but instead of sending it back to the client, it tries to redirect it to /error. If I don't have another resource for that, it'll send back a 404.
2015-12-16 18:33:21.268 INFO 9708 --- [nio-8080-exec-1] o.glassfish.jersey.filter.LoggingFilter : 1 * Server has received a request on thread http-nio-8080-exec-1
1 > GET http://localhost:8080/nullpointerexception
1 > accept: */*
1 > host: localhost:8080
1 > user-agent: curl/7.45.0
2015-12-16 18:33:29.492 INFO 9708 --- [nio-8080-exec-1] o.glassfish.jersey.filter.LoggingFilter : 1 * Server responded with a response on thread http-nio-8080-exec-1
1 < 500
2015-12-16 18:33:29.540 INFO 9708 --- [nio-8080-exec-1] o.glassfish.jersey.filter.LoggingFilter : 2 * Server has received a request on thread http-nio-8080-exec-1
2 > GET http://localhost:8080/error
2 > accept: */*
2 > host: localhost:8080
2 > user-agent: curl/7.45.0
2015-12-16 18:33:37.249 INFO 9708 --- [nio-8080-exec-1] o.glassfish.jersey.filter.LoggingFilter : 2 * Server responded with a response on thread http-nio-8080-exec-1
2 < 404
And client's side (curl):
$ curl -v http://localhost:8080/nullpointerexception
* STATE: INIT => CONNECT handle 0x6000572d0; line 1090 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* Trying ::1...
* STATE: CONNECT => WAITCONNECT handle 0x6000572d0; line 1143 (connection #0)
* Connected to localhost (::1) port 8080 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x6000572d0; line 1240 (connection #0)
* STATE: SENDPROTOCONNECT => DO handle 0x6000572d0; line 1258 (connection #0)
> GET /nullpointerexception HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.45.0
> Accept: */*
>
* STATE: DO => DO_DONE handle 0x6000572d0; line 1337 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x6000572d0; line 1464 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x6000572d0; line 1474 (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 404 Not Found
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Content-Length: 0
< Date: Wed, 16 Dec 2015 17:33:37 GMT
<
* STATE: PERFORM => DONE handle 0x6000572d0; line 1632 (connection #0)
* Curl_done
* Connection #0 to host localhost left intact
So it's always a 404. Unless I do have such an /error resource, then what? what am I supposed to return? All I have at that point is a GET request to /error. And I don't want those extra requests consuming resources and polluting my logs.
What am I missing? And if nothing, what should I do with my exception handling?
You can set the Jersey property ServerProperties.RESPONSE_SET_STATUS_OVER_SEND_ERROR to true.
Whenever response status is 4xx or 5xx it is possible to choose between sendError or setStatus on container specific Response implementation. E.g. on servlet container Jersey can call HttpServletResponse.setStatus(...) or HttpServletResponse.sendError(...).
Calling sendError(...) method usually resets entity, response headers and provide error page for specified status code (e.g. servlet error-page configuration). However if you want to post-process response (e.g. by servlet filter) the only way to do it is calling setStatus(...) on container Response object.
If property value is true the method Response.setStatus(...) is used over default Response.sendError(...).
Type of the property value is boolean. The default value is false.
You can set Jersey property simply by calling property(key, value) in your ResourceConfig subclass constructor.
In my pet project I have a simple jersey (v 2.13) resource that performs some crud operations, and the input is validated by hibernate-validator (v 5.0.1.Final).
The problem is that while the junit tests works as expected, when I deploy the webapp all the ExceptionMapper implementations are ignored.
Here some details:
#POST
#Consumes(MediaType.APPLICATION_JSON)
#Produces(MediaType.APPLICATION_JSON)
public JsonResult<User> addUser(#Valid Userbean user) {
//do stuff...
}
The validation is made by hibernate-validator.
the Userbean is annotate with:
#NotNull
private String password;
I've created an ExceptionMapper implementation:
#Provider
public class ValidationExceptionMapper implements ExceptionMapper<ValidationException> {
#Override
public Response toResponse(ValidationException e) {
return Response.status(422).build();
}
}
Leaving aside that on validation the proper status code should be 400, my problem is that while in my junit-test everything goes fine...
Userbean entity = new Userbean();
entity.setUsername(username);
Response response = target.path("users").request(MediaType.APPLICATION_JSON).post(Entity.json(entity));
int status = response.getStatus();
assertEquals(422 status);
...I cannot reproduce the same behaviour when I run it on tomcat (I've tried tomcat7 / tomcat 8 and also glassfish 4.1)
I always get a 400 status code instead of 422 and ValidationExceptionMapper is being skipped.
$ curl -v -X POST -H "Content-Type: application/json" --data "{\"username\":\"MrFoo\"}" http://localhost:8080/playground-webapp/jaxrs/jersey/users/
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
> POST /playground-webapp/jaxrs/jersey/users/ HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: localhost:8080
> Accept: */*
> Content-Type: application/json
> Content-Length: 20
>
* upload completely sent off: 20out of 20 bytes
< HTTP/1.1 400 Bad Request
< Server: Apache-Coyote/1.1
< Content-Type: text/html;charset=utf-8
< Content-Language: en
< Content-Length: 990
< Date: Sun, 28 Dec 2014 15:07:34 GMT
< Connection: close
<
* Closing connection #0
<html><head><title>Apache Tomcat/7.0.52 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 400 - Bad Request</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>Bad Request</u></p><p><b>description</b> <u>The request sent by the client was syntactically incorrect.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.52</h3></body></html>
The same call made on the test server works as expected:
curl -v -X POST -H "Content-Type: application/json" --data "{\"username\":\"MrFoo\"}" http://localhost:8080/users/
* About to connect() to localhost port 8080 (#0)
* Trying ::1... Connessione rifiutata
* Trying 127.0.0.1... connected
> POST /users/ HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: localhost:8080
> Accept: */*
> Content-Type: application/json
> Content-Length: 20
>
* upload completely sent off: 20out of 20 bytes
< HTTP/1.1 422
< Content-Type: application/json
< Date: Sun, 28 Dec 2014 15:05:35 GMT
< Content-Length: 94
<
* Connection #0 to host localhost left intact
the code of the server I use for junit is:
#Before
public void setUpClient() throws Exception {
ResourceConfig rc = new UserResourceConfig();
rc.property("contextConfig", appContext);
server = GrizzlyHttpServerFactory.createHttpServer(BASE_URI, rc);
server.start();
....
Thanks in advance for your help.
I am creating a basic service component that takes a URL as input at http inbound endpoint. Code snippet from the mule-config file is as follows:
<service name="follow">
<inbound>
<http:inbound-endpoint address="http://localhost:8765/follow/" synchronous="true"/>
</inbound>
<component class="org.mule.application.mytwitter.Follow" />
</service>
and the function that is called from the Java component class is:
public Object onCall(MuleEventContext eventContext) throws Exception {
MuleMessage msg = eventContext.getMessage();
String str = msg.getStringProperty("http.request", null);
msg.setPayload(str);
msg.setStringProperty("http.status","200");
msg.setStringProperty("Content-Type","text/html");
System.out.println("Reached here:" + str);
return msg;
}
I wish to receive an HTTP response(payload) by hitting the service through CURL as:
curl -vv "http://localhost:8765/follow/"
but I'm not receiving any payload:
> * About to connect() to localhost port 8765 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8765 (#0)
> GET /follow/ HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: localhost:8765
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/plain
< Date: Tue, 27 Dec 2011 03:14:00 IST
< Server: Mule Core/2.1.2
< Expires: Tue, 27 Dec 2011 03:14:00 IST
< Content-Length: 0
< Connection: close
<
* Closing connection #0
Am I missing something? The function in component class is being called and output is printed in console.
Are you intentionally using such an old version of mule? There's a much newer 3.2.1 version available. And I suggest you to move to flow-style messaging instead of services.
But to answer your problem, if you want to have the response payload to print out, then you should add a string transformer to you configuration. I don't remember exactly how to configure this to the service element, but if you use flow's then you can add a response block to the end of the flow.
<http:http-response-to-string-transformer />
I hope this helps.
never mind guys. i figured out something and it works fine now. there's an attribute called syncResponse for inbound-endpoint. Setting it to true makes it work synchronously. I think some problem to do with Mule 2.1.2 or maybe some system settings.