Re: [webbeans-dev] Re: @Supports

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

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.