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

Thu Nov 12 09:46:24 EST 2015

Le 12 nov. 2015 04:52, "John D. Ament" <john.d.ament at gmail.com> a écrit :
>
> 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?

Sounds legitimate from an organisation point of view but not consistent
from a technical point of view. Why ensuring all spec redefine the same
things and just trying to make them fit if possible instead of ensuring
they can share the same technical stack when a need is shared - more or
less all major spec  need scanning?

That said it needs to be moved to EE as a change in the way spec are driven
ans not just there IMO.

>
>
> 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/20151112/93f04e91/attachment-0001.html 