jsr345-experts@ejb-spec.java.net

[jsr345-experts] Re: [ejb-spec users] Re: EJB_SPEC-19 - Decoupling the @Startup/@DependsOn annotations from the EJB component model

From: Reza Rahman <reza_rahman_at_lycos.com>
Date: Tue, 12 Jul 2011 20:19:41 -0400

Pete,

* @AfterBegin, @AfterCompletion and @BeforeCompletion to me seem to
have parallels in the CDI transactional events, and I prefer that model
really.
- Not sure. The EJB way in this case seems more developer-friendly.
* @PrePassivate/_at_PostActivate would be useful in the CDI world I think.
* We should consider some sort of extended persistence for CDI though.
- Agreed.
* @Remove doesn't make any sense, as CDI beans are container managed not
user managed, and you can't remove them ad-hoc.
- Agreed. I think what's really needed is @Begin/_at_End for
@ConversationScoped.

Cheers,
Reza


On 7/12/2011 4:03 PM, Pete Muir 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.
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1390 / Virus Database: 1516/3760 - Release Date: 07/12/11
>
>
>