Rob Spoor

Sheriff
+ Follow
since Oct 27, 2005
Rob likes ...
Chrome Eclipse IDE Java Windows
Forum Moderator
Rob Spoor currently moderates these forums:
Cows and Likes
Cows
Total received
87
In last 30 days
0
Total given
32
Likes
Total received
1365
Received in last 30 days
2
Total given
2222
Given in last 30 days
4
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Rob Spoor

I agree.

What process is creating this HTML file? Can you change the life cycle phase of that process? You can perhaps use process-classes or prepare-package.
1 day ago
Does mod_jk still exist? I thought that was an Apache 2.2 thing, and was replaced by mod_proxy_ajp.
5 days ago
You can also configure Apache to proxy to Tomcat, using mod_proxy_http or mod_proxy_ajp.
1 week ago

Alex Theedom wrote:The gender property is ignored when this JSON is deserialized to the following target class that does not has a gender field.


That actually depends on the JSON serialization library used. If I recall correctly, MOXy ignores unknown fields by default. Jackson doesn't though, it throws an exception (which leads to a 400 error) if there are unknown properties. You have to explicitly tell Jackson to allow it.
1 week ago
That's a Jackson specific annotation. Howerver, Markus, you're not going to find a generic way to do this. Jackson, Gson, MOXy, they all have their own ways of ignoring unknown properties.
1 week ago
I've read the official specification, which is probably similar, but I don't think it's the best source to start with. After you've familiarised yourself using some other books it's a good reference though.
1 week ago
The exact error output depends on your business needs, and how the front-end code can handle it. We tend to return a JSON object (with status 400, 500, etc) that includes some code and message, and possibly other useful information.
2 weeks ago
Creating a controller advice is quite simple:

You can add catch-all methods with @ExceptionHandler(Exception.class) or even @ExceptionHandler(Throwable.class), but then you have to ensure that each exception gets mapped correctly.
2 weeks ago

Tim Holloway wrote:If this method had been invented in the Java era, "no more data" would probably be an exception


I partly disagree. Yes, there should probably be an exception if a read is attempted when no more data is available (there is in fact class java.io.EOFException). However, there should also be a way of detecting EOF in the first place, otherwise you would have to use the EOFException as the "stop reading" signal. That could be done by adding a method eof() or something like that that can return when EOF is reached. This would then lead to this:

Some notes:
* It's now possible to declare the variables required for reading inside the method body. For performance reasons the byte[] should probably still be declared outside though.
* A single byte read can return a byte because there is no more need for 257 values (-1 plus 0-255).
* A multiple byte read still needs to return the number of bytes read, because eof() only tells you that the end of the stream hasn't been reached yet, but not how many are available. (Method available() still shouldn't be used, because this information may simply be unknown.)
There's also an upgrade to 1.5.10 (with Spring 4.3.14) if you don't want to use 2.0.0 yet.
2 weeks ago
Welcome to the Ranch!

I would immediately reject the first two examples, because you shouldn't return success statuses (200) for erroneous responses. A simple "success" or "failure" is the worst because it doesn't tell you what went wrong, only that something went wrong. The second one does something similar in some cases, returning null or a 0 status.

Personally I'd go for the third example. Just let the method throw the exception, and use a controller advice to catch this and map it to a proper response (or you can use the default if that's good enough for you). The fourth one just seems so cluttered. You have to do all of the exception handling in every single method.

One note about the third example: if your class is annotated with @RestController you get @ResponseBody for free, there is no need to keep repeating it. With @Controller you do need to add it where necessary.
2 weeks ago
The fully qualified class names include the package name, so it would be com.boticiel.servlets.Form_nom instead of just Form_nom.
3 weeks ago

Tim Holloway wrote:In PUT, the data is part of the URL.


No it's not, it's in the body just like with POST (or at least, it should be). POST and PUT are requests that can contain a request body, GET and DELETE aren't.
3 weeks ago