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 <
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.