[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ejb-dev] [jakarta.ee-spec] Interceptors seems like a template spec
|
I missed one. Interceptors of an EJB can have injected and lookup all the same things that the EJB can have injected and look up. For example an Interceptor for an MDB can have `@Resource private MessageDrivenContext mdbContext;` injection and an interceptor of an EJB Session bean can have `@Resource private SessionContext sessionContext;` injection.
Additionally, EJBs have their own private java:comp/env/ namepsace which is completely isolated to it and not seen by other EJBs. Lets imagine we have a ColorInterceptor that looks up `java:comp/env/favorite/color` and expects a string. Because each EJB has its own namespace when ColorInterceptor intercepts a method call to BeanA it may get "Blue" as a result. When ColorInterceptor intercepts a call to BeanB it may get "Red" as a result.
There are tests to ensure that the interceptor of an EJB is seeing the same environment that exact EJB would see, both for dependency injection and lookup.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852
> On Aug 25, 2021, at 1:20 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
>
> EJB 3.0 introduced interceptors 3 years prior to CDI and there are naturally a lot of EJB-specific features and tests that should stay in the EJB section of the TCK and aren't used by CDI. Here's a list of the EJB-specific callbacks that can be intercepted:
>
> - @AfterBegin
> - @AfterCompletion
> - @BeforeCompletion
> - @PostActivate
> - @PrePassivate
> - @AroundTimeout
>
> There is also an EJB-specific mechanism for configuring interceptors in the ejb-jar.xml via `<interceptor-binding>`. The EJB spec defines three styles of binding:
>
> Style 1: Wildcard
>
> <interceptor-binding>
> <ejb-name>*</ejb-name>
> <interceptor-class>INTERCEPTOR</interceptor-class>
> </interceptor-binding>
>
> Style 2: By EJB name
>
> <interceptor-binding>
> <ejb-name>EJBNAME</ejb-name>
> <interceptor-class>INTERCEPTOR</interceptor-class>
> </interceptor-binding>
>
> Style 3: By EJB Name and Method name
>
> <interceptor-binding>
> <ejb-name>EJBNAME</ejb-name>
> <interceptor-class>INTERCEPTOR</interceptor-class>
> <method-name>METHOD</method-name>
> </interceptor-binding>
>
>
> Inside EJB's `<interceptor-binding>` element there are three other more complicated elements `<exclude-default-interceptors>`, `<exclude-class-interceptors>` and `<interceptor-order>`. There are specific rules over which binding should take precedence and win over other bindings, when things should be excluded and when the should not.
>
> There are annotation versions of all of the above; @Interceptors, @ExcludeDefaultInterceptors, @ExcludeClassInterceptors. I'm not aware of any CDI application of @ExcludeDefaultInterceptors or @ExcludeMethodInterceptors. It should also be explicitly noted that the EJB `<interceptor-binding>` element has no mapping or relationship with the @InterceptorBinding annotation introduced by CDI.
>
> EJBs `<interceptor-binding>` element maps to combinations of @Interceptors, @ExcludeDefaultInterceptors, @ExcludeClassInterceptors and so there are tests that verify if both xml and annotations are used in the same EJB application, the results are predictable and portable.
>
> There are also some differences in how the InvocationContext interface works between EJB and CDI. In EJB if the invocation occurred because the EJB was invoked as a JAX-WS endpoint the InvocationContext.getContextData() method will return the JAX-WS MessageContext. Additionally calls to InvocationContext.setParameters must be reflected in the SAAJ tree that represents the SOAP invocation. In EJB if the invocation occurred because of an EJB Timer the InvocationContext.getTimer() method will return that timer.
>
> There are also specific rules (oddly defined in the CDI spec, not the EJB spec) about which set of interceptors should should fire first. The rules are when an EJB is called and it has both EJB Interceptors and CDI interceptors, any interceptors defined via EJB mechanisms (ejb-jar.xml, the @Interceptors annotation) are invoked first and any interceptors defined via CDI interceptor mechanisms (@InterceptorBinding) are invoked second.
>
> The short version is, likely all the tests in the EJB section of the TCK that pertain to interceptors should stay right where they are.
>
> That said, some test and requirements moving should likely occur, but probably from CDI to EJB. I'll post about that separately as this is already long and few people will see it.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>
>> On Aug 25, 2021, at 10:18 AM, Scott Marlow <smarlow@xxxxxxxxxx> wrote:
>>
>> Please give input on the idea of moving some of the (EJB) Interceptors tests from the Platform TCK to the CDI TCK. From my quick look, I think that we have some Interceptors tests that could move to the CDI TCK. Would moving some of the Interceptor tests that also test EJB, create a problem for the Jakarta Enterprise Beans team? I think this would be limited to moving the Interceptors specific test groups (like https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/src/com/sun/ts/tests/ejb30/timer/interceptor).
>>
>> One possible reason against such a move is that the https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/src/com/sun/ts/tests/ejb30/timer/interceptor tests are not just testing Interceptors, as they are also testing EJB Timers with Interceptors. Still if the CDI team wants to maintain those tests, why note move them to the CDI TCK?
>>
>> Thanks,
>> Scott
>> -------- Forwarded Message --------
>> Subject: Re: [jakarta.ee-spec] Interceptors seems like a template spec
>> Date: Wed, 25 Aug 2021 11:52:46 -0400
>> From: Scott Marlow <smarlow@xxxxxxxxxx>
>> To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>, Scott Stark <starksm64@xxxxxxxxx>
>>
>>
>>
>>
>> On 8/25/21 10:43 AM, Scott Stark wrote:
>>> We were discussing @Interceptors in the CDI call and realized this project does not produce a TCK. It is another spec that is relies on the platform TCK:
>>>
>>> https://github.com/jakartaee/specifications/pull/233
>>>
>>> We also have many tests for this in the CDI TCK. This is a bad arrangement because it is one of the base api dependencies for CDI, and EJB. It would make more sense to have this in CDI and drop the platform tests and create a new standalone TCK from the existing CDI tests.
>> https://gist.github.com/scottmarlow/c3e518a64e786887c8c88c8a4ed46797 is a list of the Platform TCK tests that reference jakarta.interceptor classes. Within the EJB tests that use jakarta.interceptor, there is a subset that seem to be specifically for testing @Interceptors which seem to be contained in a `/interceptor/` test folder.
>>
>>
>>>
>>> Opinions on this?
>> I'm not personally against moving certain EJB/Interceptors tests to the CDI TCK but will ask for more input on Platform TCK ml + EJB SPEC ML.
>>
>>
>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jakarta.ee-spec mailing list
>>>
>>> jakarta.ee-spec@xxxxxxxxxxx
>>>
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
>> _______________________________________________
>> ejb-dev mailing list
>> ejb-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev
>
> _______________________________________________
> ejb-dev mailing list
> ejb-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev
