[webbeans-dev] Creating instances of managed beans (including EJBs) in EE6 (was Re: non-contextual managed bean creation)

Pete Muir pmuir at redhat.com
Thu Aug 13 15:11:18 EDT 2009


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/enterprise/inject/spi/Interceptor.java
>> - 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?



More information about the weld-dev mailing list