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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>
>
>