deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Date Fri, 30 Mar 2012 15:28:53 GMT
@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