mkarg commented on issue #52: JOHNZON-281 JAX-RS Provider MUST throw NoContentException URL: https://github.com/apache/johnzon/pull/52#issuecomment-536227824 With my latest commit ontop I have replaced the explicit zero-length detection by simply catching `NothingToRead`. As announced, I added a warning to the JavaDocs that this will only work with Johnzon JSON-P -- which I assume is 100% of the use cases of this MBR. Regarding your ideas about JAX-RS I have a different view. As a long-time member of the JAX-RS team (I had been an external advisor to JSR 311, expert group member of JSR 339 and JSR 370; now committer to Jakarta REST and publisher of JAX-RS 2.1.1 through 2.1.5) I need to tell you that this part of the JAX-RS spec actually makes *pretty much* sense. `NoContentException` can be catched by a `ReaderInterceptor`, so *the application programmer* can detect this special case and e. g. replace that exception by an entity of *his* choice, *before* the JAX-RS engine chimes in and turns the result into a `400 Bad Request`. There *are* existing applications where processing empty input streams *does* make sense, so this feature is *needed*. That "synthetic" empty entity will be propagated *to resouce methods* for regular processing of the request. This works independently of the used MBR, MIME type, and entity class. If you simply throw some MBR- or MIME-type-specific exception, the application programmer has no chance to do exactly that, as it will get propagated directly to the exception mapper, leading to 400 always -- without *any* chance for the application programmer to override this behavior. We *deliberately* introduced this interception possibility for this special case in JAX-RS 2.1. If you are unlucky with our decisions or spec, please open an issue with [our tracker on Github](https://github.com/eclipse-ee4j/jaxrs-api/issues). We are happy to explain our features, and why we invented them. :-)
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
