February 2017 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-114) Allow registration of beans at runtime

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-114: ----------------------------------- What is your exact use case? Usually the bean graph and Classpath per application is pretty much static once booted. Except during development. If it's just for development then you might look at https://github.com/HotswapProjects > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-114) Allow registration of beans at runtime

by Vincent Massol (JIRA)

[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ] Vincent Massol commented on CDI-114: ------------------------------------ Hi guys. I was wondering if there was now a recommended way of supporting the main use case I listed above back in 2011, namely: If you have a CDI application, how can you add support for installing extensions at runtime for this application (for example by adding JARs containing beans to the classloader), and tell the Bean Manager to take into account those news beans? I suspect this is a common need for apps as they grow (i.e. the ability to dynamically add extensions). As I mentioned back then, we've been supporting this in XWiki for about 10 years now with our custom handmade solution but I hate using custom solutions when there exists standard solutions so I'm always on the lookout for such solutions. I've been wanting to try to use CDI for years now but have dropped it in 2011 because of the lack of a solution. The only option I've heard so far would be to tell the Bean Manager to "restart" and thus re-run the process of creating/resolving the Bean graph. Is that still the only solution? However, I'm worried that this would take too long for our needs since XWiki has thousands (possibly tens of thousands) of Beans running, coming from hundreds of JAR files. Is this "restart"/"reload" already implemented and optimized so that there's no rescanning of JAR files for example? Does anyone have any experience with this? Thanks a lot! > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-685) Section 1.2 does not describe relationship to javax.annotations specification

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-685?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-685: ------------------------------------------ Agree. For the record the 1st chapter of the spec is an introduction and not part of the spec as stated in [Doc Organisation section|http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#doc_organisa...], so error in it is not a spec issue strictly speaking but OTH we are more free to change this introcution to make it clearer and easier to get. > Section 1.2 does not describe relationship to javax.annotations specification > ----------------------------------------------------------------------------- > > Key: CDI-685 > URL: https://issues.jboss.org/browse/CDI-685 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration, Java SE Integration > Affects Versions: 2.0 .Final > Reporter: Laird Nelson > > [Section 1.2|http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#_relationship_to...] of the specification does not describe a relationship to the {{javax.annotation}} specification. IMHO this is relevant because the usage of [{{@Priority}}|http://docs.oracle.com/javaee/7/api/javax/annotation/Priority.html] as an ordering mechanism for observer methods relies on its being applicable to method parameters, which in version 1.2 of the {{javax.annotation}} specification it is not. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-685) Section 1.2 does not describe relationship to javax.annotations specification

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-685?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-685: ---------------------------------- In fact, the spec does not even mention the fully qualified name of the priority annotation - {{javax.annotation.Priority}}! +1 for clarification > Section 1.2 does not describe relationship to javax.annotations specification > ----------------------------------------------------------------------------- > > Key: CDI-685 > URL: https://issues.jboss.org/browse/CDI-685 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration, Java SE Integration > Affects Versions: 2.0 .Final > Reporter: Laird Nelson > > [Section 1.2|http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#_relationship_to...] of the specification does not describe a relationship to the {{javax.annotation}} specification. IMHO this is relevant because the usage of [{{@Priority}}|http://docs.oracle.com/javaee/7/api/javax/annotation/Priority.html] as an ordering mechanism for observer methods relies on its being applicable to method parameters, which in version 1.2 of the {{javax.annotation}} specification it is not. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-685) Section 1.2 does not describe relationship to javax.annotations specification

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-685?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-685: ----------------------------- Issue Type: Clarification (was: Bug) > Section 1.2 does not describe relationship to javax.annotations specification > ----------------------------------------------------------------------------- > > Key: CDI-685 > URL: https://issues.jboss.org/browse/CDI-685 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration, Java SE Integration > Affects Versions: 2.0 .Final > Reporter: Laird Nelson > > [Section 1.2|http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#_relationship_to...] of the specification does not describe a relationship to the {{javax.annotation}} specification. IMHO this is relevant because the usage of [{{@Priority}}|http://docs.oracle.com/javaee/7/api/javax/annotation/Priority.html] as an ordering mechanism for observer methods relies on its being applicable to method parameters, which in version 1.2 of the {{javax.annotation}} specification it is not. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-685) Section 1.2 does not describe relationship to javax.annotations specification

by Laird Nelson (JIRA)

Laird Nelson created CDI-685: -------------------------------- Summary: Section 1.2 does not describe relationship to javax.annotations specification Key: CDI-685 URL: https://issues.jboss.org/browse/CDI-685 Project: CDI Specification Issues Issue Type: Bug Components: Java EE integration, Java SE Integration Affects Versions: 2.0 .Final Reporter: Laird Nelson [Section 1.2|http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#_relationship_to...] of the specification does not describe a relationship to the {{javax.annotation}} specification. IMHO this is relevant because the usage of [{{@Priority}}|http://docs.oracle.com/javaee/7/api/javax/annotation/Priority.html] as an ordering mechanism for observer methods relies on its being applicable to method parameters, which in version 1.2 of the {{javax.annotation}} specification it is not. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-684) Should portable extension support static observer method

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-684?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-684: ------------------------------------- Summary: Should portable extension support static observer method (was: Does portable extension should support static observer method) > Should portable extension support static observer method > -------------------------------------------------------- > > Key: CDI-684 > URL: https://issues.jboss.org/browse/CDI-684 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > Error reported in WELD-2331 brings the question of clarification of this point. > Should we forbid usage of static observer in extension class or not ? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-684) Does portable extension should support static observer method

by Antoine Sabot-Durand (JIRA)

Antoine Sabot-Durand created CDI-684: ---------------------------------------- Summary: Does portable extension should support static observer method Key: CDI-684 URL: https://issues.jboss.org/browse/CDI-684 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Reporter: Antoine Sabot-Durand Error reported in WELD-2331 brings the question of clarification of this point. Should we forbid usage of static observer in extension class or not ? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-683) BeanConfigurator#produceWith(Function) does not allow access to InjectionPoint

by Laird Nelson (JIRA)

Laird Nelson created CDI-683: -------------------------------- Summary: BeanConfigurator#produceWith(Function) does not allow access to InjectionPoint Key: CDI-683 URL: https://issues.jboss.org/browse/CDI-683 Project: CDI Specification Issues Issue Type: Bug Components: Beans Affects Versions: 2.0 .Final Reporter: Laird Nelson The {{BeanConfigurator#produceWith(Function)}} method is intended to simulate a producer method, and is quite convenient. The {{Function}} that it takes accepts one parameter which is of type {{Instance<Object>}}. This is supposed to allow "faking" parameter injection in a producer method. One of the parameters that you commonly want in a producer method is the {{InjectionPoint}} for which the return value of the producer method is destined. If you try to "get" this {{InjectionPoint}} like this: {code} final Instance<InjectionPoint> injectionPointInstance = instance.select(InjectionPoint.class); final InjectionPoint injectionPoint = injectionPointInstance.get(); {code} ...the {{InjectionPoint}} returned is _not_ the one you want, but instead a strange {{InjectionPoint}} that seems to represent something in the {{Instance}} class itself. The [{{InjectionPoint}} javadocs|http://docs.jboss.org/cdi/api/2.0.Beta1/javax/enterprise/inject/...] say this about the matter: bq. If the injection point is a dynamically selected reference obtained [sic] then the metadata obtain [sic] reflects the injection point of the Instance, with the required type and any additional required qualifers [sic] defined by Instance.select(). I observe that Weld's behavior in this case matches the javadocs (if I'm understanding them right), but surely I should be able to get the {{InjectionPoint}} that is being serviced by my simulated producer method. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

CDI 2.0 is in public review

by Antoine Sabot-Durand

In case you missed it: http://www.slideshare.net/antoinesd/cdi-20-is-upon-us-devoxx

7 years, 10 months

3
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2017