I think we can't dig too much into the details of what this API will look like until we understand the overall picture for the API. I would assume that:
* this new shared document will not make references back into the EJB spec or the EJB API
* that EJB needs to be backwards compat, so may have to expose both the new API and the old API as a wrapper (we didn't have this issue with interceptors as they were already in another package)
If this is the case, I think that the new API would need to define it's own exceptions, and EJB rebuild them. Not sure though, interested to see what concrete proposals come up.
On 27 Jun 2011, at 09:48, Carlo de Wolf wrote:
> Users won't expect a MB to throw EJBTransactionRolledbackException (for example), but they do expect the EJB to do that.
>
> It also means the EJB exceptions need to be available on the client CP. (Not that I mind, but I know a lot of people have a different opinion on this.)
>
> Carlo
>
> On 06/24/2011 11:59 PM, Marina Vatkina wrote:
>> Carlo,
>>
>> Can you please elaborate?
>>
>> thanks,
>> -marina
>>
>> Carlo de Wolf wrote:
>>> I'm curious to everybody's vision on exception handling in this light.
>>>
>>> I like the strict format of EJB exception handling, but this does expose EJBException and friends to the client.
>>>
>>> Carlo
>>>
>>> On 06/18/2011 02:27 AM, 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.
>>>> * 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.
>>>> * Re-factoring Message Driven Beans to enable message receivers in plain managed beans via CDI observers.
>>>> * Standardizing some common JMS activation properties as direct message listener attributes.
>>>>
>>>> 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...
>>>>
>>>> What do we think?
>>>>
>>>> Cheers,
>>>> Reza
>>>
>