@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 > >> > >
