[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] [cdi-dev] Discussion: The new structure of EE integration sections
|
The problem has been that components specs do not want to do this. JPA does not want to do it. Some in Servlet do not want to do it. Any spec that has its own container and/or a Java SE mode are careful to avoid CDI ingression on their baseline of operation. Integration is a platform concern and that is where we feel it should be handled.
I think we agree here, Scott, that CDI shouldn't deal with integrations. But I think that it's the responsibility of other specs to integrate with CDI, and they should define the integration. No need for a separate spec.
Ondro
"TCKs are not a right justification for requiring the creation of new specifications."
Why? The TCKs are what specifications base claims of compatibility on, and they trigger IP flow. One should be able to write the CDI core specification with its TCK tests, and deal with integration behavior and tests separately. This is valid both in terms of dependencies and ensuring the right set of experts is involved.
It’s certainly true that a specification that covers CDI integration will need TCK tests of the CDI integration. There are a variety of strategies already available for ensuring TCK coverage. Platform TCKs
are one good place for covering integration. Component TCKs can do so as well, provided they have modes for running in Jakarta EE profiles vs standalone. The latter would require a compile dependency to build the TCK, but no run time dependency on CDI when
running in the standalone mode. I don’t see why that should be a problem because TCKs already have compile dependencies on all sorts of artifacts. But if Jakarta Persistence for some reason doesn’t want that approach, they still have the option of covering
integration requirements in platform TCKs. TCKs are not a right justification for requiring the creation of new specifications.
Nathan, Not sure whether you were on this week's platform call. If spec has the CDI dependencies, the TCKs will have dependencies on CDI. I think Lukas does not
want the spec to rely on CDI. The runtime that supports both CDI and Persistence
This Message Is From an External Sender
|
This message came from outside your organization.
|
|
|
Not sure whether you were on this week's platform call. If spec has the CDI dependencies, the TCKs will have dependencies on CDI. I think Lukas does not want the spec to rely on CDI. The runtime that supports
both CDI and Persistence can use CDI extension to provide the additional Beans such as EnitityManager for injection.
Jakarta Persistence doesn’t need to define a dependency on CDI just to write about CDI in the Persistence specification document. Unless there is
some deeper issue about needing to define Jakarta Persistence API classes that compile against CDI API classes, no dependency should be required. If the deeper issue does exist, then it is one of the rare exceptions. If I followed the links that you provided
in your original email, the changes are all in the specification document text and some xml-related files – nothing that requires compilation against CDI.
My main point here is that I don’t want to see the more drastic solution for the corner case problem to be enforced for the sake of consistency across
all integration points where it isn’t necessary in the majority of cases. Possibly I didn’t understand your statement in the original email for the solution “to be consistent across the platform project.” I understood that to mean the solution will be applied
to all integration points across the Jakarta platform for consistency.
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.
This Message Is From an External Sender
|
This message came from outside your organization.
|
|
|
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.
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 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
This Message Is From an External Sender
|
This message came from outside your organization.
|
|
|
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.
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.
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.
Proposal 1: Create a new specification to hold all of the integration part, such as CDI EE, Persistence EE
The ownership is clear to start with but it might not be once the relevant specs start adding tcks.
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.
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.
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.
_______________________________________________
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
--
--
_______________________________________________
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