[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ] Cloves Almeida commented on CDI-114: ------------------------------------ I remember the thread and the general case is supporting scripted beans (injecting into them, injecting them into others). Most large enterprise apps one day or another can really benefits from scripting. It might be out of scope of CDI 1.x, but script support is something to be taken into account in the future. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ] Cloves Almeida commented on CDI-114: ------------------------------------ Yes, but as a scripting language where the class can be updated without redeployment/restart. Guys at JBoss have been doing some JRuby/Weld integration (http://bit.ly/fz4Bgq) Yet, it does not allow a JRuby class act as a managed bean among other features. Their use case was fast front-end development cycle. Adding a bit of dynamic behavior through a SPI wouldn't hurt the spirit of CDI as much as the inclusion of the Reflection API didn't make Java developers overuse unsafe invocations. Anyway, it sounds hard to implement and maybe should be first implemented as an extension to Weld before becoming part of the spec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ] 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/xwi... More specifically the default Component Manager implementation we have is here: https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwi... 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 -- 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

[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-114: ----------------------------------- Btw, OSGi is a perfect sample why to NOT allow _all_ things to get changed dynamically. How often did you manage to install/update a new plugin without having to restart Eclipse? Most of the times you update Eclipse 10 times and it even doesn't start anymore... -- 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

[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-114: ----------------------------------- Hi Vince! Will need to sleep over it, but currently this looks more like a 'hot redeploy' than a real 'dynamic Bean' change. The problem with allowing to add dynamic Beans is that they e.g. can also 'disable' other Beans, change Interceptors, Decorators, etc. So by adding one Bean, you might in the worst case change the behaviour of all the application. Another area which we need to clarify: what happens if a definition error occurs as result of adding such a new bean? It would also be very hard (or close to almost impossible) to guarantee the behaviour of previously serialized beans. I'm not saying that it's impossible, but we must really think about the consequences and how to cope with them. -- 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

[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-114: ------------------------------- I'm very reluctant to allow dynamically defined beans. If we did, it would really be CDI2 not CDI 2.0 (completely different non-backwards compat design). If the CDI container can restart fast enough, there is no real difference between dynamic beans and restarting the container. Of course, you don't want to restart the whole app as you loose session state. I'm talking about *just* restarting the CDI container. -- 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