Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Re: [cdi-dev] Discussion: The new structure of EE integration sections

Completely agree with  you, Ladislav. If I remember correctly Arjan Tijms also proposed merging a few specs, one of them was merging CDI, DI and interceptors.

https://www.eclipse.org/lists/jakartaee-platform-dev/msg03286.htmlJakarta Dependency Injection and Jakarta Contexts and Dependency Injection and Jakarta Interceptors into one spec.

CDI 5 timeframe should be good to merge specs and remove deprecated apis.

On Tue, 21 Nov 2023 at 13:15, Ladislav Thon via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
On Mon, Nov 20, 2023 at 11:04 PM Lukas Jungmann via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
On 17.11.2023 18:22, Ondro Mihályi via jakartaee-platform-dev wrote:
> [..]  CDI shouldn't
> depend on any other dependency besides Java SE, it should be one of the
> core Jakarta EE specifications.

I do see that at this point cdi-api has 5 dependencies, including
jakarta.el-api for instance. Is jakarta.el part of Java SE or is that
part of the CDI itself?

I generally agree that CDI should be a "core" spec, but the claim that it shouldn't depend on anything but Java SE is overly restrictive in my opinion.

There are a few specifications that are even more fundamental than CDI: Common Annotations, Dependency Injection (part of the CDI project), Interceptors. (To be honest, the Interceptors spec, having to serve both CDI and EJB, is a strange beast and doesn't really serve CDI very well. If I could, I would fold it into CDI.)

In addition to these, CDI depends on the CDI Language Model (which could be moved away from CDI easily -- some specifications expressed interest in this API, so we made it a separate artifact to ensure we don't accidentally make it depend on anything CDI) and _expression_ Language. The EL dependency only exists because of 2 methods in `BeanManager` which are AFAIK only useful for integrating into a container that includes EL. We're working on removing this dependency from the core CDI API; in CDI 4.1, we're deprecating these methods and providing a replacement (which is outside of the core CDI API), and we plan to remove them in CDI 5.0. 

LT
 

thanks,
--lukas

  If we move all EE-related stuff from CDI
> to related specs, those specs would depend on CDI at compile time, not
> the other way around.
>
> Ondro
>
> On Fri, Nov 17, 2023 at 6:18 PM Nathan Rauh via jakartaee-platform-dev
> <jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>> wrote:
>
>     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.____
>
>     __ __
>
>     *From: *Emily Jiang <emijiang6@xxxxxxxxxxxxxx
>     <mailto:emijiang6@xxxxxxxxxxxxxx>>
>     *Date: *Friday, November 17, 2023 at 10:43 AM
>     *To: *Nathan Rauh <nathan.rauh@xxxxxxxxxx
>     <mailto:nathan.rauh@xxxxxxxxxx>>
>     *Cc: *jakartaee-platform developer discussions
>     <jakartaee-platform-dev@xxxxxxxxxxx
>     <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
>     *Subject: *[EXTERNAL] Re: [jakartaee-platform-dev] [cdi-dev]
>     Discussion: The new structure of EE integration sections____
>
>     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 ____
>
>     ZjQcmQRYFpfptBannerStart____
>
>     *This Message Is From an External Sender ____*
>
>     This message came from outside your organization. ____
>
>     *  Report Suspicious *
>     <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJDRIpn0my8bFK8l4j3WvBcGnwzWuF7-dcqTCv1BmLWu0O6MEeEeppxsa_gFAOXDxY7AT0aN65LK4hHlnfE-37ODE3EhdsNg7zYJrfMnzh3GmJxkTqmGA2mI$>  ‌ ____
>
>     ZjQcmQRYFpfptBannerEnd____
>
>     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 can use CDI extension to provide
>     the additional Beans such as EnitityManager for injection.____
>
>     Thanks____
>
>     Emily____
>
>     __ __
>
>     On Fri, Nov 17, 2023 at 3:13 PM Nathan Rauh <nathan.rauh@xxxxxxxxxx
>     <mailto:nathan.rauh@xxxxxxxxxx>> wrote:____
>
>         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.____
>
>         ____
>
>         ____
>
>         *From: *jakartaee-platform-dev
>         <jakartaee-platform-dev-bounces@xxxxxxxxxxx
>         <mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>> on behalf
>         of Emily Jiang via jakartaee-platform-dev
>         <jakartaee-platform-dev@xxxxxxxxxxx
>         <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
>         *Date: *Friday, November 17, 2023 at 8:45 AM
>         *To: *jakartaee-platform developer discussions
>         <jakartaee-platform-dev@xxxxxxxxxxx
>         <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
>         *Cc: *Emily Jiang <emijiang6@xxxxxxxxxxxxxx
>         <mailto:emijiang6@xxxxxxxxxxxxxx>>
>         *Subject: *[EXTERNAL] Re: [jakartaee-platform-dev] [cdi-dev]
>         Discussion: The new structure of EE integration sections____
>
>         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.  ____
>
>         ZjQcmQRYFpfptBannerStart____
>
>         *This Message Is From an External Sender *____
>
>         This message came from outside your organization. ____
>
>         *  Report Suspicious *
>         <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJDRIpn0mYUQd4sEg92kdKZCi1tdScISeQyrMsCrXuBegx8LdPoHVhZZaN65YtDXQ40KN1fru4DHMSaGfYdhkWk1yJ4Q6tGScNxk3RSZyRCareyJd3Z0rDpC$>  ‌ ____
>
>         ZjQcmQRYFpfptBannerEnd____
>
>         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
>         <mailto: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
>             <mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>> on
>             behalf of Ondro Mihályi via jakartaee-platform-dev
>             <jakartaee-platform-dev@xxxxxxxxxxx
>             <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
>             *Date: *Friday, November 17, 2023 at 4:24 AM
>             *To: *jakartaee-platform developer discussions
>             <jakartaee-platform-dev@xxxxxxxxxxx
>             <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
>             *Cc: *Ondro Mihályi <mihalyi@xxxxxxxxxxx
>             <mailto:mihalyi@xxxxxxxxxxx>>, cdi developer discussions
>             <cdi-dev@xxxxxxxxxxx <mailto:cdi-dev@xxxxxxxxxxx>>,
>             jpa-dev@xxxxxxxxxxx
>             <mailto:jpa-dev@xxxxxxxxxxx><jpa-dev@xxxxxxxxxxx
>             <mailto: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 *
>             <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJA1yxHVsKtWOKHJwMOJoeIYgm32bsAX8ECrog84gVNZuNteH8TCuJoCOBwkAGjXqptM2yFpJUUnKORLxwPreByrzVQIhq14EgnX3EmB-YVk7xMVfyom9RdD$>  ‌ ____
>
>             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
>             <mailto: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 <mailto: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
>                     <https://urldefense.com/v3/__https://github.com/jakartaee/specifications/pull/665__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQwhEkutj$>) while Jakarta Persistence with CDI integration was proposed to be added to the platform specification (see here <https://urldefense.com/v3/__https://github.com/jakartaee/platform/pull/746__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQ50OGs_L$>). 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 <mailto:cdi-dev@xxxxxxxxxxx>
>                     To unsubscribe from this list, visit
>                     https://www.eclipse.org/mailman/listinfo/cdi-dev
>                     <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/cdi-dev__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQ-nZVuCr$>____
>
>                 _______________________________________________
>                 jakartaee-platform-dev mailing list
>                 jakartaee-platform-dev@xxxxxxxxxxx
>                 <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
>                 To unsubscribe from this list, visit
>                 https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQ94mOsO9$>____
>
>             _______________________________________________
>             jakartaee-platform-dev mailing list
>             jakartaee-platform-dev@xxxxxxxxxxx
>             <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
>             To unsubscribe from this list, visit
>             https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQ94mOsO9$>____
>
>
>
>         -- ____
>
>         Thanks
>         Emily____
>
>
>
>     -- ____
>
>     Thanks
>     Emily____
>
>     _______________________________________________
>     jakartaee-platform-dev mailing list
>     jakartaee-platform-dev@xxxxxxxxxxx
>     <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
>     To unsubscribe from this list, visit
>     https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>     <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQ94mOsO9$>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQ94mOsO9$

_______________________________________________
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


--
Regards,
Anbu

Back to the top