[webbeans-dev] Re: @Supports

[Scott Ferguson]

On Nov 23, 2008, at 9:35 AM, Gavin King wrote:

> If we did decide to go down this first path, instead of the
> alternative @Prototype path, I would probably call the annotation
> @Composes and the feature "composition".
>
> I would also let you have the Web Bean actually implement the
> interfaces and be declared abstract, for example:
>
>   @ApplicationScoped
>   public abstract class QueueEndpoint
>           implements Queue, QueueSession, QueueSender,  
> QueueConnection {
>       ....
>
>       @Composes Queue getQueue() { ... }
>       @Composes QueueSession getQueueSession() { ... }
>       @Composes QueueSender getQueueSender() { ... }
>       @Composes QueueConnection getQueueConnection() { ... }
>
>       void close() { throw new UnsupportedOperationException(); }
>
>   }

Why does QueueEndpoint implement any interfaces?  That looks like an  
implementation detail that doesn't need to be exposed to the users.

-- Scott

>
>
> (I like this, it reads very nicely.)
>
> On Fri, Nov 14, 2008 at 2:58 PM, Gavin King <gavin at hibernate.org>  
> wrote:
>> I've been thinking about the problem of implementing re-usable
>> components like our JMS endpoints. What I'm trying to do is implement
>> the requirements of JMS endpoints as a simple Web Bean. To do that
>> today, I would need to create a class which implemented all the API
>> types:
>>
>>   @ApplicationScoped
>>   public class QueueEndpoint
>>       implements Queue, QueueSession, QueueSender, QueueConnection  
>> { ... }
>>
>> and I would have to go and implement every one of the operations of
>> each of those interfaces to delegate to the correct object. (A bunch
>> of tedious code.)
>>
>> However, if we assume that the client proxy is smart enough, we could
>> let the Web Bean manager automagically do that delegation for us. We
>> would need a new annotation that could be applied to fields or
>> methods, for example:
>>
>>   @ApplicationScoped
>>   public class QueueEndpoint  {
>>       ...
>>
>>       @Supports Queue getQueue() { ... }
>>       @Supports QueueSession getQueueSession() { ... }
>>       @Supports QueueSender getQueueSender() { ... }
>>       @Supports QueueConnection getQueueConnection() { ... }
>>
>>   }
>>
>> We no longer need to write all those annoying delegation methods! The
>> client proxy would just call the correct @Supports method when the
>> QueueEndpoint type did not define the method that was  invoked by the
>> client, and delegate the method to the returned object.
>>
>> To make this really work, we would need to say:
>>
>> * the set of API types of the Web Bean includes all types of  
>> @Supports
>> methods/fields
>> * if a certain method name appears on more than one @Supports
>> method/field type, it must also be implemented directly by the impl
>> class
>> * if a certain method name appears on more than one @Supports
>> method/field type, or on both the impl class and a @Supports
>> method/field type, it is always called on the impl class
>>
>> Therefore, close() would need to be implemented by QueueEndpoint:
>>
>>   @ApplicationScoped
>>   public class QueueEndpoint  {
>>       ...
>>
>>       @Supports Queue getQueue() { ... }
>>       @Supports QueueSession getQueueSession() { ... }
>>       @Supports QueueSender getQueueSender() { ... }
>>       @Supports QueueConnection getQueueConnection() { ... }
>>
>>       void close() { throw new UnsupportedOperationException(); }
>>
>>   }
>>
>> You're probably thinking that we can do all this with @Producer
>> methods, however, the semantics are not exactly the same, since the
>> association b/w the producer object and produced object is lost as
>> soon as the producer method returns. Furthermore, @Producer methods
>> aren't really appropriate for 3rd-party reusable objects, since the
>> XML configuration of a producer method is verbose.
>>
>> I don't believe that Web Beans 1.0 absolutely has to have this
>> feature, but I know its useful, and I know that we will implement it
>> in the RI, so I would prefer if it was portable. What do you guys
>> think? Useful? Too much magic? Let me know...
>>
>> Seam already has an extremely primitive/braindead version of this
>> feature, that I've found *extremely* useful when writing reusable
>> components:
>>
>> http://docs.jboss.com/seam/2.1.0.SP1/reference/en-US/html/concepts.html#d0e4283
>>
>> (@Factory is more or less like @Produces, whereas @Unwrap is a really
>> crappy version of @Supports.)
>>
>> --
>> Gavin King
>> gavin.king at gmail.com
>> http://in.relation.to/Bloggers/Gavin
>> http://hibernate.org
>> http://seamframework.org
>>
>
>
>
> -- 
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>
>