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

[Vincent Massol (Commented) (JIRA)]

    [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643249#comment-12643249 ] 

Vincent Massol commented on CDI-114:
------------------------------------

{quote}
Actually not supporting beans which can dynamically change at runtime is a BIG benefit. 
{quote}

What this means is that CDI will not have the future I imagined (i.e. be the standard Component framework that becomes the standard reference). Because by this statement you're telling everyone who has a need for dynamic registration to go away. What you're doing is actually moving the people to OSGi or other such frameworks (I'd be curious to know how you position CDI vs OSGi/Jigsaw for the future - they seem to fill the same overall need for me and I'm not yet sure we'll need to have several).

Of course it's easy to be fast when you don't do much but if your use case isn't covered that doesn't help you much... :)

FTR here's an implementation we have done for XWiki:
https://github.com/xwiki/xwiki-commons/tree/master/xwiki-commons-core/xwiki-commons-component

More specifically the default Component Manager implementation we have is here:
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-default/src/main/java/org/xwiki/component/embed/EmbeddableComponentManager.java

Of course our implementation has some consequences on performance since we instantiate components lazily and and since we have a singleton lifecycle we need to use ConcurrentHashMap and have some synchronized blocks. This is also needed for dynamic component registration.

I have no figure to show about OSGi perf but it probably is less performant because of its dynamic nature. However it doesn't seem to me that it's preventing people from using it. I think that vast majority of applications (let's say 99% for the sake of arguing ;)) would be just fine with the small overhead that synchronization brings. Now I also agree that 99% of apps may not need dynamicity ATM (although I think more and more will want it as time passes and apps become more complex). It's just a pity that CDI isn't a more generic Component framework.

Anyway for the XWiki project we have our own implementation for now for lack of a standard solution. I would have liked to see CDI being that solution but if it doesn't support dynamically adding beans it won't work for us.

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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira