deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Muir <pm...@redhat.com>
Subject Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Date Tue, 06 Mar 2012 10:47:47 GMT
It's probably fair. They are certainly missing some things you might expect, that Antoine ran
into…

If we can find a way to create a similar extension capability but implemented differently,
it would be good. However what they offer is too useful to pass up.

You often have a situation where you want to create the effect of having a group of beans
for a multiple configurations of something. Injection of InjectionPoint can go some way to
solving this, but suffers from three key limitations. Let's first take an example problem
domain which I know well - caches, specifically Infinispan.

You obviously want to be able to configure multiple caches in an application, as they might
well have different characteristics, such as eviction policy, persistent storage, and so on.

Infinispan offers a number of caching classes associated with a cache - a Cache interface,
and an AdvancedCache interface, as well as the Configuration for the cache. We want to be
able to inject any of these objects for each cache configured. e.g.

@Inject @Cache("cache1") Cache cache;
@Inject @Cache("cache1") AdvancedCache cache;
@Inject @Cache("cache1") Configuration cache;

@Inject @Cache("cache2") Cache cache;
@Inject @Cache("cache2") AdvancedCache cache;
@Inject @Cache("cache2") Configuration cache;
 
The first problem we can see here is that we've lost type safety. This is quite easy to fix,
simply by having the user create an annotation per cache, which perhaps could be meta-annotated
with the name of cache. We now have (truncated for brevity!)

@Inject @Cache1 Cache cache;

However, now let's assume we are running in JavaSE, and we need to don't have something like
JNDI to look up the CacheManager in, every time we want to access a cache. We need to make
the beans that hold the cache reference application scoped. This is the first of the key problems
I identified above.

We could solve this by saying that the cache manager is stored in application scope, and the
cache is looked up each time, but it's also reasonable to assume that there can be multiple
cache managers in an application.

The second problem, is that we really still need a way to attach a configuration to a cache.
A producer method is an ideal way to do this (produce the configuration needed for the cache,
so that CDI can pass it to Infinispan at the right point), but we somehow need to associate
this producer method through, and have CDI know how to call this. Qualifiers of course solve
this.

Finally, we of course want this properly validated at startup, and we do know the entire system
at startup.

I hope that outlines some of the problems we wanted to solve with generic beans. Anyone have
a better idea how to solve this? I'm all ears :-D

On 4 Mar 2012, at 20:01, Mark Struberg wrote:

> I don't think it's correct to call them buggy. It's just that it might be _very_ hard
to provide the same behaviour over all our supported containers.
> But we will hit those kind of compat problems sooner or later anyway and will need to
find a way to deal with them.
> 
> 
> LieGrue,
> strub
> 
> 
> 
> ----- Original Message -----
>> From: Antoine Sabot-Durand <antoine@sabot-durand.net>
>> To: deltaspike-dev@incubator.apache.org
>> Cc: 
>> Sent: Sunday, March 4, 2012 8:38 PM
>> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
>> 
>> T hank you John to launch this subject. I've been very busy since january and 
>> didn't found time to launch the subject. To be totally honest I thought I 
>> was the only one interested in them.
>> 
>> Now regarding Generic beans in Solder : 
>> 
>> - documentation is quite inaccurate
>> - they are bugy : I didn't had bug, but it seems that some their tests 
>> don't pass
>> - I read some wrong information about them : you can't create beans in 
>> another scope that the generic bean definition.
>> 
>> I'll prepare a description of how I use them in Seam Social to ease 
>> extension of the framework and the issue I encounter using them.
>> 
>> regards,
>> 
>> 
>> Antoine SABOT-DURAND
>> 
>> 
>> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
>> 
>>> I think they're really powerful, but we may need to do some rewrite to 
>> make sure it works correctly in a modular container. 
>>> 
>>> Sent from my iPhone
>>> 
>>> On Mar 4, 2012, at 8:52, "John D. Ament" 
>> <john.d.ament@gmail.com> wrote:
>>> 
>>>> Hi All
>>>> 
>>>> I would like to begin discussing the use of Generic Beans from Solder
>>>> (currently this issue is assigned to Antoine, but I have some bandwidth 
>> and
>>>> offered to help him here).  This feature is used to configure a set of
>>>> related beans that require shared components, while still allowing 
>> scopes
>>>> to be provided.  This is useful when trying to make legacy 
>> libraries/APIs
>>>> CDI capable.  The following are the API components required for
>>>> GenericBeans:
>>>> 
>>>> - @GenericType(Class<?> clazz) - defines the type of 
>> configuration for the
>>>> generic.  This annotation is placed on another annotation, as defined 
>> by
>>>> the application developer or framework author to support how 
>> configuration
>>>> is resolved.  This will look for a matching bean of the given type and
>>>> resolve it based on the annotation that this is assigned to.
>>>> - @Generic - when using the manager type, defines an expected injection
>>>> point for a generic bean.
>>>> - @GenericConfiguration(Class<?> clazz) - defines the 
>> relationship between
>>>> generic objects.
>>>> - @ApplyScope - indicates that the produced object should inherit the 
>> scope
>>>> of the configuration.
>>>> 
>>>> 
>>>> The examples in the Solder documentation describe this in depth:
>>>> 
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>>>> 
>>>> Thoughts/questions on the feature?
>>>> 
>>>> john
>> 


Mime
View raw message