Yes, we need a new name for the feature, generic beans isn't good ;-) I'm not sure Bean Groups is right, any other ideas?
On 7 Mar 2012, at 02:13, John D. Ament wrote: > @pete > > Reminds me of the JMS issue we have. > > So I suppose - could we rename the feature - "Bean Groups" ? Then describe > the feature more along the lines of "the ability to define a bean that > contains producers that inherit the qualifiers of the existing injection > point. > > John > > On Tue, Mar 6, 2012 at 5:47 AM, Pete Muir <[email protected]> wrote: > >> 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 <[email protected]> >>>> To: [email protected] >>>> 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" >>>> <[email protected]> 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 >>>> >> >>
