On 21.06.2011, at 02:48, Marina Vatkina 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.
Great - we don't need email any more - its telepathy.
>
> 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.
Even better!
>
> 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