[jira] [Commented] (DELTASPIKE-334) CDI + Blueprint integration
[
https://issues.apache.org/jira/browse/DELTASPIKE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807007#comment-13807007
]
Gerhard Petracek commented on DELTASPIKE-334:
-
@jason:
that wasn't a "go". just keeping this ticket unchanged and unassigned for
months isn't nice.
+1 for dropping it in favor of pax-cdi.
> CDI + Blueprint integration
> ---
>
> Key: DELTASPIKE-334
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-334
> Project: DeltaSpike
> Issue Type: New Feature
>Reporter: Charles Moulliard
>Assignee: Charles Moulliard
>Priority: Minor
>
> Description should be enriched by authors (Jason, ...)
> {code}
> From:Nodet Guillaume
> 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)
> >>
> >>
> >>
> #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
>
>
>
> Not sure what exactly we'd need in the 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 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
> element or a default attribute on the element.
> Cheers,
> Guillaume Nodet
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (DELTASPIKE-341) Provide Integration between Faces Exceptions and Exception Handling
[ https://issues.apache.org/jira/browse/DELTASPIKE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807000#comment-13807000 ] Cody Lerum commented on DELTASPIKE-341: --- I don't have anything using Deactivatable > Provide Integration between Faces Exceptions and Exception Handling > --- > > Key: DELTASPIKE-341 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-341 > Project: DeltaSpike > Issue Type: Improvement >Reporter: Cody Lerum >Assignee: Jason Porter > Fix For: 0.6 > > > Just an ExceptionHandlerFactory and ExceptionHandlerWrapper which fire and > remove events so that DS core exceptional handling can intercept. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DELTASPIKE-341) Provide Integration between Faces Exceptions and Exception Handling
[ https://issues.apache.org/jira/browse/DELTASPIKE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806980#comment-13806980 ] Jason Porter commented on DELTASPIKE-341: - Cody, if you have a working example with the Deactivatable code, that would be a great addition to add to some documentation. > Provide Integration between Faces Exceptions and Exception Handling > --- > > Key: DELTASPIKE-341 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-341 > Project: DeltaSpike > Issue Type: Improvement >Reporter: Cody Lerum >Assignee: Jason Porter > Fix For: 0.6 > > > Just an ExceptionHandlerFactory and ExceptionHandlerWrapper which fire and > remove events so that DS core exceptional handling can intercept. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DELTASPIKE-334) CDI + Blueprint integration
[
https://issues.apache.org/jira/browse/DELTASPIKE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806868#comment-13806868
]
Romain Manni-Bucau commented on DELTASPIKE-334:
---
maybe we should get the DS xml config before dealing with integration with
other framework.
IIRC we agreed to integrate it so that's maybe the first step?
> CDI + Blueprint integration
> ---
>
> Key: DELTASPIKE-334
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-334
> Project: DeltaSpike
> Issue Type: New Feature
>Reporter: Charles Moulliard
>Assignee: Charles Moulliard
>Priority: Minor
>
> Description should be enriched by authors (Jason, ...)
> {code}
> From:Nodet Guillaume
> 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)
> >>
> >>
> >>
> #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
>
>
>
> Not sure what exactly we'd need in the 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 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
> element or a default attribute on the element.
> Cheers,
> Guillaume Nodet
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (DELTASPIKE-334) CDI + Blueprint integration
[
https://issues.apache.org/jira/browse/DELTASPIKE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806863#comment-13806863
]
Jason Porter commented on DELTASPIKE-334:
-
I believe part (or maybe all of this?) is being done with PAX CDI. Anyone
working on that here?
> CDI + Blueprint integration
> ---
>
> Key: DELTASPIKE-334
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-334
> Project: DeltaSpike
> Issue Type: New Feature
>Reporter: Charles Moulliard
>Assignee: Charles Moulliard
>Priority: Minor
>
> Description should be enriched by authors (Jason, ...)
> {code}
> From:Nodet Guillaume
> 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)
> >>
> >>
> >>
> #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
>
>
>
> Not sure what exactly we'd need in the 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 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
> element or a default attribute on the element.
> Cheers,
> Guillaume Nodet
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
