CDI+Blueprint

[Jason Porter <jp...@redhat.com>]

I'm sending the content of our previous discussions, taking out some of the mail header/footer garbage.

From:        Nodet Guillaume <gn...@redhat.com>

Such a xml is in the META-INF/beans.xml, right ? So that you can override the behaviour of annotations ?
I'm not sure how / where we could use it, and that does not seem really critical to me anyway.

I think we'd better come to an understanding of the use case we'd want to cover.
I'm thinking about:
 * #1 create beans using the CDI container
 * #2 inject CDI beans into blueprint beans using the blueprint xml
 * #3 inject blueprint beans into CDI beans using @Inject
 * #4 support CDI annotations on blueprint beans (@PostConstruct, @PreDestroy, @Inject)

#1 is obviously needed, it could be done from the blueprint xml using a simple tag, eventually pointing to the beans.xml config file, or inline it (though inlining is not really worth the pain now imho)
>>>>>> <cdi:container xmlns="…">
>>>>>>     <cdi:beans url="…" />
>>>>>> </cdi:container>


#2 means being able to use one of the bean created from the CDI container and inject it using the xml blueprint syntax, something like
 <bean ….>
   <cdiroperty name="service"… />
</bean>
Not sure what exactly we'd need in the <cdiroperty/> element, but the idea is to use the bean setters to inject a bean created inside the CDI container

#3 means that we'd need to be able to inject a bean created by the blueprint container using <bean/> into a @Inject annotated property of a CDI bean created by the CDI container.  In blueprint, beans are referred to by name though, so it may require a custom annotation maybe ?

#4 means mixing CDI annotations with blueprint beans.  It's the most complicated case I think, as it needs an even closer cooperation of both containers.
This needs to be triggered either globally or an individual bean using a flag such an xml attribute such as cdirocess="true" that could be set on a <bean/> element or a default attribute on the <cdi:container/> element.

Cheers,
Guillaume Nodet

On Feb 13, 2013, at 6:38 PM, Jason Porter <jp...@redhat.com> wrote:

> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/xml-provider.html unfortunately there isn't an xsd (thought for sure there was). It's based on the XML configuration that was originally part of the CDI 1.0 specification. You can that at http://download.oracle.com/otndocs/jcp/web_beans-1.0-pr-oth-JSpec/ Chapter 9.
>
> ----- Original Message -----
>> From: "Nodet Guillaume" <gn...@redhat.com>
>>
>> Do you have any pointer to the seam 3 xml / xsd ?
>>
>> Guillaume
>>
>> On Feb 13, 2013, at 6:11 PM, Jason Porter <jp...@redhat.com> wrote:
>>
>>> Thanks all. I've looked through the code (pulled it from github for
>>> now). This doesn't seem terribly difficult, at least the
>>> integration. My two concerns right now are when this happens (and
>>> if we need to kick it off from a CDI life cycle event) and what we
>>> want the XML and XSD to look like. Do we want to take what we have
>>> from Seam 3 or create something different?
>>>
>>> ----- Original Message -----
>>>> From: "Emily Jiang" <EM...@uk.ibm.com>
>>>>
>>>> If you check out the trunk according to the instruction of the
>>>> apache
>>>> aries wiki (link attached in my earlier email). All transaction
>>>> models are under the directory of transaction. Yes.
>>>> transaction-blueprint is the one that you should be able to follow
>>>> as an example. You can find out the registration of namespace
>>>> handler in its transaction.xml.
>>>>
>>>> Many thanks,
>>>> Emily
>>>> ===========================
>>>> Emily Jiang
>>>>
>>>>
>>>>
>>>>
>>>> From: James Strachan <js...@redhat.com>
>>>> I'm guessing the transaction-blueprint project…
>>>> https://github.com/apache/aries/tree/trunk/transaction/transaction-blueprint
>>>>
>>>> On 12 Feb 2013, at 17:24, Jason Porter wrote:
>>>>
>>>>> Where's the transaction stuff?
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Emily Jiang" <EM...@uk.ibm.com>
>>>>>>
>>>>>> Agree with Guilliaume that it is a good design if CDI support is
>>>>>> registered as a blueprint namespace like transaction support.
>>>>>> You
>>>>>> can find the transaction example from the aries code.
>>>>>>
>>>>>> I suggest you follow the aries wiki to check out the source. You
>>>>>> can
>>>>>> also join the aries dev to discuss any concerns you might have.
>>>>>>
>>>>>> Many thanks,
>>>>>> Emily
>>>>>> ===========================
>>>>>> Emily Jiang
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Guillaume Nodet <gn...@redhat.com>
>>>>>> The blueprint container main class is the following one:
>>>>>> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java
>>>>>>
>>>>>> But if we want to make things clean, the CDI support should be
>>>>>> written as a blueprint namespace.
>>>>>> The main interface is there
>>>>>> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-parser/src/main/java/org/apache/aries/blueprint/NamespaceHandler.java
>>>>>>
>>>>>> That would mean that the blueprint xml would look like
>>>>>>
>>>>>> <blueprint xmlns="…">
>>>>>>
>>>>>> <cdi:container xmlns="…">
>>>>>> <cdi:beans url="…" />
>>>>>> </cdi:container>
>>>>>>
>>>>>> … blueprint beans ...
>>>>>>
>>>>>> </blueprint>
>>>>>>
>>>>>> The namespace handler implementation will be called when the
>>>>>> parser
>>>>>> hits the <cdi:container> element.
>>>>>> At that point, the cdi namespace handler will be invoked and can
>>>>>> start some processing.
>>>>>>
>>>>>> Injections of blueprint beans into CDI beans and injection of
>>>>>> CDI
>>>>>> beans into blueprint should not be too problematic.
>>>>>> I guess the tricky questions will come when we want to support
>>>>>> CDI
>>>>>> annotations on a blueprint managed bean …
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>>
>>>>>> On 11 févr. 2013, at 17:42, Jason Porter < jporter@redhat.com >
>>>>>> wrote:
>>>>>>
>>>>>> Hi everyone, as you all know infinitely more about Aries and the
>>>>>> blueprint parser than I do at present, where should I start and
>>>>>> what
>>>>>> do we think will be the best way to hook into it to support CDI?
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Ian Robinson" < ian_robinson@uk.ibm.com >
>>>>>>
>>>>>> I'd like to see the Apache Blueprint implementation be able to
>>>>>> integrate with CDI too. So long as the design is such that the
>>>>>> implementation remains modular and that compatibility with
>>>>>> current
>>>>>> BP container behaviour can be maintained.
>>>>>>
>>>>>> Regards,
>>>>>> Ian
>>>>>>
>>>>>> Ian Robinson , IBM Distinguished Engineer
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: David Bosschaert <da...@redhat.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 31/01/2013 09:00, Guillaume Nodet wrote:
>>>>>> On 31 janv. 2013, at 15:55, Jason Porter <jp...@redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>> From a development point of view, I don't think it really
>>>>>> matters
>>>>>> where we put it, aside from the Aries wanting to move on this
>>>>>> now
>>>>>> and DeltaSpike guys moving very slowly
>>>>>>
>>>>>> From a user pov, I'm torn. I guess it depends on which camp
>>>>>> you're
>>>>>> in as to where you would expect this to live. Either way we'll
>>>>>> want to keep dependencies to a minimum. With DeltaSpike that
>>>>>> would be the core and this new config module. With Aries?
>>>>>> I think Aries makes more sense, the reason being that such a CDI
>>>>>> /
>>>>>> Blueprint integration can not be independent of the blueprint
>>>>>> container, because the blueprint specification does not cover
>>>>>> such
>>>>>> SPI at all. But that's really not so important.
>>>>>> And this may require more blueprint container hacking than CDI
>>>>>> container hacking.
>>>>>>
>>>>>> I'm happy to do the code where ever makes the most sense, though
>>>>>> with Aries it would have to be a patch as I'm not a commiter.
>>>>>>
>>>>>> Guillaume and I are Aries committers and I think there are a
>>>>>> number
>>>>>> of
>>>>>> other Aries committers on this thread. I'm happy to help getting
>>>>>> patches
>>>>>> applied. If we're going to do this work in Aries then I think we
>>>>>> should
>>>>>> work towards getting those who will be working on this becoming
>>>>>> Aries
>>>>>> committers in the medium term.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> PO6 3AU
>>>>>>
>>>>
>>>>
>>>> James
>>>> -------
>>>> Red Hat

>>
>>