Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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, 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
From: rest-dev <rest-dev-bounces@xxxxxxxxxxx> on behalf of Markus KARG via rest-dev <rest-dev@xxxxxxxxxxx>
Sent: Wednesday, December 10, 2025 1:23 AM
To: rest-dev@xxxxxxxxxxx <rest-dev@xxxxxxxxxxx>
Cc: Markus KARG <markus@xxxxxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [rest-dev] Jakarta REST Release Plans
 
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.

[1]: https://github.com/jakartaee/rest/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A5.0

James R. Perkins
Software Developer 

IBM

_______________________________________________
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

Back to the top