Hi Marina,
Yes, you are right, we cannot break the compatibility between 3.1 and 3.2.
Going back the the need/question, cause it's interesting in my opinion.
As per the spec, nothing is inherited then, if we add an inherited
attribute (as for @ApplicationException since EJB 3.1). It could be false
by default to not break compatibility (@ApplicationException inherited
attribute is true by default).
It would allow to inherit a defined behavior in sub classes.
IMO, it makes sense. When you create a session bean, let's say a generic
session bean. You are the one who is able to say what's the behavior to
apply for transactions, etc. When you have to extend it, you should have to
know the rule and re-apply transaction attributes, security, etc.
Am i wrong?
From a design point of view and especially because of responsibilities, It
like to be able to do that (first Mark's case).
The second point is clear in my mind but could be clarified maybe by adding
some words to the previously named chapter (4.9.2.1 Session Bean
Superclass).
As we already say that no behavior is inherited by default in the sub
class. We could also mention that any behavior applied to the sub class
also applies to inherited methods.
If the user does not want such a behavior, he should only apply annotations
on methods not the sub class.
I don't think it breaks compatibility.
Lemme me know if that's absolutely stupid or if it could help.
Jean-Louis
2012/10/25 Marina Vatkina <marina.vatkina_at_oracle.com>
> Mark,
>
>
>
> Mark Struberg wrote:
>
>> Thanks Jean-Louis!
>>
>> I fear this does not play together nicely with CDI currently.
>>
>
> It means that CDI spec needs to follow EJB rules for EJBs (if not for all
> other CDI beans): we can't change inheritance behavior for backward
> compatibility - otherwise bean B will start behaving differently when
> deployed to a newer EJB container.
>
> Best,
> -marina
>
> AnnotatedType has just no inheritance information right now. We just
>> assume standard Java inheritance rules.
>>
>> Also please think about portable Extensions: how could you apply an
>> Interceptor dynamically to a scanned class? How would you tell the
>> container that you like to have the interceptor on the inherited methods as
>> well?
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>
>>
>>
>>> ______________________________**__
>>> From: Jean-Louis MONTEIRO <jeanouii_at_gmail.com>
>>> To: "users_at_ejb-spec.java.net" <users_at_ejb-spec.java.net> Sent:
>>> Wednesday, October 24, 2012 8:46 AM
>>> Subject: [ejb-spec users] Re: A small interceptor question
>>>
>>>
>>> Hi Mark,
>>>
>>> With EJBs the inheritance is pretty new. It was container specific
>>> before EJB 3.1. Since 3.1, there is now a chapter to deal with session
>>> beans inheritance. In the document EJB 3.2 core PD, the chapter is 4.9.2.1
>>> Session Bean Superclass.
>>>
>>> It's more or less clear that there is nothing inherited from super
>>> classes. For instance,
>>> "There are no special rules that apply to the processing of annotations
>>> or the deployment descriptor for this case."
>>> and
>>> "In this regard, the use of session bean classes as superclasses merely
>>> represents a convenient use of implementation inheritance but does not have
>>> component inheritance semantics."
>>>
>>> So I would say that even 1. is false.
>>> The @TransactionAttribute (not @Transactional for EJBs) does not have
>>> inherited attribute. AFAIR only ApplicationException has an inherited
>>> attribute but it only applies to exceptions not beans.
>>>
>>> In regards to the second question, I would answer yes, annotations in
>>> the subclass also apply to inherited methods.
>>>
>>> That's how EJBs work for now. No issue to discuss that and refine the
>>> behavior if possible.
>>>
>>> Jean-Louis
>>>
>>>
>>>
>>>
>>> 2012/10/18 Mark Struberg <struberg_at_yahoo.de>
>>>
>>> Dear EJB EG!
>>>
>>>
>>>> We have a small question over in the CDI EG and Apache DeltaSpike
>>>> regard interception of methods of a superclass.
>>>>
>>>> When dealing with multiple class hierarchies of intercepted classes
>>>> (@InterceptorBinding style for now) we have the 2 following use cases:
>>>>
>>>>
>>>> @Transactional
>>>> public class A {
>>>> public void methodA();
>>>> }
>>>>
>>>>
>>>> public class B extends A {
>>>> public void methodB();
>>>> }
>>>>
>>>> Question
>>>> 1: does the @Transactional interceptor get inherited and both methodA()
>>>> and methodB() get intercepted, or will only methodA() get intercepted?
>>>> Let's
>>>> assume the Transactional annotation itself is marked as inherited. Imo
>>>> it should, right? if @Transactional doesn't have @Inherited then methodB()
>>>> will not get intercepted, right?
>>>>
>>>>
>>>> And now for the other (bit more tricky) case:
>>>>
>>>> public class A {
>>>> public void methodA();
>>>> }
>>>>
>>>> @Transactional
>>>> public class B extends A {
>>>> public void methodB();
>>>> }
>>>>
>>>> Question
>>>> 2: does the @Transactional interceptor also affect inherited methods
>>>> and both methodA() and methodB() get intercepted, or will only methodB()
>>>> get intercepted? I found no clear answer in the interceptors spec.
>>>> From the gut feeling we think methodA() should get intercepted as well...
>>>>
>>>> Could you please point us to the paragraph where the behaviour got
>>>> defined?
>>>> I could only find paragraphs about inherited interceptors itself, but
>>>> not about inheritance behaviour of intercepted classes.
>>>>
>>>> Next question while I'm at it: the behaviour of @InterceptorBinding
>>>> style Interceptors and @Interceptors is the same regarding the scenarios
>>>> above?
>>>>
>>>>
>>>> Oh and btw, the next revision please with paragraph numbers - makes it
>>>> lot easiers to reference ;)
>>>>
>>>> txs and LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>