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: Marina Vatkina <marina.vatkina_at_oracle.com>
Date: Wed, 13 Jul 2011 12:32:45 -0700

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

There is a Common Annotations spec (JSR 250) that can own annotations
shared by 2 or more specs.
>
>> 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.