[JBoss JIRA] (CDI-535) cdi instance injection ordering
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-535:
-----------------------------
Fix Version/s: 2.1 (Discussion)
> cdi instance injection ordering
> -------------------------------
>
> Key: CDI-535
> URL: https://issues.jboss.org/browse/CDI-535
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Reporter: Ochieng Marembo
> Priority: Optional
> Fix For: 2.1 (Discussion)
>
>
> We should allow ordering of bean instance injection using the {{Instance<MyBeanInterface>}} when an instance injection is used.
> h3. Use case:
> Developer always define a kind of chain of processor beans, which may need to run in specific order.
> h3. Current scenario:
> Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following:
> #1
> {code:java}
> private Iterable<MyBeanInterface> myBeans;
> @Inject
> void injectBeans(@Any Instance<MyBeanInterface> myBeans) {
> //the create order does some kind of ordering on the beans.
> this.myBeans = createOrder(myBeans);
> }
> {code}
> #2
> This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call.
> {code:java}
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> public void doSomething() {
> Iterable<MyBeanInterface> orderedbeans = createOrder(myBeans.select(someQualifier));
> }
> {code}
> h3. Our Proposal
> We already have {{javax.annotation.Priority}} or any cdi specific annotation which we can add to {{MyBeanInterfaceImpl}} so that on injection of an {{Instance<MyBeanInterface>}}, all possible injection values are sorted based on the {{Priority.value()}} and if no annotation is defined, defaults to {{Priority.value = Integer.MAX_VALUE}}
> {code:java}
> public interface MyBeanInterface {}
> @MyQualifier
> @Priority(0)
> public class MyFirstBean implements MyBeanInterface{
> }
> @MyQualifier
> @Priority(2)
> public class MySecondBean implements MyBeanInterface{
> }
> @ApplicationScoped
> public class MyBeanProcessor {
> //We expect that this injected instances shall be in order based on the @Priority annotation
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang edited comment on CDI-627 at 11/17/16 12:29 PM:
------------------------------------------------------------
As Mark has fixed the issue reported by Tomas, can this PR #309 be merged and then this issue can be fixed by Weld? [~antoinesabot-durand]
was (Author: emilyj):
As Mark has fixed the issue reported by Tomas, can this PR #309 be merged and then this issue can be fixed by Weld.
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang edited comment on CDI-627 at 11/17/16 12:29 PM:
------------------------------------------------------------
As Mark has fixed the issue reported by Tomas, can this PR #309 be merged and then this issue can be fixed by Weld, [~antoinesabot-durand]?
was (Author: emilyj):
As Mark has fixed the issue reported by Tomas, can this PR #309 be merged and then this issue can be fixed by Weld? [~antoinesabot-durand]
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-627:
---------------------------------
As Mark has fixed the issue reported by Tomas, can this PR #309 be merged and then this issue can be fixed by Weld.
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
John offline until ~11/26
by John Ament
Will be offline through the coming US holiday.
John
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
7 years, 5 months
Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
by Werner Keil
+1 for InterceptionFactory, too.
It sounds simpler.
Werner
On Tue, Nov 8, 2016 at 2:29 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Finding a new name for InterceptorProxyFactory (Mark Struberg)
> 2. Re: Finding a new name for InterceptorProxyFactory
> (Antoine Sabot-Durand)
> 3. Re: Finding a new name for InterceptorProxyFactory
> (Romain Manni-Bucau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 7 Nov 2016 16:58:04 +0000 (UTC)
> From: Mark Struberg <struberg(a)yahoo.de>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Romain Manni-Bucau <rmannibucau(a)gmail.com>, Antoine Sabot-Durand
> <antoine(a)sabot-durand.net>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <421014798.1728352.1478537884045(a)mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
>
> InterceptionFactory sounds fine for me.
>
>
> LieGrue,
> strub
>
>
>
> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> rmannibucau(a)gmail.com> wrote:
> >
> >Hello Antoine,
> >
> >
> >concurrency-utilities use ContextFactory for something pretty close (a
> proxying adding spec features over invocations) which is less "cglib-like"
> than "Enhancer" so I'd like to keep Factory. In the list
> InterceptionFactory looks clear enough. We neevr speak of business method
> anymore I think so it would add a difficulty for something very useful to
> go that deep in the naming I think.
> >
> >
> >
> >Romain Manni-Bucau
> >@rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >
> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net
> >:
> >
> >Hi all,
> >>
> >>
> >>In my last review for CDI-580 (https://github.com/cdi-spec/
> cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
> following various feedback.
> >>So now the name of the interface is the only one dealing with Proxy, so
> we really need to find it a new name.
> >>I listed some proposal in PR 315:
> >>- InstanceEnhancer (short but not very clear)
> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
> clear from user pov?)
> >>- InterceptionFactory (cleared from user pov and near our initial name)
> >>- InterceptionEnhancer
> >>
> >>
> >>Feedback and other names are welcome.
> >>
> >>
> >>Antoine
> >>______________________________ _________________
> >>cdi-dev mailing list
> >>cdi-dev(a)lists.jboss.org
> >>https://lists.jboss.org/ mailman/listinfo/cdi-dev
> >>
> >>Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list, the
> provider waives all patent and other intellectual property rights inherent
> in such information.
> >>
> >
> >
> >_______________________________________________
> >cdi-dev mailing list
> >cdi-dev(a)lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> >Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
> >
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 08 Nov 2016 13:24:28 +0000
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Mark Struberg <struberg(a)yahoo.de>, Romain Manni-Bucau
> <rmannibucau(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CABu-YBRhd8UYWck4-fibda_Ykoh-n=u_Xfhs48tUcBCOw_TiAw@mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> +1 for InterceptionFactory as well. I change my PR with this name.
>
> Romain, for the record, mentioning "business method invocation" and
> paragraph 7.2 is the only mean to bind this feature to the spec without
> mentioning implementation specific stuff like proxies. That's why the
> javadoc and text for this new section lack clarity. In other word we lack a
> simple name for instances on which "methods invocation" are "business
> methods invocation".
>
> Antoine
>
> On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg(a)yahoo.de> wrote:
>
> > InterceptionFactory sounds fine for me.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> > rmannibucau(a)gmail.com> wrote:
> > >
> > >Hello Antoine,
> > >
> > >
> > >concurrency-utilities use ContextFactory for something pretty close (a
> > proxying adding spec features over invocations) which is less
> "cglib-like"
> > than "Enhancer" so I'd like to keep Factory. In the list
> > InterceptionFactory looks clear enough. We neevr speak of business method
> > anymore I think so it would add a difficulty for something very useful to
> > go that deep in the naming I think.
> > >
> > >
> > >
> > >Romain Manni-Bucau
> > >@rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> > >
> > >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
> antoine(a)sabot-durand.net
> > >:
> > >
> > >Hi all,
> > >>
> > >>
> > >>In my last review for CDI-580 (https://github.com/cdi-spec/
> > cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
> > following various feedback.
> > >>So now the name of the interface is the only one dealing with Proxy, so
> > we really need to find it a new name.
> > >>I listed some proposal in PR 315:
> > >>- InstanceEnhancer (short but not very clear)
> > >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
> > clear from user pov?)
> > >>- InterceptionFactory (cleared from user pov and near our initial name)
> > >>- InterceptionEnhancer
> > >>
> > >>
> > >>Feedback and other names are welcome.
> > >>
> > >>
> > >>Antoine
> > >>______________________________ _________________
> > >>cdi-dev mailing list
> > >>cdi-dev(a)lists.jboss.org
> > >>https://lists.jboss.org/ mailman/listinfo/cdi-dev
> > >>
> > >>Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2 (http://www.apache.org/
> > licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the
> > provider waives all patent and other intellectual property rights
> inherent
> > in such information.
> > >>
> > >
> > >
> > >_______________________________________________
> > >cdi-dev mailing list
> > >cdi-dev(a)lists.jboss.org
> > >https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > >Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2 (
> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
> > >
> > >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/
> 20161108/efa4663c/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Tue, 8 Nov 2016 14:28:27 +0100
> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg(a)mail.gmail.
> com>
> Content-Type: text/plain; charset="utf-8"
>
> 2016-11-08 14:24 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net
> >:
>
> > +1 for InterceptionFactory as well. I change my PR with this name.
> >
> > Romain, for the record, mentioning "business method invocation" and
> > paragraph 7.2 is the only mean to bind this feature to the spec without
> > mentioning implementation specific stuff like proxies. That's why the
> > javadoc and text for this new section lack clarity. In other word we
> lack a
> > simple name for instances on which "methods invocation" are "business
> > methods invocation".
> >
> >
> Agree and it fits the spec but since EJB I never heard any developer (not
> developping weld or openwebbeans) using this term so for the API it would
> be rude IMHO - was the point, nothing more.
>
>
> > Antoine
> >
> > On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg(a)yahoo.de> wrote:
> >
> >> InterceptionFactory sounds fine for me.
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> >> rmannibucau(a)gmail.com> wrote:
> >> >
> >> >Hello Antoine,
> >> >
> >> >
> >> >concurrency-utilities use ContextFactory for something pretty close (a
> >> proxying adding spec features over invocations) which is less
> "cglib-like"
> >> than "Enhancer" so I'd like to keep Factory. In the list
> >> InterceptionFactory looks clear enough. We neevr speak of business
> method
> >> anymore I think so it would add a difficulty for something very useful
> to
> >> go that deep in the naming I think.
> >> >
> >> >
> >> >
> >> >Romain Manni-Bucau
> >> >@rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >> >
> >> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
> >> antoine(a)sabot-durand.net>:
> >> >
> >> >Hi all,
> >> >>
> >> >>
> >> >>In my last review for CDI-580 (https://github.com/cdi-spec/
> >> cdi/pull/315), I removed all reference to proxies in Javadoc and spec
> doc
> >> following various feedback.
> >> >>So now the name of the interface is the only one dealing with Proxy,
> so
> >> we really need to find it a new name.
> >> >>I listed some proposal in PR 315:
> >> >>- InstanceEnhancer (short but not very clear)
> >> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is
> it
> >> clear from user pov?)
> >> >>- InterceptionFactory (cleared from user pov and near our initial
> name)
> >> >>- InterceptionEnhancer
> >> >>
> >> >>
> >> >>Feedback and other names are welcome.
> >> >>
> >> >>
> >> >>Antoine
> >> >>______________________________ _________________
> >> >>cdi-dev mailing list
> >> >>cdi-dev(a)lists.jboss.org
> >> >>https://lists.jboss.org/ mailman/listinfo/cdi-dev
> >> >>
> >> >>Note that for all code provided on this list, the provider licenses
> the
> >> code under the Apache License, Version 2 (http://www.apache.org/
> >> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the
> >> provider waives all patent and other intellectual property rights
> inherent
> >> in such information.
> >> >>
> >> >
> >> >
> >> >_______________________________________________
> >> >cdi-dev mailing list
> >> >cdi-dev(a)lists.jboss.org
> >> >https://lists.jboss.org/mailman/listinfo/cdi-dev
> >> >
> >> >Note that for all code provided on this list, the provider licenses the
> >> code under the Apache License, Version 2 (http://www.apache.org/
> >> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> >> the provider waives all patent and other intellectual property rights
> >> inherent in such information.
> >> >
> >> >
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/
> 20161108/c6e8a845/attachment.html
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
> End of cdi-dev Digest, Vol 72, Issue 5
> **************************************
>
7 years, 5 months
AnnotatedTypeConfigurator limitation
by Antoine Sabot-Durand
Hi Guys,
Following CDI-642 and 643 I started to explore place where annotatedType
can be used and where we don't provide access to AnnotatedTypeConfigurator
[1], I really think we should solve this use case to avoid advanced users
frustration discovering a new feature they can use everywhere (that was my
case when realised that I could use it in BBD for Qualifier or
interceptorBinding addition).
Possible solutions:
1) Add a hook to each of these place to obtain an AnnotatedTypeConfigurator
2) Add BM.createAnnotatypeConfigurator(Class) and
BM.createAnnotatedType(ATC)
3) Add a Builder class that would provide a configure method
4) Transform AnnotatedTypeConfigurator into a Builder and simplify SPI
using AnnotatedTypeConfigurator.
Antoine
[1] Non exhaustive list :
- BeforeTypeDiscovery for addQualifier and addInterceptorBinding
- UnManaged class
- BeanManager createInjectionTartet and getInjectionTargetFactory or in
InjectionTarget
- BeanManager getProducerFactory where a configured AnnotatedField or
AnnotatedMethod could be useful
7 years, 5 months
[JBoss JIRA] (CDI-512) Initialization parameter to specify loaded Extensions
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-512?page=com.atlassian.jira.plugin.sy... ]
John Ament closed CDI-512.
--------------------------
Resolution: Rejected
Already in.
> Initialization parameter to specify loaded Extensions
> -----------------------------------------------------
>
> Key: CDI-512
> URL: https://issues.jboss.org/browse/CDI-512
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Java SE Integration
> Reporter: John Ament
> Assignee: John Ament
>
> As a tie in for CDI-511, define a initialization parameter that can specify the list of extensions to be enabled.
> The parameter should accept any Collection, however if a duplicate entry is found it is ignored.
> The collection should support either Classes or Strings representing the FQCN of the extension itself, or the extension instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
