Re: [jakartaee-platform-dev] [cdi-dev] Discussion: The new structure of

[Arjan Tijms <arjan.tijms@xxxxxxxxxxx>]

Hi,

The strange thing is that the Jakarta Persistence team is supposedly against a dependency on CDI. The fact this is strange is twofold:

1. CDI is supposed to be the core technology of Jakarta EE. It's at the lowest level. Why are we afraid of "ourselves"? As I asked in the platform call, are Spring projects afraid of being dependent on Spring Beans? Are Java applications being afraid to be dependent on Java classes?

It just does not make sense. If Jakarta Persistence is supposedly not willing to depend on anything Jakarta EE, and is supposedly focusing mainly on Java SE, why would it be a Jakarta EE specification to begin with?

Don't get me wrong, I understand there are timing issues and that there are moments in time when a Jakarta EE runtime boots where CDI is not available yet. Of course that needs to be addressed, like in e.g. MicroProfile Config there is a special construct to use at those early stages. But outright not wanting to have any dependency on CDI, even at places where's it's absolutely technically feasible and useful to the user strikes me as... weird.

2. Perhaps the strangest thing of all, with the Jakarta Persistence team allegedly being against any type of CDI dependency, why do we all seem to forget there already is a CDI dependency in Jakarta Persistence that has been there for a long time? See https://jakarta.ee/specifications/persistence/3.1/jakarta-persistence-spec-3.1#entity-listeners

This also does not make sense at all. How can you be against introducing something that is already there?

Maybe we should recheck our assumptions. Is the Jakarta Persistence team *really* against CDI, or are we just assuming they are?

Kind regards,

Arjan Tijms

On Fri, 17 Nov 2023 at 16:14, Ondro Mihályi via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

> "The Persistence spec team does not want the integration to be present in that repo as it does not want to declare the dependency on CDI because Spring or others will use it potentially."

In that case we should discuss with the Persistence spec team more to see if there's a solution. I don't see a problem why Persistence spec couldn't define additional behavior  in case CDI container is present. If used without CDI, that functionality would not simply be available and that's OK.

If the Persistence team would be adamant in refusing any type of (optional) dependency on CDI, then I suggested resorting to adding Persistence x CDI integration into the Platform/profile spec. But, if there are no good arguments from the Peristence spec team, then I would sincerely question whether the Persistence team wants Jakarta EE to be successful or they care only about Spring and other non-Jakarta EE usages of Persistence.

All the Jakarta EE specs should work well together, not only work standalone. The purpose of Jakarta EE is to create a coherent set of standard APIs, not individual APIs. If they work well as standalone, that's a good bonus. But the other way doesn't work well for the Jakarta EE community.

Ondro

On Fri, Nov 17, 2023 at 3:45 PM Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Ondro, Nathan,

What Ondro said does not address the dependency issue, which was the reason to have the 2 proposals. As for CDI, it puts dependencies on other specs and other specs have dependencies on CDI, which creates circular dependencies. For Persistence, as discussed on this week's platform call, the Persistence spec team does not want the integration to be present in that repo as it does not want to declare the dependency on CDI because Spring or others will use it potentially.

Thanks

Emily

On Fri, Nov 17, 2023 at 2:35 PM Nathan Rauh via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

I agree with Ondro’s response that introducing new specifications for integration requirements is overdoing it, and favor what he suggests in his second paragraph below (can this be Proposal 3?), that the specification define the integration requirement to apply when the other Jakarta specification is present.  I have used that approach many times in Jakarta specifications and it works very well:  "In environments/profiles where Jakarta specification X is available, … must happen."  It helps to have the outermost specification--most distant from core profile or most distant from wave 1--define the requirement. Generally, that is easily done.

 

It should be an extremely rare case where this doesn’t solve the problem, and only in those exceptional cases should it be necessary that proposal 1 or 2 be used.  I don’t want to see proposal 1 or 2 applied across the board to all integration points between specifications.  That would cause unnecessary churn in specifications and burden already thinly stretched specification teams with additional work that has little, if any, value.

 

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Ondro Mihályi via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Date: Friday, November 17, 2023 at 4:24 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Ondro Mihályi <mihalyi@xxxxxxxxxxx>, cdi developer discussions <cdi-dev@xxxxxxxxxxx>, jpa-dev@xxxxxxxxxxx <jpa-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] [cdi-dev] Discussion: The new structure of EE integration sections

From the 2 proposals, I favor the option 1 (already existing platform/profile specs) But I think a cleaner solution is that individual specs like persistence, or servlet define this behavior in case CDI container is present. Faces and Transactions

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

    Report Suspicious    ‌

ZjQcmQRYFpfptBannerEnd

From the 2 proposals, I favor the option 1 (already existing platform/profile specs)

 

But I think a cleaner solution is that individual specs like persistence, or servlet define this behavior in case CDI container is present. Faces and Transactions already do so, they define custom scopes or @Transactional interceptor. Other specs should do so too. If those specs don’t do accept that, the I would define it in the platform/profile specs as a last resort.

 

But introducing a new spec looks like an overkill for me.

 

Ondro

 

On Thu, 16 Nov 2023 at 17:00, Matej Novotny via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

The Proposal 2 is what has been voiced during CDI calls by multiple people (me included) but has been repeatedly decided against; although I fail to recall the reasons now.

I am definitely for option 2 as that's way simpler to keep track of as opposed to creating multitude of other separate projects.

 

As for the ownership I don't see that as a con, or rather, I don't think there is much difference between putting the spec/tcks into platform bits and into separate "EE integration" project.

After all, it's integration of spec X and spec Y which already implies there should two be interested parties participating on that spec part and relevant TCKs.

So maybe it would be even better to have these parts stored on a "neutral ground" so to speak (platform spec/tck) so that both parties can cooperate there without arguing whose responsibility that is based on where that code currently resides.

 

Just my 0.02$

Matej

 

On Thu, Nov 16, 2023 at 4:19 PM Emily Jiang via cdi-dev <cdi-dev@xxxxxxxxxxx> wrote:

Further to this week's discussion regarding where to put EE integration chapters for Jakarta Specifications, we need to discuss offline to evaluate the approaches. At the moment, CDI EE was proposed to be a new spec (see here) while Jakarta Persistence with CDI integration was proposed to be added to the platform specification (see here). It is better to be consistent across the platform project.

 

Context: some Jakarta EE specifications have integration parts with other Jakarta EE specifications, such as CDI or potentially Jakarta Persistence.

 

Issue: These dependencies might introduce some circular dependencies among the specs. In order to avoid the circular dependencies, the integration parts need to be somewhere else.

 

Proposals:

Proposal 1: Create a new specification to hold all of the integration part, such as CDI EE, Persistence EE

Pros:

The ownership is clear to start with but it might not be once the relevant specs start adding tcks.

 

Cons:

The number of specs might be increased dramatically.

For some certification with web/core profile or platform, separate parts are to be spelled to differentiate web/core profile or platform implementers.

 

 

Proposal 2: put the integration part to Core/Web Profile or Platform specifications under separate modules.

Pros:

The number of the specs will not change.

It is clear that certification for core/web profile and platform are clear which tcks are to be executed.

This can be released when releasing the platform or web profile or core profile. However, these TCKs can be released individually.

 

Cons:

The ownership is less clear. It might not be an issue if the involved spec teams work together on this or the tests clearly document the owners.

 

 

Please add other proposals and cons/pros I missed.

--

Thanks
Emily

_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-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

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

--

Thanks
Emily

_______________________________________________
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