Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rest-dev] [External] : Re: Jakarta Rest 3.2?
  • From: Santiago Pericasgeertsen <santiago.pericasgeertsen@xxxxxxxxxx>
  • Date: Wed, 17 Jan 2024 15:19:15 +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=Hf24xcb/Oix4YCZjTbWtcGBCswH09bEn7vF2+zXamNE=; b=dNldc+oQr4KxNwHH3fwwdAspOLpzoLmPV2ESSi4GHwbctbhpNj/At+OZ3MwgGcjCrON4+Hg5nmTrmcgWHbPdqhxPlafCb4+Fvt40+SvzChzDS3yqdnBlKnORrsPrqoWCTR3eD1KqTiXvYAt5zco1a3tSg2nqZnopb0kEqwqyqP/YwjAauya6wLSvR8i53wDsQxZ+HNsRlddHS2GjC/tyIhl4QbjLI/jh+iOyuqG40e7UoOPPKansH4tpG8mYd8BUdnfXjPBP0hY9HdhWvYWi80mhfnTD2tT9lx5gUxgkVLhOc/CTo40UOaGLJshsRNeXchVtekCadjRe81CoFIZkhQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=HI0OAoujT8OJ03ZmTfPMdEx+DAKDdbXKdYtDbMrLEyLdowBvy0N5S0H4WCGbt+DPSsARDsuCTtB5Z28Ew0IzvVDL+/QIU2J1XEn6lcNus85jnZ26KFtyurCePlSeARq2MaMALpjgPlColqM6hJ3CaVfR+Zs4tneaKKuS3MOIa06b56fJegl1DKt5trBfgVTa6bzv0nlEA48i+ondTAZQRHPqPqRT+RhZLsW3r1P6C0x6nfnVIaj/QIVier+IBDJZHbgdS6DcLVGuEdV4jYze1gLugg2SuyUgdzBmNG2XtIFdCloaIn7EUegrlxSWEHdldp7GrK01DCk4Un878MUTCQ==
  • Delivered-to: rest-dev@xxxxxxxxxxx
  • List-archive: <>
  • List-help: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • Thread-index: AQHaSKTc40i8HeA+xUy5T3YdKnwAYrDc5DeAgAAUoYCAAPtvAIAAK3IA
  • Thread-topic: [rest-dev] [External] : Re: Jakarta Rest 3.2?


 It’s not easy to provide an alternative to @Context in 3.2. We need to analyze each type of injection point individually (constructors, fields, properties and method arguments). Some initial thoughts:

 1. Needs to be fully backward compatible in 3.2
 2. Migrating all TCKs to avoid the deprecation messages is a lot of work
 3. We cannot introduce a static dependency with CDI, still needs to be optional
 4. Need to figure out the entity annotation problem
 5. How to deal with ContextResolver(s) 

 Brings back memories as to why we didn’t do this before ...

— Santiago

On Jan 17, 2024, at 7:43 AM, Jan Supol via rest-dev <rest-dev@xxxxxxxxxxx> wrote:

Are you suggesting: 
  • keeping @Body and the injection mechanism used in 3.1 (3.1 injection), ignoring the annotation? 
  • allowing switching the injection modules (3.1 injection vs CDI injection module) when the customer decides to transition from @Context to @Body
  • need to support @Inject by the 3.1 injection wherever the deprecated @Context would be replaced by @Inject 
  • in JBoss (or any application server), you won't be able to use both injection modules at the same time, so only the deprecated injection will be included (to keep the backward compatibility)
  • hence the CDI injection won't be testable by the tck running atop the application server
Or are you suggesting:
  •  teach CDI to understand the @Context and have CDI as the main injection framework
  • update/duplicate all the TCKs to use @Inject and @Body
Or something else?


From: Jim Krueger <jckofbyron@xxxxxxxxx>
Sent: Tuesday, January 16, 2024 10:43 PM
To: Jakarta Rest project developer discussions <rest-dev@xxxxxxxxxxx>
Cc: Jan Supol <jan.supol@xxxxxxxxxx>; James Perkins <jperkins@xxxxxxxxxx>
Subject: Re: [rest-dev] [External] : Re: Jakarta Rest 3.2?

On Jan 16, 2024, at 2:29 PM, James Perkins via rest-dev <rest-dev@xxxxxxxxxxx> wrote:

2. We could support both. If possible, not sure on this, we could require implementations to log a warning  if the @Body annotation is not used. Effectively supporting both the old and new options

I’ve chatted a bit with James on this and I’m thinking that option 2 is likely the only viable option for Jakarta Rest 3.2.    We have to provide an alternative to @Context if we are going to formally deprecate it and I would think that we’d want to also deprecate @Suspended as well.  As a result there may be more than one un-annotated parameter, so support for @Body will be needed.
rest-dev mailing list
To unsubscribe from this list, visit;!!ACWV5N9M2RV99hQ!Kwzg2pkpyVLiEtXSqPnjGDSglMHxL2O0tClkAImyPaOsKD-Ig66trlBf1GPkFGNFMzkaiBYEJVb2RczFEZzHe0sJs0Jg$

Back to the top