You are right Marina,
There is a different behavior if the inherited class is a component or a
simple class for EJB.
Not sure if that makes sense for CDI experts cause all classes (inherited
or not) should be managed (ie. seen as components).
Jean-Louis
2012/10/26 Marina Vatkina <marina.vatkina_at_oracle.com>
> Guys,
>
> I was wrong (sorry - shouldn't be rushing through): non-component-defining
> annotations are inherited by the subclass:
>
> 4.9.2 Session Bean Class
> "The session bean class may have superclasses and/or superinterfaces. If
> the session bean has superclasses, the business methods, lifecycle callback
> interceptor methods, the timeout callback methods, the methods implementing
> the optional session synchronization notifications,the Init or
> ejbCreate<METHOD> methods, the Remove methods, and the methods of the
> SessionBean interface, may be defined in the session bean class, or in any
> of its superclasses."
>
> The inheritance rule in 4.9.2.1Session Bean Superclasses applies only to
> the component definition. I.e. class B in Mark's example won't be an EJB
> unless it has e.g. @Stateless annotation (or an entry in the DD).
>
> Are we all fine now or is there anything that I missed?
>
> thanks,
> -marina
>
>
> Pete Muir wrote:
>
>> I think we have two options
>>
>> 1) We let interceptor binding work differently to @Interceptors, and
>> require it to apply interceptors to all types, not just the current type.
>> This would produce the best functionality for users
>> 2) We make interceptor binding work like @Interceptors, and then provide
>> a way to override this for the whole app or something
>>
>> I can think of few cases where the current design is actually most useful.
>>
>> On 25 Oct 2012, at 16:15, Mark Struberg wrote:
>>
>>
>>
>>> Hi folks!
>>>
>>> Thanks for taking a stab on this!
>>>
>>> A few small questions:
>>>
>>> 1.) I can see that the inheritance was not on by default in EJB
>>> @Interceptors
>>>
>>> 2.) I can not find any wording which defines that for any
>>> @InterceptorBinding interceptor. Do you have a paragraph reference for me?
>>> If there is no such thing yet, you might add a clarification please.
>>>
>>> The idea with the flag sounds fine, still we need to address this in the
>>> CDI spec.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>> ______________________________**__
>>>> From: Jean-Louis MONTEIRO <jeanouii_at_gmail.com>
>>>> To: marina.vatkina_at_oracle.com Cc: Mark Struberg <struberg_at_yahoo.de>; "
>>>> users_at_ejb-spec.java.net" <users_at_ejb-spec.java.net>; Pete Muir <
>>>> pmuir_at_redhat.com> Sent: Thursday, October 25, 2012 1:40 PM
>>>> Subject: [ejb-spec users] Re: A small interceptor question
>>>>
>>>>
>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>