Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rest-dev] [External] : Start version 3.2

On Tue, Jan 23, 2024 at 5:51 AM Santiago Pericasgeertsen via rest-dev <rest-dev@xxxxxxxxxxx> wrote:

Reviewing the responses I see the following responses from Jakarta REST Committers:
  • 8 :  +1 votes (including me)
  • 1 :  +0 votes
So, unless any committers wish to change their votes, I think we should formally get started.


Also,  there have been a couple changes in the formal Jakarta EE11 plan that affect us (

  • The release review date for Wave 5 (which currently includes Jakarta REST) has been moved from 2024-02-29 to 2024-03-29.   This will likely still be aggressive, but maybe not impossible?

 Definitely better.

  • The min. Java version supported for EE11 has been moved to Java 17  ("Each Wave 1 - 5 component spec has an impl that passes its TCK on Java SE 17 and an impl that passes its TCK on Java SE 21. These need not be the same impl.) . So the Jakarta REST 3.2 TCK will need to support both Java 17 and Java 21.

Santiago,  you had stated previously that your time to work on this will be limited.  Assuming we go ahead with this I am willing to help out as needed.


What needs to be done (please add to this list if I’ve missed something):

  • Create a version 3.2 release plan.  Should be similar to the current 4.0.0 release plan ( adding info needed for CDI deprecation and possibly removing Jakarta Concurrency integration.
  • Create a release-3.2 branch.   Copy the release-4.0 branch and removing changes that removed @Context,  or possibly copy master and add PRs for any changes that need to be moved forward. 
  • Create a version 3.2 epic (similar to
  • Create a M1 version of the APIs and Spec as soon as possible, publishing to Maven Central as all other specs for EE11 have already done.

This is a lot to do and still a short time to do it.   So there are 3 discussion points that I see (maybe more):
  1. Do you feel this is worth pursuing for EE-11 given the time-line?
  2. Are you in a position to contribute to this?  At a minimum dedicate time to review PRs, contribute to discussions, etc..
  3. Do you feel that this 3.2 version, with a deprecated @Context injection, should be pursued for EE-12 if EE-11 is not possible? Or, in that case, should we just go with Jakarta REST-4.0 with @Conext removed rather than pushing a 3.2 version in EE-12?

 IMO, we need to iron out the technical problems that result from deprecation of @Context first. As we know, deprecation requires an alternative, and in this case providing an alternative may not be straightforward. Does it make sense to work on a release plan, branch etc without a sound technical solution to the problem?

Do I understand correctly that the following types are the only types allowed to be injected with @Context?

  • jakarta.servlet.ServletConfig
  • jakarta.servlet.ServletContext
  • jakarta.servlet.http.HttpServletRequest
  • jakarta.servlet.http.HttpServletResponse
If so, I don't really understand why CDI won't work here. I do understand how this could be an issue in SeBootstrap, unless we require a CDI container, and the client. However, in a Jakarta EE Container I see no reason why we can't just use @Inject. I realize for method parameters it's a bit different, but with CDI Method Invokers,, we should be able to handle that.

Is there another case I'm missing here?

— Santiago

rest-dev mailing list
To unsubscribe from this list, visit

James R. Perkins
JBoss by Red Hat

Back to the top