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.