[cdi-dev] Producer#dispose(T instance) and similar
Pete Muir
pmuir at redhat.com
Fri Dec 14 08:15:37 EST 2012
Basically agreed, we just have to work out how we sanitize this and preserve backwards compat.
On 14 Dec 2012, at 08:29, Mark Struberg wrote:
> back to the original topic.
>
> The weird thing for me is that
>
> * the Bean<T> has all the important information e.g the Scope, the Stereotypes, etc
>
> * both Bean<T> and Producer<T> have getInjectionPoints()
>
> * If the Producer<T> is intended to create the proxies, then we would store them directly in the Contexts. But then you don't have access to private methods anymore if the container has no info about proxy internas. Remember that the EJB and Interceptors spec require _proxying_ (delegation) and not subclassing!
>
> * Otoh if the Producer<T> creates the proxies and stores them 'anonymously' in the CreationalContext, then all other mechanics which needs this info don't work. Please note that e.g. interceptors on Decorators need to get 'moved out' of the decorator and be executed before all other decorator calls.
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Pete Muir <pmuir at redhat.com>
>> To: Mark Struberg <struberg at yahoo.de>
>> Cc: Arne Limburg <arne.limburg at openknowledge.de>; cdi-dev <cdi-dev at lists.jboss.org>
>> Sent: Thursday, December 13, 2012 4:55 PM
>> Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar
>>
>>
>> On 12 Dec 2012, at 11:46, Mark Struberg wrote:
>>
>>> Yes, to get this summed up what seems to have been the intended way:
>>>
>>> A CDI annotated class is a 'Managed Bean' which is one kind of
>> Bean<T>
>>>
>>> A producer method and producer field is also a Bean<T> but not
>> referred to as 'Managed Bean' in the spec.
>>
>> +1
>>
>>>
>>>
>>> And this is different to what we did read and interpret/implement in OWB:
>>> * each Bean<T> has general features and the definitions for certain
>> bean types (producer methods, producer fields, etc) 'specialize' this
>> base behaviour.
>>>
>>> e.g. in OWB all @NormalScoped beans are treated the same and get
>> interceptors and decorators. Regardless whether they came from scanning a class
>> or returned by a producer method or field.
>>
>> Mark and I discussed this specific one on IRC. Interceptors and decorators are
>> not required to be supported for producer methods or fields. However it is not
>> disallowed either :-)
>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Arne Limburg <arne.limburg at openknowledge.de>
>>>> To: Mark Struberg <struberg at yahoo.de>; Pete Muir
>> <pmuir at redhat.com>
>>>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>>>> Sent: Wednesday, December 12, 2012 8:50 AM
>>>> Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar
>>>>
>>>> And a short addition: The introduction of chapter three suggests that a
>>>> producer method IS a bean...
>>>>
>>>>
>>>> Am 12.12.12 08:46 schrieb "Arne Limburg" unter
>>>> <arne.limburg at openknowledge.de>:
>>>>
>>>>> Hi Mark,
>>>>> Hi Pete,
>>>>>
>>>>> From reading the spec literally I must admit that Pete seems to be
>> right
>>>>> and the returned object of a producer method is not a
>> "bean" in
>>>> the sense
>>>>> of the spec. But then there are MANY parts of the spec where we
>> MUST
>>>>> clarify the usage of the term "bean", because they apply
>> to the
>>>> result of
>>>>> a producer method, too. AND for a producer method there is a
>> Bean<T>
>>>>> object available (The ProcessBean event is fired, see 11.5.11)
>> which is
>>>>> confusing, if the returned object is not a "bean".
>>>>>
>>>>> And my last point: The definition as Pete understands it, would
>> result in
>>>>> very unexpected behavior. Consider the following producer method:
>>>>>
>>>>> @Produces
>>>>> @MyStereotype
>>>>> public MyObject produce() {
>>>>> ...
>>>>> }
>>>>>
>>>>>
>>>>> And the following stereotype:
>>>>>
>>>>> @Stereotype
>>>>> @RequestScoped
>>>>> @CustomQualified
>>>>> @CustomIntercepted
>>>>> public @interface MyStereotype {}
>>>>>
>>>>> where the @CustomQualified and @CustomIntercepted annotations are a
>>>>> qualifier and an interceptor binding.
>>>>> The resulting object would have @RequestScoped and @CustomQualified
>>>>> applied, but not @CustomIntercepted... How would we explain that to
>> our
>>>>> users?
>>>>> This behavior is not so clear in CDI 1.0, but would become clearer
>> in CDI
>>>>> 1.1.
>>>>> We should definitely change some clarifications in another
>> direction.
>>>>> Have not looked at Decorators and produced objects, but I guess
>> there are
>>>>> many things to be clarified, too…
>>>>>
>>>>> Just my two cent,
>>>>> Cheers,
>>>>> Arne
>>>>>
>>>>> Am 11.12.12 18:58 schrieb "Mark Struberg" unter
>>>> <struberg at yahoo.de>:
>>>>>
>>>>>> so a producer method in Weld does not result in a Bean<T>
>> and is
>>>> not
>>>>>> being returned by BeanManager#getBeans() ?
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: Pete Muir <pmuir at redhat.com>
>>>>>>> To: Mark Struberg <struberg at yahoo.de>
>>>>>>> Cc: Arne Limburg <arne.limburg at openknowledge.de>;
>> cdi-dev
>>>>>>> <cdi-dev at lists.jboss.org>
>>>>>>> Sent: Tuesday, December 11, 2012 4:11 PM
>>>>>>> Subject: Re: [cdi-dev] Producer#dispose(T instance) and
>> similar
>>>>>>>
>>>>>>> Agreed, managed bean is a well defined term:
>>>>>>>
>>>>>>> " 3.1. Managed beans
>>>>>>>
>>>>>>> A managed bean is a bean that is implemented by a Java
>> class."
>>>>>>>
>>>>>>> So I'm pretty sure producers aren't managed beans.
>>>>>>>
>>>>>>>
>>>>>>> On 11 Dec 2012, at 16:07, Mark Struberg wrote:
>>>>>>>
>>>>>>>> Actually I cannot read this restriction from the old
>> wording.
>>>> Please
>>>>>>>> note
>>>>>>> that the terminus 'managed bean' is well defined
>> and any
>>>> producer
>>>>>>> method
>>>>>>> is a 'managed bean' as well as explicitly defined
>> in the
>>>> spec. This is
>>>>>>> not restricted to managed beans which are just classes imo.
>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: Pete Muir <pmuir at redhat.com>
>>>>>>>>> To: Mark Struberg <struberg at yahoo.de>
>>>>>>>>> Cc: Arne Limburg
>> <arne.limburg at openknowledge.de>;
>>>> cdi-dev
>>>>>>> <cdi-dev at lists.jboss.org>
>>>>>>>>> Sent: Monday, December 10, 2012 1:37 PM
>>>>>>>>> Subject: Re: [cdi-dev] Producer#dispose(T
>> instance) and
>>>> similar
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 7 Dec 2012, at 22:06, Mark Struberg wrote:
>>>>>>>>>
>>>>>>>>>> Well, that restriction got only introduced
>> with
>>>> CDI-1.1.
>>>>>>>>>
>>>>>>>>> CDI 1.0 didn't require an impl to support
>> this. To
>>>> quote:
>>>>>>>>>
>>>>>>>>> "Interceptor bindings may be used to
>> associate
>>>> interceptors with
>>>>>>> any
>>>>>>>>> managed bean that is not itself an interceptor or
>> decor-
>>>> ator or
>>>>>>>>> with
>>>>>>> any EJB
>>>>>>>>> session or message-driven bean."
>>>>>>>>>
>>>>>>>>> "Decorators may be associated with any
>> managed bean
>>>> that is not
>>>>>>> itself an
>>>>>>>>> interceptor or decorator or with any EJB session
>>>> bean."
>>>>>>>>>
>>>>>>>>> The restriction was just making it explicit,
>> because
>>>> people thought
>>>>>>>>> it
>>>>>>> should
>>>>>>>>> work.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I've not noticed that, what was the
>> reason? There
>>>> is no
>>>>>>> technical
>>>>>>>>> necessity to do that imo!
>>>>>>>>>
>>>>>>>>> Maybe, but that isn't the way the spec is
>> written in
>>>> 1.0 :-) We can
>>>>>>> change
>>>>>>>>> it for sure, but it's a feature request.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I can see that for
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> @Produces @Transactional User getUser() {..}
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> it is ambiguous whether the @Transactional
>> interceptor
>>>> should
>>>>>>> account for
>>>>>>>>> the method invocation or the produced bean.
>>>>>>>>>> But as Arne pointed out it is in CDI-1.0 very
>> clear
>>>> what should
>>>>>>> happen with
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> @Produces @MyInterceptedStereotype User
>> getUser() {}
>>>>>>>>>>
>>>>>>>>>> Should we reopen CDI-59?
>>>>>>>>>>
>>>>>>>>>> LieGrue,
>>>>>>>>>> strub
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: Pete Muir <pmuir at redhat.com>
>>>>>>>>>>> To: Arne Limburg
>>>> <arne.limburg at openknowledge.de>
>>>>>>>>>>> Cc: Mark Struberg
>> <struberg at yahoo.de>;
>>>> cdi-dev
>>>>>>>>> <cdi-dev at lists.jboss.org>
>>>>>>>>>>> Sent: Wednesday, December 5, 2012 4:55 PM
>>>>>>>>>>> Subject: Re: [cdi-dev] Producer#dispose(T
>>
>>>> instance) and similar
>>>>>>>>>>>
>>>>>>>>>>> Hey Arne,
>>>>>>>>>>>
>>>>>>>>>>> No, they can't :-) It's
>> specifically
>>>> called out in
>>>>>>> Chapter 8
>>>>>>>>> and Chapter
>>>>>>>>>>> 9 that decorators and interceptors
>> aren't
>>>> applied to the
>>>>>>> result of
>>>>>>>>> producer
>>>>>>>>>>> methods.
>>>>>>>>>>>
>>>>>>>>>>> Pete
>>>>>>>>>>>
>>>>>>>>>>> On 5 Dec 2012, at 14:47, Arne Limburg
>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Pete,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> A little of topic and I don't
>> want to
>>>> disturb your
>>>>>>> discussion,
>>>>>>>>> but:
>>>>>>>>>>>>
>>>>>>>>>>>> Beans produced by producer methods
>> CAN have
>>>> interceptors as
>>>>>>>
>>>>>>>>> stereotypes
>>>>>>>>>>>> are supported on producer methods.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Arne
>>>>>>>>>>>>
>>>>>>>>>>>> Am 04.12.12 17:46 schrieb "Pete
>>>> Muir" unter
>>>>>>>>>>> <pmuir at redhat.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Mark, I'll try to answer
>> inline,
>>>> but I'm
>>>>>>> missing a
>>>>>>>>> bit of
>>>>>>>>>>> background
>>>>>>>>>>>>> about what you are doing...
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4 Dec 2012, at 14:20, Mark
>> Struberg
>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Another problem probably
>> being an
>>>> interceptor on
>>>>>>> the
>>>>>>>>> @Disposes
>>>>>>>>>>> method
>>>>>>>>>>>>>> itself.
>>>>>>>>>>>>>> Where does the
>> Proucer#dispose(T
>>>> instance) get the
>>>>>>>>> interceptor
>>>>>>>>>>> from?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>>> From: Mark Struberg
>>>> <struberg at yahoo.de>
>>>>>>>>>>>>>>> To: cdi-dev
>>>> <cdi-dev at lists.jboss.org>
>>>>>>>>>>>>>>> Cc:
>>>>>>>>>>>>>>> Sent: Tuesday, December
>> 4, 2012
>>>> 3:16 PM
>>>>>>>>>>>>>>> Subject: [cdi-dev]
>>>> Producer#dispose(T instance)
>>>>>>> and
>>>>>>>>> similar
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm currently
>> stumbling over
>>>> implementing
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Producer#dispose(T
>> instance)
>>>> properly
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The
>>>> Producer#produce(CreationalContext)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> has the CreationalContext
>>
>>>> parameter but the
>>>>>>> dispose
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, it would have been good to
>> have
>>>> included it
>>>>>>> here.
>>>>>>>>> I'm not
>>>>>>>>>>> sure why
>>>>>>>>>>>>> it wasn't, however I
>> don't believe
>>>> that it
>>>>>>> causes a
>>>>>>>>> problem
>>>>>>>>>>> with the CDI
>>>>>>>>>>>>> 1.0 spec, but just limits us
>> going
>>>> forward.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> and others do not have
>> it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Problem here is that a
>> Producer
>>>> could probably
>>>>>>> get
>>>>>>>>> exchanged
>>>>>>>>>>> via a
>>>>>>>>>>>>>>> portable
>>>>>>>>>>>>>>> extension via
>>>>>>> ProcessProducer#setProducer(Producer)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, this is definitely supported
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> so it could be from a
>>>>>>>>>>>>>>> foreign source which must
>> not know
>>>> anything
>>>>>>> about
>>>>>>>>> container
>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>> details.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think the critical part of the
>> spec to
>>>> understand
>>>>>>> this is
>>>>>>>>> 11.2.
>>>>>>>>>>> I'm
>>>>>>>>>>>>> quoting here from the CDI 1.1
>> spec, into
>>>> which we have
>>>>>>> add the
>>>>>>>>>>>>> clarification that "The
>> instance
>>>> returned by
>>>>>>> produce() may
>>>>>>>>> be a
>>>>>>>>>>> proxy.".
>>>>>>>>>>>>> The part about building
>> interceptors and
>>>> decorators is
>>>>>>> there in
>>>>>>>>> CDI
>>>>>>>>>>> 1.0.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> For a Producer that
>> represents a
>>>> class:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> € produce() calls the
>> constructor
>>>> annotated
>>>>>>> @Inject if
>>>>>>>>> it
>>>>>>>>>>> exists, or
>>>>>>>>>>>>>> the constructor with no
>> parameters
>>>> otherwise, as
>>>>>>> defined in
>>>>>>>>>>>>>> [instantiation], and returns
>> the
>>>> resulting
>>>>>>> instance. If the
>>>>>>>>> class
>>>>>>>>>>> has
>>>>>>>>>>>>>> interceptors,produce() is
>> responsible
>>>> for building
>>>>>>> the
>>>>>>>>> interceptors
>>>>>>>>>>> and
>>>>>>>>>>>>>> decorators of the instance.
>> The
>>>> instance returned
>>>>>>> by
>>>>>>>>> produce() may
>>>>>>>>>>> be a
>>>>>>>>>>>>>> proxy.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> € dispose() does
>> nothing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> and
>>>>>>>>>>>>>
>>>>>>>>>>>>>> For a Producer that
>> represents a
>>>> producer method or
>>>>>>> field:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> € produce() calls the
>> producer
>>>> method on, or
>>>>>>> accesses
>>>>>>>>> the
>>>>>>>>>>> producer
>>>>>>>>>>>>>> field of, a contextual
>> instance of the
>>>> bean that
>>>>>>> declares
>>>>>>>>> the
>>>>>>>>>>> producer
>>>>>>>>>>>>>> method, as defined in
>> [methods].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> € dispose() calls the
>> disposer
>>>> method, if any,
>>>>>>> on a
>>>>>>>>> contextual
>>>>>>>>>>>>>> instance of the bean that
>> declares the
>>>> disposer
>>>>>>> method, as
>>>>>>>>> defined
>>>>>>>>>>> in
>>>>>>>>>>>>>> [methods], or performs any
>> additional
>>>> required
>>>>>>> cleanup, if
>>>>>>>>> any, to
>>>>>>>>>>>>>> destroy state associated with
>> a
>>>> resource.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now, let me start to break down
>> your
>>>> sentence :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What now about having an
>>>> interceptor on
>>>>>>> @PreDestroy?
>>>>>>>>>>>>>
>>>>>>>>>>>>> For a start, it's worth
>> remembering
>>>> interceptors
>>>>>>> can only
>>>>>>>>> be
>>>>>>>>>>> associated
>>>>>>>>>>>>> with beans defined by a class. If
>> the bean
>>>> is a
>>>>>>> producer, then
>>>>>>>>> you
>>>>>>>>>>> can't
>>>>>>>>>>>>> intercept the instance produced
>> (only the
>>>> invocation of
>>>>>>> the
>>>>>>>>> producer).
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is what you get if
>>>>>>>>>>>>>>> your interceptor has
>> a at PreDestroy
>>>> method
>>>>>>> himself as per
>>>>>>>>> the
>>>>>>>>>>>>>>> interceptors and EJB
>>>>>>>>>>>>>>> specs. That would mean
>> that the
>>>> instance passed
>>>>>>> to
>>>>>>>>> dispose()
>>>>>>>>>>> whould be
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> proxy? That purely sounds
>> wrong to
>>>> me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Based on my comment from above, I
>> think
>>>> it's clear
>>>>>>> that
>>>>>>>>> dispose()
>>>>>>>>>>> should
>>>>>>>>>>>>> never try to invoke predestroy
>> methods.
>>>> That is the job
>>>>>>> of
>>>>>>>>>>>>> InjectionTarget.preDestroy(). I
>> would
>>>> expect a proxy to
>>>>>>> be
>>>>>>>>> passed to
>>>>>>>>>>>>> preDestroy().
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Another issue being
>>>>>>> InjectionTarget#postConstruct()
>>>>>>>>> only having
>>>>>>>>>>> the
>>>>>>>>>>>>>>> instance T
>>>>>>>>>>>>>>> as well. Now what about
>>>> @PostConstruct
>>>>>>> interceptors as
>>>>>>>>> defined
>>>>>>>>>>> in the
>>>>>>>>>>>>>>> interceptors spec?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Again, I would expect a proxy to
>> be passed
>>>> to
>>>>>>> postConstruct().
>>>>>>>>> Anyway,
>>>>>>>>>>>>> I'm not sure why you need
>> access to
>>>> the creational
>>>>>>> context
>>>>>>>>> in the
>>>>>>>>>>>>> postConstruct()? Here you should
>> just
>>>> invoke the
>>>>>>> postConstruct
>>>>>>>>>>> callback,
>>>>>>>>>>>>> which should create any new
>> dependent
>>>> objects.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Currently we have a dirty
>> hack in
>>>> OWB to pass
>>>>>>> over the
>>>>>>>>>>>>>>> CreationalContext which
>>>>>>>>>>>>>>> contains the dependent
>> scoped
>>>> interceptors for
>>>>>>> our own
>>>>>>>>>>> Producers and
>>>>>>>>>>>>>>> InjectionTargets. But I
>> have no
>>>> clue yet how
>>>>>>> that
>>>>>>>>> should get
>>>>>>>>>>>>>>> implemented if one
>>>>>>>>>>>>>>> plugs in a portable
>> Producer via
>>>> an Extension
>>>>>>> ^^
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Who is responsible of
>> performing
>>>> the
>>>>>>> interception? The
>>>>>>>>>>> Producer? Or
>>>>>>>>>>>>>>> must the
>>>>>>>>>>>>>>> instance being handed
>> into already
>>>> be a Proxy?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The instance returned from
>> produce()
>>>> should have
>>>>>>> interceptors
>>>>>>>>> and
>>>>>>>>>>>>> decorators applied.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please let me know if above makes
>> sense,
>>>> it took me a
>>>>>>> while to
>>>>>>>>> work out
>>>>>>>>>>>>> whether what was defined was
>> sane. After
>>>> quite a lot of
>>>>>>>
>>>>>>>>> thinking +
>>>>>>>>>>>>> talking to Jozef and Stuart I
>> came to the
>>>> conclusion it
>>>>>>> was,
>>>>>>>>> but if
>>>>>>>>>>> you
>>>>>>>>>>>>> can poke holes then please do!
>>>>>>>>>>>>>
>>>> _______________________________________________
>>>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>>>>>
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>
More information about the cdi-dev
mailing list