No worries Marina. If the answer would have been glass clear then we wouldn't have asked ;)
JL: I'm not sure this is 100% to the point. Does it depend on 'annotation is EJB component definition annotation' or 'annotation is ON an EJB component'? Those are 2 fundamentally different things, right?
Oki, here are my thoughts:
A CDI Bean is not an EJB but an EJB is always a 'aware of CDI features'. What I mean is that EJBs since ejb-3.1 can use all features defined in CDI as well. What will happen with CDI features used on those EJBs? Will they follow CDI rules or EJB rules? Or don't we have a mismatch at all and it's not depending on the Bean but the applied feature?
LieGrue,
strub
>________________________________
> From: Jean-Louis MONTEIRO <jeanouii_at_gmail.com>
>To: marina.vatkina_at_oracle.com
>Cc: users_at_ejb-spec.java.net
>Sent: Friday, October 26, 2012 8:45 AM
>Subject: [ejb-spec users] Re: A small interceptor question
>
>
>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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>
>
>
>