[JBoss JIRA] (CDI-114) Allow registration of beans at runtime
by Samba Kolusu (JIRA)
[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ]
Samba Kolusu commented on CDI-114:
----------------------------------
let me put this issue in a different context:
(1) let us say an application is deployed with three CORE modules that are essentials and cannot be disabled or removed, each having their own named CDI beans, which may depend on other such beans from the other two core modules.
this setup works perfectly as all the modules (and CDI beans, interceptors, qualifiers, decorators, etc) are always loaded , and at deployment
(2) a new module is installed into this system at runtime - with the following CDI usage:
inject existing CDI beans, supplied by one or more of the always present core modules, into its own injectable classes like Servlets, JSF backing beans, transaction Services, etc. i suppose this should not be an issue at all, since the new module is only trying to use existing CDI components. if for example for Events that need to be fired, the newly registered CDI components from the installed module (plugin, for clarity) can be added as EventListeners or interceptors during bean registration. the core modules shall never depend on the additional modules. it is only the CDI components from additional modules that may listen to or intercept the events and method invocations of CDI components from core modules. ---- what is the problem in supporting this feature?
(3) let us say module-x and module-y are deployed as additional modules, and module-y specified dependency on module-x because one or more of the CDI component in module-y is using or listening or intercepting one or more of the CDI components from module-x. in this case - the module framework will not let the installation of module-y if module-x is not installed; similarly, the framework will not let the uninstallation of module-x without the uninstallation of module-y. so, we can always be sure that the CDI components required by module-y are always present in the application because when module-y is there, the module-x shall always be there. at no point in time, a CDI component in module-x can refer to (depend on) a CDI component of module-y. that dependency management is the responsibility of the module framework, if it fails there, it is not the problem of CDI. why can't this be supported?
(4) i guess you could be thinking about a scenario where one CDI component from module-x depends on other CDI compoent of module-y while another CDI component of module-y depends on yet another CDI component of module-x.... i.e. cyclical dependency of modules... i agree that makes it much more complex, and require checking boundaries too often-- but why can't a well-defined dependency graph be supported?
all that is needed is registering the CDI components (by component, i mean bean/interceptor/qualifier/producer/etc) at runtime, and broadcasting the events (including method invocation - for interceptors) to runtime registered CDI components. what is so dangerous in this?
as a realistic use case :
suppose a web app is deployed with some core set of JPA Entities, JSF backing beans, JSF pages, CDI Transaction beans that may offer REST services too (because EJB container do not allow dynamic adding of beans, we rely solely on CDI) . now into this system, a new module gets installed that brings in new JPA entities, JSF backing beans, JSF pages, its own CDI transactional components, etc. now, any of the CDI components (including backing beans) may like to listen for or depend or intercept any of CDI components deployed at startup (or installed before). why can’t this be achieved since the previously installed CDI components can never depend on the newly installed CDI components? what problems do you see in this? in fact, we can easily uninstall this newly installed module and remove all of its CDI components with out any impact to the core web app system that was deployed initially. — all that is needed is to track what came in new, and which new ones are listening to or intercepting around which old ones. refusing to implement this feature because improper usage may cause unpredictable errors is like saying synchronized key word cannot be supported because its improper use leads to deadlocks in multi-threaded systems.
> 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
Identify a Bean as synthetic?
by Laird Nelson
I haven't thought this through yet but I wonder if it would be helpful to
mark a Bean as synthetic or not—i.e. discovered by means of the "normal"
bean discovery process, or programmatically added by a portable extension.
I was mentally working through what it might take to write up a sort of CDI
reporting mechanism—something that would report on what beans where found,
where they came from, what interceptors are enabled and why, etc. etc. etc.
and realized one axis of this would be whether a portable extension was
involved with certain beans or not.
Should I file an enhancement/feature request, or is this something that was
already debated and turned away at some point in the past?
Best,
Laird
7 years, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-686:
----------------------------------------
was referring to the producer parameter but tend to think the factory doesnt care much and can use the passed types blindly
> Could InterceptionFactory accept an interface as type parameter
> ---------------------------------------------------------------
>
> Key: CDI-686
> URL: https://issues.jboss.org/browse/CDI-686
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0 .Final
> Reporter: Antoine Sabot-Durand
>
> If you take this code:
> {code:java}
> @Produces
> public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) {
> interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> {
> if (m.getJavaMember().getName().equals("add")
> && m.getJavaMember().getParameterCount() == 1) {
> return true;
> }
> return false;
> }).findFirst().get().add(Monitor.Literal.INSTANCE);
> return interceptionFactory.createInterceptedInstance(new ArrayList<>());
> }
> {code}
> Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding.
> In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-686:
----------------------------------
What's the _"injected" generic type_?
> Could InterceptionFactory accept an interface as type parameter
> ---------------------------------------------------------------
>
> Key: CDI-686
> URL: https://issues.jboss.org/browse/CDI-686
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0 .Final
> Reporter: Antoine Sabot-Durand
>
> If you take this code:
> {code:java}
> @Produces
> public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) {
> interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> {
> if (m.getJavaMember().getName().equals("add")
> && m.getJavaMember().getParameterCount() == 1) {
> return true;
> }
> return false;
> }).findFirst().get().add(Monitor.Literal.INSTANCE);
> return interceptionFactory.createInterceptedInstance(new ArrayList<>());
> }
> {code}
> Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding.
> In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-686:
----------------------------------------
is that so hard? I mean, I don't think we need a CDI rule but just a standard java one where you can "cast" the instance since it is out of CDI matching rules world, no? Or do you want to limit to the "injected" generic type?
> Could InterceptionFactory accept an interface as type parameter
> ---------------------------------------------------------------
>
> Key: CDI-686
> URL: https://issues.jboss.org/browse/CDI-686
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0 .Final
> Reporter: Antoine Sabot-Durand
>
> If you take this code:
> {code:java}
> @Produces
> public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) {
> interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> {
> if (m.getJavaMember().getName().equals("add")
> && m.getJavaMember().getParameterCount() == 1) {
> return true;
> }
> return false;
> }).findFirst().get().add(Monitor.Literal.INSTANCE);
> return interceptionFactory.createInterceptedInstance(new ArrayList<>());
> }
> {code}
> Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding.
> In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-686:
------------------------------------------
Ok, got it. But as Martin and I said it's a bit late to work on that without risking making error in standardisation.
So I still suggest that we make it non portable to allow us to cleanly specify it in the future.
On the Weld side, we'll probably add this support (that doesn't exist right now) to allow these use case.
> Could InterceptionFactory accept an interface as type parameter
> ---------------------------------------------------------------
>
> Key: CDI-686
> URL: https://issues.jboss.org/browse/CDI-686
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0 .Final
> Reporter: Antoine Sabot-Durand
>
> If you take this code:
> {code:java}
> @Produces
> public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) {
> interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> {
> if (m.getJavaMember().getName().equals("add")
> && m.getJavaMember().getParameterCount() == 1) {
> return true;
> }
> return false;
> }).findFirst().get().add(Monitor.Literal.INSTANCE);
> return interceptionFactory.createInterceptedInstance(new ArrayList<>());
> }
> {code}
> Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding.
> In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-686:
----------------------------------------
You can also consider:
{code}
// pseudo code
MyBean<T> implements Bean<T> {
T create(CC context) {
return factory.createInterceptedInstance(Proxy.newProxyInstance(...));
}
}
{code}
Which is way more commont than the producer case IMHO - at least from the code I encountered until now.
> Could InterceptionFactory accept an interface as type parameter
> ---------------------------------------------------------------
>
> Key: CDI-686
> URL: https://issues.jboss.org/browse/CDI-686
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0 .Final
> Reporter: Antoine Sabot-Durand
>
> If you take this code:
> {code:java}
> @Produces
> public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) {
> interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> {
> if (m.getJavaMember().getName().equals("add")
> && m.getJavaMember().getParameterCount() == 1) {
> return true;
> }
> return false;
> }).findFirst().get().add(Monitor.Literal.INSTANCE);
> return interceptionFactory.createInterceptedInstance(new ArrayList<>());
> }
> {code}
> Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding.
> In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-686:
----------------------------------
I think I understand the use case described by [~rmannibucau] and [~tandraschko], e.g. somethig like:
{code:java}
interface MyService {}
class MyServiceProducer {
@Produces
MyService produce(InterceptionFactory<MyService> factory, ServiceLocator locator) {
factory.configure().add(Monitor.Literal.INSTANCE);
// Lookup a MyService implementation...
return factory.createInterceptedInstance(locator.lookup(MyService.class));
}
}
{code}
However, I'm afraid it's too late for this kind of discussions. Since we would have to carefully adapt the inheritance rules (as defined in "4. Inheritance and specialization") for this particular use case. Note that _"Type-level metadata is never inherited from interfaces implemented by a bean."_.
> Could InterceptionFactory accept an interface as type parameter
> ---------------------------------------------------------------
>
> Key: CDI-686
> URL: https://issues.jboss.org/browse/CDI-686
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0 .Final
> Reporter: Antoine Sabot-Durand
>
> If you take this code:
> {code:java}
> @Produces
> public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) {
> interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> {
> if (m.getJavaMember().getName().equals("add")
> && m.getJavaMember().getParameterCount() == 1) {
> return true;
> }
> return false;
> }).findFirst().get().add(Monitor.Literal.INSTANCE);
> return interceptionFactory.createInterceptedInstance(new ArrayList<>());
> }
> {code}
> Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding.
> In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-686:
----------------------------------------
[~antoinesabot-durand] how is it supposed to work with an API which doesn't use @Produces and doesn't have a concrete implementation but just a Proxy instance?
> Could InterceptionFactory accept an interface as type parameter
> ---------------------------------------------------------------
>
> Key: CDI-686
> URL: https://issues.jboss.org/browse/CDI-686
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0 .Final
> Reporter: Antoine Sabot-Durand
>
> If you take this code:
> {code:java}
> @Produces
> public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) {
> interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> {
> if (m.getJavaMember().getName().equals("add")
> && m.getJavaMember().getParameterCount() == 1) {
> return true;
> }
> return false;
> }).findFirst().get().add(Monitor.Literal.INSTANCE);
> return interceptionFactory.createInterceptedInstance(new ArrayList<>());
> }
> {code}
> Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding.
> In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Thomas Andraschko (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Thomas Andraschko commented on CDI-686:
---------------------------------------
+1 romain. Same for abstract classes.
Mabye it would be great if the CDI API would allow the same features as the DS PartialBean module. Shoudln't be that hard. AFAIR the code is almost already availble in OWB, we would just need a nice API (like introducing a @PartialBeanBinding).
> Could InterceptionFactory accept an interface as type parameter
> ---------------------------------------------------------------
>
> Key: CDI-686
> URL: https://issues.jboss.org/browse/CDI-686
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0 .Final
> Reporter: Antoine Sabot-Durand
>
> If you take this code:
> {code:java}
> @Produces
> public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) {
> interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> {
> if (m.getJavaMember().getName().equals("add")
> && m.getJavaMember().getParameterCount() == 1) {
> return true;
> }
> return false;
> }).findFirst().get().add(Monitor.Literal.INSTANCE);
> return interceptionFactory.createInterceptedInstance(new ArrayList<>());
> }
> {code}
> Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding.
> In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
