On 13 Aug 2009, at 20:02, Kenneth Saks wrote:
On Aug 13, 2009, at 2:32 PM, Pete Muir wrote:
>
> On 13 Aug 2009, at 18:12, Kenneth Saks wrote:
>
>>
>> On Aug 13, 2009, at 1:00 PM, Pete Muir wrote:
>>
>>>
>>> On 13 Aug 2009, at 17:03, Kenneth Saks wrote:
>>>
>>>>>> Let's add a web beans provided interceptor that the EJB
>>>>>> container
>>>>>>
>>
>>
>> 1. Is the Interceptor type in this signature a new kind of
>> descriptor? What information does
>> it hold?
>
> It's a CDI defined interface.
http://anonsvn.jboss.org/repos/webbeans/ri/trunk/api/src/main/java/javax/...
> - you could also use the create() method to make an instance.
>
>> 2. interceptors should be a List instead of a Collection since it
>> needs to
>> convey the ordering.
>
> Yes, my bad.
>
>> Does the CDI-specified interceptor metadata
>> allow method-level
>> granularity for @AroundInvoke? If so, a single ordered list of
>> interceptor classes isn't
>> sufficient.
>
> Yes. Can you propose an alternative structure, as I guess you have a
> similar structure in EJB?
That means we'll need both component-level and per-method lists. I
don't see
the benefit of this approach. Why not just register a single CDI
impl interceptor
that knows about all the CDI-specific application interceptors? The
ejb container
will register it in the right place in the chain and it can delegate
all the
@PostConstruct , @AroundInvoke, etc. methods appropriately. If the
interceptor instance
itself needs some context we can agree on a constructor argument
such as
EjbDescriptor.
I don't see why this approach prohibits that implementation.
Rather than using an internal API to transfer the needed interceptors
from the EnterpriseBean instance to the EJB interceptor, we make this
a public SPI, thus allowing an integrator the flexibility to choose
how to add these interceptors to the stack.
ALR, Carlo, any comment. Which do you guys prefer?