Hi Marina,
Sounds like an excellent solution!
On 21 June 2011 01:48, Marina Vatkina <marina.vatkina_at_oracle.com> wrote:
> Pete, Reza,
>
> As it was mentioned in the JSR submission, refactoring TransactionAttribute
> to some common location is on the todo list. I'll need top discuss with Bill
> and Linda the proper way to do it, but you guys can bring this up at the
> platform EG as well.
>
> I had preliminary discussions with the JMS spec lead (Nigel), and
> simplifications and improvements in the MDB/JMS area are on the JMS spec
> high priority to-do list as well. We'll follow up on that in the EJB JSR.
>
> HTH,
> -marina
>
> Pete Muir wrote:
>>
>> I think all of these belong in the EJB or JMS spec, and not in the CDI
>> spec. The reasoning behind this is primarily organisational:
>>
>> 1) That the CDI expert group is comprised of experts in developing
>> programming model APIs and not domain experts groups in transactions,
>> pooling, or messaging technology.
>> 2) That the JMS and EJB EGs do comprise experts (I hope) in such things
>> 3) That CDI has a stable and well known API and programming model which
>> these other EGs can build upon to develop such features. Assistance can be
>> provided by CDI experts as needed, but they don't have the domain knowledge
>> to build an API, just on how to align the programming model
>> 4) That the CDI spec should concentrate on programming model not on
>> enterprise service integration
>>
>> On 18 Jun 2011, at 01:27, Reza Rahman wrote:
>>
>>
>>>
>>> Folks,
>>>
>>> I guess this is a question more for Marina and/or Pete as well as for all
>>> of us collectively to ponder (and maybe the Java EE EG). As I mentioned in
>>> my introductory email, there are a number of EJB-ish features that I
>>> personally believe is a better fit for the CDI 1.1 and/or JMS 2
>>> specifications. Here is a partial list of such features:
>>>
>>> * Introducing the @TransactionScoped and @ThreadScoped CDI scopes geared
>>> towards using back-end resources in a thread-safe manner in plain managed
>>> beans.
>>>
>>
>> I would like to see this done in EJB.
>>
>>
>>>
>>> * Introducing the @PoolScoped CDI scope as a way of providing the
>>> equivalent of stateless session beans in plain managed beans. Alternatively
>>> or in addition to, a @MaxActive annotation could be introduced.
>>>
>>
>> I don't see the desperate need for this, EJB offers this through stateless
>> session beans. The API for SLSBs could be improved to align with CDI better.
>>
>>>
>>> * Re-factoring Message Driven Beans to enable message receivers in plain
>>> managed beans via CDI observers.
>>>
>>
>> I believe the JMS 2 EG have this on their TODO, I am planning to check up
>> on this.
>>
>>
>>>
>>> * Standardizing some common JMS activation properties as direct message
>>> listener attributes.
>>>
>>
>> Not 100% sure what this means.
>>
>>
>>>
>>> Now, a lot of this hinges on successfully decoupling EJB transactions
>>> from the component model. If we are reasonably confident that this will
>>> happen and agree that these features really belong outside the EJB
>>> specification, I'd like to bring them up ASAP in the CDI 1.1 and/or JMS 2
>>> EGs. I thought it's only fair to check here first before I went down that
>>> path too far...
>>>
>>
>> Marina, wdyt?
>>
>> Pete
>
--
Pete Muir
http://in.relation.to/Bloggers/Pete
http://www.seamframework.org