Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Unify the Container Managed Resource Definitions
Hi Hantsy,

> For Jakarta EE developers, providing a **consistent experience** across all specs is also vast.

I am completely in agreement with this. I have proposed consistency as an overarching theme for Jakarta EE releases multiple times.

While progress is slow, some steps are being taken for EE 12, such as making @Lock in Concurrency and REST resources CDI beans. Admittedly, this alignment should have been completed around 2012 for EE 7, and the extent of these delays is unfortunate.

One of the strengths of Jakarta EE (decentralized control) is also its weakness here. Many specs have individual leads or majority contributors who have their own ideas, and don't take the platform into consideration. There's one important spec where seemingly Java SE is the number 1 concern, Java SE is also the number 2 concern, then Spring is the number 3 concern, and with a lot of space in between Jakarta EE is, maybe, as an afterthought the number 4 concern.

At OmniFish we would love to work on exactly those work items you propose, and I'd basically literally implement them like you sketched them. The problem is however always time and available people. We're now working hard on Security (adding first class support for REST and JWT) and Faces (many many small improvements) and somehow have to find time to implement the new Persistence features in EclipseLink and update the Jakarta Persistence support for Data 1.1 in JNoSQL.

Best regards,
Arjan Tijms


On Thu, 30 Apr 2026 at 16:49, lenny--- via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
These all sounds like great ideas, hopefully they will be considered.

On Apr 30, 2026, at 3:45 AM, hantsy bai via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Hi
Since Java EE 7, the Java EE/Jakarta EE has had container resource definitions via a series of annotations. Such as

* DataSourceDefinition
* The security-related XXXXAuthenticationMechanismDefinition
* The concurrency-related ManagedExecutorDefinition, ContextServiceDefinition, ManagedThreadFactoryDefinition, etc.
* The JMSDestinationDefinition, and factory definition.

As time goes by, the security and concurrency annotations have CDI alignment, and EL in the security annotation attributes. But the most useful annotation -
`DataSourceDefinition`, and the old JMS-related annotations have not evolved for a few years.

I hope that in the incoming Jakarta EE 12, these will be considered:

* allow injecting default DataSource by `@Inject`
* allow adding Qualifier to DataSourceDefintion and JMSXXX, and inject them via CDI `Inject` with qualifiers. 
* It is better to add EL support as security annotations, especially the DataSourceDefinition, while Payara and Wildfly have their own solutions for it, it is better to use the standard EL for it.

This is just a very **small improvement**, but for end users (Java backend developers using Jakarta EE), it is a big step forward.

I remember adding several issues for these, but unfortunately, every spec focuses on developing new features.  For Jakarta EE developers, providing a **consistent experience** across all specs is also vast.

BTW, I also proposed a similar annotation to expose `PersistenceContext/Unit` or `EntityManagerFactory/EntityManager` via creating a new similar annotation, check here:

and 

I just need similar features to declare container-managed ` EntityManagerFactory/EntityManager ` resources via annotations, like the existing annotations, but the discussions are finally missing direction and closed.  I am not sure if my _expression_ is unclear or if other developers have never used these features. 

---

Regards,

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker

GitHub: https://github.com/hantsy

Twitter: https://twitter.com/@hantsy

Medium: https://medium.com/@hantsy
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top