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

[Reza Rahman]

Responses in-line:

> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> 
> 2015-11-16 14:40 GMT-08:00 Reza Rahman <reza.rahman at oracle.com>:
>> In terms of CDI and EJB alignment, I think these would have the most
>> value to the community going forward:
>> 
>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has
>> similarly nice syntax to handle eager loading).
> 
> @Startup is there with @Initialized(ApplicationScoped) event
> @DependsOn is less important than for EJB IMO cause all CDI is lazy
> and full of proxies so not sure it would bring much to the game
> without bringing really much more like @Schedule etc...

Yes, I know but eager loading is a common enough case to warrant better syntax/usability.

> 
>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for CDI.
>> These are very useful bits of functionality that should be available to
>> plain CDI beans without EJB. A similar @MaxConcurrency could also be
>> extremely useful. EJB @Schedule is similarly useful but likely not right
>> for CDI proper as it does not have that much to do with component
>> life-cycle/bean access management. The others I think are quite natural
>> fits for the core of a DI framework (in fact it may be awkward to have
>> them elsewhere).
> 
> 
> Think concurrency utilities can have a CDI integration rather than
> putting everything in CDI. It is globally all interceptors - at least
> in term of design - so would make sense to have them outside IMO - but
> a big +1 to get them cleanly added on top of CDI.

Keep in mind, Java EE concurrency utilities is also minimally resourced and that's unlikely to change in the future. I would say if we think these features would help community/CDI adoption, it's likely wisest to find a way to do it in CDI proper. As I alluded to, these are also a bit easier to implement at the core DI container level than via interceptors. Things like @Transcational, @Schedule are easier as interceptors since they don't have as much to do with the internals of the component life-cycle and instance access control.

> 
>> 
>> As to doing more work in EJB, honestly it's likely best to leave EJB be
>> at this stage. If there is a compelling reason that helps the platform
>> and CDI generally we can see if it can be done. By default, EJB is
>> pretty minimally resourced for Java EE 8 and that's pretty hard to
>> change at this stage. In the community I have mostly seen requests for
>> moving functionality out of EJB into CDI rather than the other way around...
>> 
>>> On 11/11/2015 2:47 PM, Mark Struberg wrote:
>>> 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.