search

jakartaee / rest

Jakarta RESTful Web Services
Other
361 stars 117 forks source link

NotImplementedException to go with Response.Status.NOT_IMPLEMENTED & friends #772

Open derekm opened 5 years ago

derekm commented 5 years ago

Provide equivalent exception types for the new v2.0 Response.Status fields.

mkarg commented 5 years ago

@derekm Feel free to provide a PR. :-)

jeyvison commented 5 years ago

Just so if anyone is thinking about work on this on, i'll send a PR about it shortly.

mkarg commented 3 years ago

There are open comments in PR #774 that have to be addressed before we can close this issue.

spericas commented 3 years ago

Does this issue still need to be targeted for 3.1?

derekm commented 3 years ago

@spericas -- I think not having exceptions for all statuses is an oversight. It is nice to cause specific status codes in responses simply by raising the corresponding exception. Having all users constantly re-invent the wheel by providing their own exceptions in such cases strikes me as somewhat malicious.

spericas commented 3 years ago

@derekm We need someone to submit a PR :)

derekm commented 3 years ago

@spericas -- It looks like @jeyvison's PR was rejected. To me it is all or nothing, and Jeyvison's PR looks like it went with "all," but some maintainers want user-programmers to constantly reinvent these wheels. Now it seems like a matter of lobbying for the rejected PR.

spericas commented 3 years ago

@derekm Not everyone agrees on the all or nothing approach; if a middle ground will not cut it, we might just as well move on ...

derekm commented 3 years ago

@spericas -- How do we know which ones are worth implementing or which exceptions won't be rejected if implemented? I was asking for exceptions for "NOT_IMPLEMENTED & friends." Just implement them one-by-one and see which of n PRs aren't rejected?

spericas commented 3 years ago

@derekm No, you submit the PR with the proposal and update it based on the feedback received and until you get the necessary approvals. If I recall correctly, last time the comments were never addressed. It's really not that complicated, and the way all PR's get accepted.

mkarg commented 3 years ago

@spericas -- I think not having exceptions for all statuses is an oversight. It is nice to cause specific status codes in responses simply by raising the corresponding exception. Having all users constantly re-invent the wheel by providing their own exceptions in such cases strikes me as somewhat malicious.

No this is not an oversight. JAX-RS is just a foundational API that provides the boilerplate for others to build third-party libraries. It is not a REST framework, it just contains the really essential return codes. Such a common library easily could provide lots of status codes and become something like Apache Commons.

derekm commented 3 years ago

@spericas -- Yes, I'm aware how PRs work. 😄 Which is why I'm asking question so I don't just shoot in the dark trying to bring this home, as I think it is very valuable (and very late).

The only unaddressed comment I can find across a mess of PRs is from @chkal, which paraphrases to "maybe don't implement RequestHeaderFieldsTooLargeException or RequestedRangeNotSatisfiableException". I can imagine many instances where an application might forward requests to other systems using header or range data, in which case these exceptions could be handy.

Only these two exceptions are at issue and need to be removed? Why even pare it down on just 2 exceptions?

@mkarg -- Interesting... I use JAX-RS directly without any additional libraries. I find it quite suitable to use standalone, minus some minor wheels I have to constantly re-invent or provide to myself via internal dependencies -- hence this issue. Probably I should get my private utility libraries on maven central or something (e.g., https://github.com/derekm/jaxrs-ext).

jeyvison commented 3 years ago

Hey Folks :) I'm sure i addressed everything that was supposed to be addressed at the time. For what i understand , it was closed bacause we didn't get a consensus on what to keep. If we know now it now i'm more than happy in changing my PR and resend it

spericas commented 3 years ago

@jeyvison Seems like there is some interest in your PR. If you re-submit, I'll take a closer look and provide a review. Let's give it another shot. Thanks.

mkarg commented 3 years ago

@mkarg -- Interesting... I use JAX-RS directly without any additional libraries. I find it quite suitable to use standalone, minus some minor wheels I have to constantly re-invent or provide to myself via internal dependencies -- hence this issue. Probably I should get my private utility libraries on maven central or something (e.g., https://github.com/derekm/jaxrs-ext).

Interesting! In fact, in my daily use of JAX-RS, I am using approx. 10 external feature libraries for things like caching, compression, benchmarking, and other stuff.