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
  • From: Santiago Pericasgeertsen <santiago.pericasgeertsen@xxxxxxxxxx>
  • Date: Wed, 24 Jan 2024 15:31:09 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ezrsaj6dKhuEZzs7dTS6YEPsE6OBAdSPnxDKpy/LXII=; b=UvVHztyF3w0v9hbJzwgiUBe79lbQhHvzi0Xfat5z7YxmL/laeuD5rxe4GU75VnXMCEJfjXPmnGp8ZmqqtIN2TMwGFj8Mkzun61P5putIkG/7JG0Vlp1k9lbOWCVT1rBw+smSBLEgUa3dd/ZogwdmdCoYFRSuQeC2kDsp3vXk3Z4Kpy6KoN8ssCG5W6H/u9q8lMfLxDVZV6ypJqMwza9qAx7lzDVdbIT2rJW9Uksp8D/6laSwf57M6fAtWkqpIC8Z+01ZwfKW9lZaGb5jV0Ld+94jtX8NNi9nq8ks7hzzGymaKOX40uFiAlWPDlJGxpPGyt2Qr82E2AsHUld8hpoR4Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=ABcDciKqtqowy6KRVxsRdx125yevoKdTJvQCY9N/5sjMW0xM+KV5bBUAM8hw4KPdiDROV/efUpWXw2Ggtys49T0VN2wSx1j1Jg7UGKSr3QIEhuGejj3tnfCbNoWd7imCazw7MD5YPkJbHm3mKU7cAPIEgV7jkMv74Fyac21e76kusk95Vh3O12F9hcvwQKOP9TqfFMf8+tr0agKrAWBtmt0EJa7/RKjuU86JUJJWmvWudc4nwa5lLkDJAhaCtKqkrNagQLQN3iRmSb7SuAAJBiyNwJcgZ02AboN1Qsfx5fjmOiCQRiDVX/zFDfK1bBCXqfiHCA0L2OzAYHE4L58LDg==
  • Delivered-to: rest-dev@xxxxxxxxxxx
  • List-archive: <>
  • List-help: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • Thread-index: AQHaThA7rjBuXcXYzEKZGQULS4B3ObDnsHyAgAAgBgCAAUgFAA==
  • Thread-topic: [rest-dev] [External] : Start version 3.2

On Jan 23, 2024, at 2:56 PM, James Perkins <jperkins@xxxxxxxxxx> wrote:

On Tue, Jan 23, 2024 at 10:02 AM Santiago Pericasgeertsen <santiago.pericasgeertsen@xxxxxxxxxx> 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). 

This is where I'm wondering if I'm missing something TBH. I looked at the TCK and through the RESTEasy tests as well as read over the 3.1 specification. I don't see where you can inject a type that a ContextResolver resolves with @Context. All the examples I see inject the Providers and lookup the ContextResolver to resolve the context type. Am I missing something? I might very well be, which is why I'm asking :) FWIW I thought it would work too, but all my local testing shows the injected values to always be null.

 Right, I think you’re correct in your analysis, this is only done programmatically. So it boils down to having support to inject Providers. However, having a method called `getContextResolver` in Providers when @Context is deprecated may be a bit odd —but again backward compatibility is imperative here.

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? 

As of now using CDI to inject the known types listed above does work in RESTEasy for fields. We need to do some work to have it work on constructor and method injection though. I plan on working on this week or next week for sure.

 Roger, excellent.

— Santiago

Back to the top