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 Fri, 30 Mar 2012 12:21:56 GMT
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