Hi Marina!
Yes, if all agree that adding an interceptor to a subclass will also cause the methods in the parent class to get intercepted, then my question is answered. It would be good to explicitly list the intended rules in the interceptors spec.
We only started talking about component definition annotations because they give an indirect answer to my question.
LieGrue,
strub
----- Original Message -----
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: Mark Struberg <struberg_at_yahoo.de>
> Cc: "users_at_ejb-spec.java.net" <users_at_ejb-spec.java.net>
> Sent: Tuesday, October 30, 2012 1:19 AM
> Subject: [ejb-spec users] Re: A small interceptor question
>
> Mark, Alex,
>
> Can one of you file a JIRA issue?
>
> Mark,
>
> I'm a bit lost - your original question didn't seem to be about possible
> errors if component defining annotations do not match... Is the warning/error
> about component mismatch in an EJB class hierarchy the only outstanding issue?
>
> thanks,
> -marina
>
> Mark Struberg wrote:
>> Hi Alex!
>>
>> Thanks for your response!
>>
>> Yes, that is exactly what I meant with the 'behaviour' caused by
> different annotations. For now let's just look at classic EJB-3.1
> annotations and leave aside all CDI stuff.
>>
>> Imo it would be perfectly fine if 'component declaring annotations'
> will not get inherited. At least not if they don't have an @Inherited
> meta-annotations. And @Stateless, @Stateful etc don't have this
> meta-annotation, right? What other of those 'component declaring
> annotations' are there?
>>
>> For the rest of the annotations (especially @Interceptors on a method in
> the superclass) EJB also inherits the behaviour defined in the superclass? That
> would perfectly match what CDI containers do atm afaik.
>>
>>
>>
>> Now let's take CDI into account as well: The CDI default scopes are all
> marked as @Inherited. What if a baseclass is marked as @SessionScoped ad the
> sub-class is @Stateful? What will the subclass end up with?
>> Note: From a CDI perspective I don't care much, but it should be well
> defined for EJBs.
>>
>> txs and LieGrue,
>> strub
>>
>> PS: sorry for always asking such bad questions ;)
>>
>>
>>
>> ----- Original Message -----
>>
>>> From: "asbriglio_at_cesi.fr" <asbriglio_at_cesi.fr>
>>> To: users_at_ejb-spec.java.net
>>> Cc: Sent: Sunday, October 28, 2012 6:00 PM
>>> Subject: [ejb-spec users] Re: A small interceptor question
>>>
>>> Hi everybody,
>>> I fear I have not quite understood what you mean by « There is a
>>> different behavior if the inherited class is a component or a simple
> class for EJB.” In fact what do you mean by “behavior” ?
>>> What I have understood from the spec is :
>>> Annotations configuring the component type and clients views declared
>>> in a session bean super class are not inherited in a subclass :
>>> annotations and interfaces has to be specified for the subclass for it
>>> to be considered has a session bean (spec 4.9.2.1 of the EJB 3.2 spec).
>>> There is no component inheritance semantic But configurations of
> container services specified in a super class
>>> (basic class or session bean superclass) are inherited by a session
>>> bean subclass following specific rules (ie. Transaction [8.3.7 ] and
>>> security[12.3.2.1]. There is an implementation inheritance semantic.
>>> Is this that what you mean ?
>>> Note that test under GlassFish tend to confirm these two assertions
>>> For the interception case, I’m quite OK with what you.
>>> Anyway it would be a good thing if you precise a little more in the
> 4.9.2.1part to avoid confusion.
>>> In the case I have well understood the two upper assertions, there is
>>> another point who is worried me: the fact that a super component could
>>> be declared as a Stateful , and a subcomponent as a Stateless which
>>> could lead to strange behavior. If I don’t mistake, there is nothing
>>> written in the spec about this. What if the child access to the parent
>>> conversational state?
>>> In the case of a session bean class deriving from a session bean
>>> superclass, you should maybe add a warning who states that a session
>>> bean subcomponent type should be of the type of the super component or
>>> a type having a wider scope. That is a stateless session bean should
>>> not inherit from a stateful or singleton session bean.
>>> Regards,
>>> Alex
>>>
>>>
>