4:12 a.m.
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(a)gmail.com>
To: "Romain Manni-Bucau" <rmannibucau(a)gmail.com>
Cc: "cdi-dev" <cdi-dev(a)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(a)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(a)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(a)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(a)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(a)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