[jsr345-experts] Fwd: [ejb-spec users] Re: EJB_SPEC-19 - Decoupling the @Startup/@DependsOn annotations from the EJB component model
From Emmanuel.
Begin forwarded message:
> From: Emmanuel Bernard <ebernard_at_redhat.com>
> Date: 13 July 2011 08:45:44 GMT+01:00
> To: Pete Muir <pmuir_at_bleepbleep.org.uk>
> Cc: "jsr345-experts_at_ejb-spec.java.net" <jsr345-experts_at_ejb-spec.java.net>
> Subject: Re: [ejb-spec users] [jsr345-experts] Re: EJB_SPEC-19 - Decoupling the @Startup/_at_DependsOn annotations from the EJB component model
>
> I havent thought much about a generalized PC management outside EJB but I tend to like the idea in principle.
> A PC lifecycle and propagation rules are driven by:
> * the scope of the component (think stateful/stateless SB)
> * the JTA transaction status
> If we can rely on those in raw CDI, we can think about a PC management outside EJBs
>
> Emmanuel
>
> On 12 juil. 2011, at 22:03, Pete Muir <pmuir_at_bleepbleep.org.uk> wrote:
>
>>
>> On 11 Jul 2011, at 15:39, Reza Rahman wrote:
>>
>>> Pete,
>>>
>>> We did not want to mess with the actual current semantics of the annotation, so for us it only works if you have @Named, managed beans or EJBs. I think a generalized solution should allow for expressing dependencies via names, classes and/or component-level annotations (qualifiers, stereotypes, servlets, ejb types, etc). Basically a declarative form of BeanManager.getBeans?
>>
>> Yep, this seems to me the only CDI friendly way to do this.
>>
>> I guess it would be interesting to hear what Marina and others think about whether we can do this split. If we can worth discussing this in CDI EG.
>>
>>>
>>> Incidentally, what's your thoughts on decoupling @AfterBegin/_at_AfterCompletion/_at_BeforeCompletion/_at_PostActivate/_at_PrePassivate/_at_Remove. We don't have those decoupled yet on Resin because they seem tougher to justify outside the EJB world. Same for the extended persistence scope...
>>
>> @AfterBegin, @AfterCompletion and @BeforeCompletion to me seem to have parallels in the CDI transactional events, and I prefer that model really. @PrePassivate/_at_PostActivate would be useful in the CDI world I think. @Remove doesn't make any sense, as CDI beans are container managed not user managed, and you can't remove them ad-hoc.
>>
>> Regarding the extended persistence context, that one is tougher I think as the semantics are very coupled to EJB. We should consider some sort of extended persistence for CDI though. I'm not a persistence expert, so I tend to defer these question to Emmanuel ;-)
>>
>> Emmanuel, do you have any preliminary thoughts about this? If you do, I can forward them to the EJB EG.