|
Markus,
Sorry, I wasn't clear. I do think it can be used, I think we just need to define it. Right now there is no requirement on SeBootstrap and CDI. We just need to introduce the dependency.
To be the bigger concern are providers used on the client side that may be outside of a container all together. Right now I could have a standalone application that just makes a REST call with the jakarta.ws.rs.client.Client which uses a MessageBodyReader to
resolve a jakarta.json.binding.Jsonb object. If we deprecated the ContextResolver, we need another way to do that.
James R. Perkins
Software Developer
IBM
From: Markus KARG <markus@xxxxxxxxxxxxxxx>
Sent: Thursday, December 11, 2025 9:24 AM
To: James Perkins <jperkins@xxxxxxx>; rest-dev@xxxxxxxxxxx <rest-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [rest-dev] Jakarta REST Release Plans
James, maybe it's just me being on PTO for too long ;-), but could you please share some brief picture with me why you think CDI cannot be handled in the SE case? Actually I am already using standalone Jersey INCLUDING CDI since several years,
James,
maybe it's just me being on PTO for too long ;-), but could you please share some brief picture with me why you think CDI cannot be handled in the SE case? Actually I am already using standalone Jersey INCLUDING CDI since several years, and it works fine
(TBH, actually I am using Jersey's NATIVE SE bootstrap, not the JAX-RS SE bootstrap - but originally I designed SeBootstrap AROUND Jersey's, actually). What in particular do you see as the problematic detail?
-Markus
Am 11.12.2025 um 16:51 schrieb James Perkins:
Hello Markus,
Sorry the day delay, yesterday got away from me 🙂
I need to do some testing, but I think for the most part RESTEasy could be close. I've already got CDI producers for most known @Context types. However, I've not looked at creating producers based on a ContextResolver. There could be a way to some treat
it as a producer, but I've not looked into it.
I do still think the biggest question becomes how we handle CDI outside of an EE container. We'd have to determine if we simply do not support injection there or we require a CDI container be available. The SeBootstrap part is easier as CDI also as an
SE requirement. The client is what concerns me the most. Things like using MessageBodyReaders or MessageBodyWriters which use @Context to inject requirements. I don't really know how we handle those. In theory we could just use @Inject, but that's not really
CDI so to speak.
That said, that if we're not doing CDI a 4.1 seems much more practicle. Moving forward, I definitely think we need to breath some life back into this specification. It's core web layer in the Jakarta EE Core Profile.
James R. Perkins
Software Developer
IBM
James, thank you for starting this discussion. Following the Eclipse Foundation's "Code First" philosophy, we should first check if the JAX-RS implementations actually are ready for this step. So hands up please: Which implementation already
James,
thank you for starting this discussion.
Following the Eclipse Foundation's "Code First" philosophy, we should first check if the JAX-RS implementations actually are ready for this step. So hands up please: Which implementation already implemented the CDI changes? If we do not find at least one,
we MUST stick with 4.1, as downstreams EXPECT the CDI changes with 5.0, as IMHO it is not possible to do that before end of January.
-Markus
Am 09.12.2025 um 17:57 schrieb James Perkins via rest-dev:
Our current release plan [1] has 9 open issues. Does anyone feel we're going to have time to sort out the CDI changes we want? If not, should we be doing a 4.1 instead of a 5.0 given we won't be changing much else?
We do need changes for the OSSRH updates. This is something I can have a look at.
Jakarta EE 12 would like an M2 by January 27th. We missed the M1 release as we weren't ready for it. I don't think we should miss the M2, which was previously due today, though. The Jakarta REST spec is in the Jakarta EE Core Profile so we really need to be
prepared for a release.
James R. Perkins
Software Developer
IBM
_______________________________________________
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
|
