[JBoss JIRA] (CDI-114) Allow registration of beans at runtime
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-114:
----------------------------------------
Hmm, does it means xwiki is leaking cause previously injected values can be unregistered ("remove extension")? Or did you mean you never inject the component by type but always Provider<X> everywhere? If so you also do lazy validation which means you accept to start a not functional app cause of a missing component - CDI prevents it. Is that right? If so I fear you need something to "mock" until you can inject an actual component. Means you can refactor your code but not change it drastically cause of these rules.
> 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
[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:
------------------------------------
{quote} since xwiki is dynamic it needs to control what was injected before to be able to update which is not in Spring/Guice/CDI as basic features (always done through proxies and as an internal bean impl).{quote}
In XWiki we do lazy instantiation of components, i.e. we instantiate them when they are required (ie. when the ComponentManager.getInstance() is called or when a component needs to be injected in another component). However we do not control what was injected before. FTR XWiki only supports field injection. Thus if you register a new implementation of a Component role at runtime, all existing components that have been instantiated already are not modified. However when a component needs to have an aways up to date @Inject(ed) field, we use a Provider<> and the code using it calls get() on it to return the latest registered component instance from the Component Manager.
BTW thanks for your replies! :)
> 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
[JBoss JIRA] (CDI-114) Allow registration of beans at runtime
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-114:
----------------------------------------
locally yes but in term of lifecycle not sure since xwiki is dynamic it needs to control what was injected before to be able to update which is not in Spring/Guice/CDI as basic features (always done through proxies and as an internal bean impl). So concretely if you do the hierarchic solution with a custom BeanManagerAggregator then you are fine and replaced the Map from your manager but you still need a dynamic runtime design "by design" which intends to breaks the startup validation and runtime safety. (that's what i meant)
> 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
[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:
------------------------------------
[~rmannibucau] You lost me with your last reply! :) AFAIK the XWiki Component Manager does exactly what Guice or CDI do (except that it handles runtime registration of beans).
We have components both in the core and in extensions.
> 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
[JBoss JIRA] (CDI-114) Allow registration of beans at runtime
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-114:
----------------------------------------
producers are Bean so you can reuse CDI semantic (qualifiers etc) but not interceptors (until you use the factory cdi 2.0 introduces which is another part of the DIY) and other parts like post constuct etc as well (Unmanaged or equivalent). So whatever you do producers are for 3rd party integration and you keep all the work in this 3rd party. Until you add scanning and use default managed Beans you will not benefit of all CDI but just a subset like contexts, light lifecycle (produces/disposes), integration with other beans etc...
Also it is unclear to me how CDI would fit your need since you have components but generally in extensions only and a set of selectable component depending a key where CDI will not help much (you still need a custom lookup aligned on your design so CDI or not is equivalent there which the Bean is managed by CDI which is done with an inherited BeanManager solution). Also note adding at runtime Beans still requires a classloader (CDI is not doing anything there) so this solution is actually low cost for you anyway.
> 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
[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:
------------------------------------
[~rmannibucau] If we need to keep our XWiki Component Manager then there's little interest in moving to CDI since (if I understand correctly) we would be able to use the CDI features only for core components that are registered statically at application boot time (and thus have two distinct Component models depending on whether you're coding a core extension or a non-core one). We're also reducing our number of core components to the maximum as time progresses to have the smallest possible core and all the rest are extracted into extensions. We currently have hundreds of extensions and this will grow even more in a very near future. So having 2 models is not a good idea IMO :)
{quote}but producers generally means 'do it yourself'{quote}
I don't understand this part. AFAIK you can use CDI constructs in producers, using injections, qualifiers, etc. Aren't there plenty of CDI apps that use producer constructs too without requiring to implement a Component Manager that would handle instantiation/injection? If the object created in the producers requires to be injected other beans, CDI doesn't provide any helper for that?
Thanks
> 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
[JBoss JIRA] (CDI-114) Allow registration of beans at runtime
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-114:
----------------------------------------
If you know the type you can surely sort it out with producers but producers generally means 'do it yourself' which would lead to keeping the component manager more or less. However an extension can produce any bean based on a qualifier (see https://gist.github.com/antoinesd/3097661ca99fa61900fb but instead of Object you can use the xwiki-api/interfaces). Issue allowing runtime registration is you would need to reboot the container more or less bypassing the scanning only to validate injection points and to reinject all created beans to ensure the consistency. It is a lot of work and overhead at runtime for not that much gain since a manager is easy and fast for this kind of dynamic registration - even with subclassloaders. Hope this makes some sense
> 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
[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:
------------------------------------
[~rmannibucau] I think xwiki component == cdi bean. Basically an XWiki component has a lifecycle (instantiation, injection, disposal) managed by the XWiki Component Manager. The goal of of using CDI for us would be to drop our Component Manager in favor of CDI (I guess it's the Bean Manager in CDI parlance but I'm a newbie so I could use the wrong terminology).
Regarding the scripted macros, it's a special case. The way we handle this now is that the XWiki Component Manager has two ways to register a new component: by passing a Class/Type and it would instantiate it itself or by passing an existing instance (in which case, it'll not perform the instantiation but it'll still perform the populate/injections). As you mentioned, I guess that the equivalent in CDI is the Producer strategy.
> 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
[JBoss JIRA] (CDI-114) Allow registration of beans at runtime
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-114:
----------------------------------------
[~vmassol] don't you mix xwiki component and cdi bean? a macro is not a Bean generally until you generate a custom class at runtime which in any case doesn't need CDI no? The producer option would still work but is still overkill to handle wiki macros since there is a manager in xwiki, no?
> 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