[cdi-dev] [PROPOSAL] further align CDI and EJB

Fri Nov 13 03:49:04 EST 2015

Well, that was my point of splitting out these metadata scanning and
processing into an independent spec, which CDI will depend on and maybe EJB
in some future too, if their EG adopts it. As there is no global inter-spec
coordination for  - Mark called it - "EE umbrella" one can simply have a
chat with them and keep the fingers crossed.

br, Sven

2015-11-12 17:00 GMT+01:00 Mark Struberg <struberg at yahoo.de>:

> >  So why wouldn’t the entire EE ecosystem be described at the EE level?
>
> Perfectly nailed.
> But here is the problem: the EE umbrella does NOT do code. It does NOT
> provide an own TCK. It just packages together the other specs (and
> sometimes imposes restrictions and additional features on it).
>
> LieGrue,
> strub
>
>
> > Am 12.11.2015 um 13:51 schrieb John D. Ament <john.d.ament at gmail.com>:
> >
> > Splitting out into more specs probably won't solve the issue.  My honest
> opinion is that neither CDI nor EJB should describe how the other spec
> works.  The way JAX-RS, Bean Val, JMS describe it makes more sense, IF CDI
> is available, these additional things occur.
> >
> > The probably is that CDI has already describe certain aspects about
> EJB.  Because of that, its likely ours forever.
> >
> > The way most of these other services operate, it feels like they're all
> app server level integrations.  So why wouldn't the entire EE ecosystem be
> described at the EE level?
> >
> > On Thu, Nov 12, 2015 at 5:46 AM Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
> > From my POV problems are:
> >
> > - EJB spec totally ignore CDI (it's CDI that does all the job of EJB
> integration)
> > - EJB spec won't be reopened except for minor MR
> > - I launched the proposition for a new spec based on our AnnotatedType
> meta model when we were discussing about config spec. I didn't have enough
> support from Red Hat and EG so I put it back in my drawer.
> >
> > Antoine
> >
> > Le jeu. 12 nov. 2015 à 11:17, Tomas Remes <tremes at redhat.com> a écrit :
> >
> > I think nothing will happen in EJB spec so I would not really rely on
> some future collaboration. Another case is this classpath scanning and
> AnnotatedType/PAT stuff. This sounds to me like quite interesting idea at
> least at first glance.:) But the question is: Isn't it late to propose any
> new JSR for upcoming EE 8? I guess it is so this seems to me bit out of
> scope for CDI 2.x... maybe CDI 3?:)
> >
> > Tom
> >
> > ----- Original Message -----
> > From: "Sven Linstaedt" <sven.linstaedt at gmail.com>
> > To: "Romain Manni-Bucau" <rmannibucau at gmail.com>
> > Cc: "cdi-dev" <cdi-dev at lists.jboss.org>
> > Sent: Thursday, November 12, 2015 10:45:22 AM
> > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> >
> > +1 for splitting the classpath scanning and all AnnotatedXXX /
> ProcessAnnotatedType type parsing/overriding from the CDI in an own spec,
> so other specs (not only EJB) may rely on it.
> >
> > 2015-11-11 20:54 GMT+01:00 Romain Manni-Bucau < rmannibucau at gmail.com >
> :
> >
> >
> >
> > Hi Mark,
> >
> > few points on that topic:
> >
> > - let the EJB container reuse AnnotatedType (ie even add @Stateless
> through an Extension): +1
> > - veto an EJB as a whole and not only in CDI side - ie @Schedule is
> ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it
> would break the compatibility with extsing apps I fear since veto is 100% a
> CDI thing today.
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog | Github | LinkedIn | Tomitriber
> >
> > 2015-11-11 11:47 GMT-08:00 Mark Struberg < struberg at yahoo.de > :
> >
> >
> > Hi!
> >
> > We already do a decent amount of ‚side-by-side‘ handling in EJB and CDI.
> But there are still many aready where we could really move together much
> closer.
> >
> > E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the
> EJB container. But what happens with ProcessAnnotatedType#veto(). This one
> is not defined that clearly I fear.
> >
> > What if we (of course together with the EJB spec group) define that the
> EJB container must create the EJBs according to the effective AnnotatedType
> coming out after ProcessAnnotatedType? This would define that EJBs can also
> get modified via CDI Extensions. Some container do that already.
> > The benefit of explicitly writing this down would obviously be that we
> would allow EJB to fully utilize the power of CDI Extensions in a portable
> way.
> >
> > Any objections, any ideas, any howtos?
> >
> > Let the ideas roll ;)
> >
> > LieGrue,
> > strub
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> > --
> > Tomas Remes
> >
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151113/9ab067a1/attachment-0001.html 