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


Just wanted to reference this somewhat older discussion which goes into the effects of making a REST resource a CDI bean:

Kind regards,
Arjan Tijms

On Tue, 23 Jan 2024 at 19:02, Santiago Pericasgeertsen via rest-dev <rest-dev@xxxxxxxxxxx> wrote:

On Jan 23, 2024, at 10:23 AM, James Perkins <jperkins@xxxxxxxxxx> wrote:

 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

 I didn’t check this, but seems correct. And any type for which a ContextResolver<T> is defined (aka producer). 
If so, I don't really understand why CDI won't work here.

 We currently run with and without CDI, in particular, resources and providers don’t need to be CDI beans (and there’s no need for any beans.xml file). Assuming CDI is always available is sort of a big change and maintaining backward compatibility may be an issue (e.g., final classes may be problematic with Weld). Ignoring that for a moment, injection into fields/properties and constructors (this would require the class to be a CDI bean also) should be possible. 

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.

 Hmmm, maybe. In general, this all sounds like a big change for dot release. Perhaps it is time to prototype something to learn more about these challenges? 
— Santiago

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

Back to the top