deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Sabot-Durand <anto...@sabot-durand.net>
Subject Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Date Sat, 31 Mar 2012 09:08:51 GMT
Gerhard,

I understand use case are a bit complex to explain. I'm preparing a university talk on Seam
social for Devoxx France on april 18th. I'll use this talk material to write a post on Genercis
during easter holiday. So we'll have a clearly explained use case on the subject.

Antoine SABOT-DURAND



Le 30 mars 2012 à 17:28, Gerhard Petracek a écrit :

> @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 <antoine@sabot-durand.net>
> 
>> 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 <antoine@sabot-durand.net>
>>>> 
>>>>> 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 <pmuir@redhat.com>
>> 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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message