What about "Bean Family" or "Bean Family Producer" ?
Antoine SABOT-DURAND Le 7 mars 2012 à 16:55, Pete Muir a écrit : > 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 >>>>> >>> >>> >
