[webbeans-dev] Re: @Supports

[Scott Ferguson]

On Nov 23, 2008, at 1:27 PM, Gavin King wrote:

>
> Imagine the classic "mixin" inheritance case. This would let me mixin
> two interfaces, and compose together one or more classes that
> implement those interfaces into a single class, without writing all
> those nasty degating methods, and having my code break when a new
> method is added to one of the interfaces.

Ok.  It's not related to JMS, but that's a conceivable webbeans feature.

>
>> Or if that auto-proxy generation is useful in itself, shouldn't it be
>> decoupled from the @Produces concept?
>
> Well, remember that @Composes is a *competing proposal* to @Prototype.

But the mixin problem (proxy mixin) is different from the JMS problem  
(tuple projection).  So they don't really compete, they are different  
problems.

> * @Composes *is* totally decoupled from @Produces
> * @Prototype doesn't have anything to do with proxying/delegation
>
> They're actually quite different features, that just happen to both
> provide a solution to a common problem: creating reusable classes that
> present a set of "identities" to clients.

But it's not a common problem.  Look at it from the perspective of  
Manager.getInstanceByType.  @Composes doesn't do the right thing for  
JMS.  For JMS, the returned objects need to be the real objects, not a  
mixin:

   Queue queue = manager.getInstanceByType(Queue.class);
   QueueSender sender = manager.getInstanceByType(QueueSender.class);

The queue and sender object need to be different, because the JMS  
provider would expect its own Queue, and methods like equals() need to  
work correctly.   Correspondingly,  manager.resolveByType(Queue.class)  
and resolveByType(QueueSender.class) would also return different Bean  
objects.

But @Composes returns a single instance from getInstanceByType and a  
single Bean from manager.resolveByType:

   Queue queue = manager.getInstanceByType(Queue.class);
   QueueSender sender = manager.getInstanceByType(QueueSender.class);

For @Composes, the queue and sender are the same object, and the Queue  
does not extend the JMS provider's Queue, it extends QueueEndpoint,  
which would be very confusing or useless to the JMS provider.  For  
@Composes, the Bean object for resolveByType is a single Bean with  
multiple types, not multiple Beans with a single type.

So, JMS needs something more like @Prototype, while a new mixin  
feature could use @Composes.

-- Scott

>
>
> -- 
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>
>