[
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
|
I fully agree with you, Ladislav. No need that CDI depends on EL, interceptors could be merged into CDI if not shared with EJB, e.g. if EJB spec builds on top of CDI one day. My claim was an overstatement, I meant CDI should have only minimum dependencies.
Ondro
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
