Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rest-dev] Jakarta Rest 3.2?



On Fri, Jan 12, 2024 at 4:11 PM James Perkins via rest-dev <rest-dev@xxxxxxxxxxx> wrote:
I'm a +1 for this plan. I think having a real depreciation of @Context and the ContextResolver interface is really helpful for users. I don't think most users read the specification and I truly feel it will catch users by surprise that the types are no longer there. It also allows projects like MicroProfile to adopt the specification without breaking changes. I understand the specification noted this and there is in a note in the @Context JavaDoc, but there is nothing on the ContextResolver interface. Adding a @Deprecated(forRemoval = true) annotation on these types would be very helpful IMO.

I would be in favor of this proposal as well.

 
With this plan, I'd like to request a minimum Java level of Java 17. This would be consistent with all other specifications with the exception of Jakarta Concurrency (Java 21) and CDI (Java 11).
+1

Cheers

 

On Fri, Jan 12, 2024 at 5:54 AM Jim Krueger via rest-dev <rest-dev@xxxxxxxxxxx> wrote:

The purpose of this note is to gauge the interest within the Jakarta Rest community for a RESTful Web Services version 3.2.

 

The primary impetus for this proposed version would be to deliver a version where @Context injection is formally deprecated.   This would require an alternative implementation and all of the corresponding API and TCK changes/additions, but would not remove backward compatibility for current users.    The current plan for Jakarta Rest 4.0 introduces a breaking change by removing @Context injection .   While 4.0 should still focus on that and I’m aware that both the 3.1 specification and Javadoc for the Context class indicate that it will be removed in a “future release”, I’m wondering if it wouldn’t be a good idea to formally deprecate this first, allowing users to see the deprecation warnings and prepare.

 

In addition, at this point it would seem that the likelihood of Jakarta Rest-4.0’s inclusion in Jakarta EE11 is tenuous at best, so producing a more limited 3.2 Version, that still has value add, might be more of a realistic goal along with easing the eventual transition to tighter integration with CDI.

 

Thoughts?

_______________________________________________
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org


--
James R. Perkins
JBoss by Red Hat
_______________________________________________
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org


--

Alessio Soldano

Manager, Software Engineering 

Red Hat



Back to the top