@antoine: i know - i was talking about using std. cdi mechanisms without introducing a whole new approach in between. however, for sure i'm ok with discussing this feature. we can have a look at the current usage and possible alternatives.
maybe it's easier to start with the usage in infinispan. @pete: it would be great, if you can describe the details. regards, gerhard 2012/3/30 Antoine Sabot-Durand <[email protected]> > Gerahrd, > > I understand what you. Generic Beans are based on standard CDI as all > extension we are doing in DS. Before using them I had a lot of extension > to deal with my need. Generic Beans in seam social makes dev save about 50 > lines of oct for each OAuth Application declared(should it be only one for > each SN, it's already more than 50). It's a great helper. I'm not sure of > how the feature is used in Infinispan but it looks like the same need. > > CDI is strong typed and it's good but having a smart extension that can > produce a bunch of bean with different scope and unknown qualifiers at > compile time brings a dynamic aspect without forgetting the strong typed > aspect. > > I'd be pleased if you have a look at Seam social[1] and see how they are > used. So you could take half time to tell me how to do without them (but I > already now, since I did without them before) and half time to see the > potential of Generics. > > regards > > > Antoine > [1] http://github.com/seam/social > > > Le 30 mars 2012 à 14:01, Pete Muir a écrit : > > > Hi Gerhard, > > > > Do you have some examples of configuring a "family of beans" in MyFaces > CODI, where the family can be easily reused for different, coexisting, > services? This would be very helpful so that we can see how CODI achieved > this. > > > > pete > > > > On 30 Mar 2012, at 12:53, Gerhard Petracek wrote: > > > >> hi antoine, > >> > >> a lot of parts of myfaces codi are also customizable (easily) and almost > >> all of them are based on std. cdi mechanisms. > >> > >> if the social module has special requirements, we can discuss the > >> alternatives. > >> if a std. based approach requires just a bit more effort to support new > >> social services, it's ok imo because you don't have to do it that often. > >> > >> regards, > >> gerhard > >> > >> > >> > >> 2012/3/30 Antoine Sabot-Durand <[email protected]> > >> > >>> So what's next on "Bean Familiy Producer" ? > >>> > >>> They are used in infinispan cdi [1] and Seam Social [2]. > >>> In both case they are used to provide pug ability with unknown > >>> implementation (I Can create a new Cache module with a new technology > or I > >>> can create a new Social Network Module for the last Twitter in town) > >>> > >>> So we agree it's mainly a framework development need to avoid users to > >>> have to create a bunch of producers when they extend the framework. > >>> > >>> As it's used to produce beans they can be in different scope or merit > >>> dynamically of master bean scope. > >>> > >>> To make it short : it seems rather useful even if the use cases are > narrow. > >>> > >>> Does anybody have questions, objections ? Should we go for a vote ? > >>> > >>> > >>> [1] > >>> > https://github.com/infinispan/infinispan/blob/master/cdi/extension/src/main/java/org/infinispan/cdi/AdvancedCacheProducer.java > >>> [2] > >>> > https://github.com/seam/social/blob/develop/impl/src/main/java/org/jboss/seam/social/oauth/OAuthGenericManager.java > >>> > >>> Antoine SABOT-DURAND > >>> > >>> > >>> > >>> Le 9 mars 2012 à 17:32, Pete Muir a écrit : > >>> > >>>> I quite like Bean Family Producer actually. > >>>> > >>>> On 9 Mar 2012, at 08:54, Antoine Sabot-Durand wrote: > >>>> > >>>>> 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 > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>> > > > >
