Dynamic registration of beans?

[vmassol]

Hi,

I'm discovering CDI and it looks very nice. I'd like to move from our custom component injection framework to Weld but our framework supported dynamic registration of components (aka beans in CDI).

I found the ability to dynamically lookup beans and the ability to register beans at startup (using AfterBeanDiscovery's addBean()) but I haven't found a way to dynamically register a bean. I've seen that BeanManager can be injected but it doesn't seem to have a method to register a bean (unless I have misunderstood something).

I'm also interested if anyone has thought about how to implement CDI over OSGi and whether this would be doable or not.

Thanks a lot
-Vincent

[ukyovirgden]

The reference implementation of CDI, Weld runs on the reference implementation of Java EE 6 container Glassfish v3. GF v3 is OSGI based.

[vmassol]

Thanks Ukyo. Do you know how to perform dynamic bean registration in CDI/Weld?

Re OSGi my understanding is that Weld has an OSGi bundle but this is different from using CDI over OSGi.

[ukyovirgden]

You're right. I didn't come across or think about a use case or need to do so. So you want to make a bean available to CDI context(s) dynamically controlled by the OSGI container. Can you elaborate a litte?

[vmassol]

I'd just like to be able to dynamically register a bean with the CDI container.

Here's a concrete use case we have in XWiki:
* I have a Macro interface (interface to for a bean implementation)
* Users can create macros in wiki pages by entering some script
* When the user saves a wiki page containing a macro, we dynamically register a Macro implementation against the container so that it's then available to other code as any standard macro

Right now we're using our own component manager to do this (in case you want some details: http://code.xwiki.org/xwiki/bin/view/Modules/ComponentModule) but I'm interested in moving our component model to CDI if it can support the dynamic registration/unregistration use case.

Thanks again

[nickarls]

I don't think CDI supports dynamic addition of beans but if you use Weld and portability is not a primary issue, the BeanManagerImpl has an addBean method (not that I've really tried to add anything mid-flight)

[vmassol]

ok thanks Nicklas. That's what I was fearing.

Do you know if JSR299 authors had injection framework with dynamic capabilities in mind when they created the spec? I read they had Spring, Guice in mind (I think that's what's mentioned in the spec) but they didn't mention other framework such as Plexus, OSGi, or even Guice/Peaberry for example which have these dynamic capabilities.

If they did, it means they rejected the ability to dynamically add bean and I'd be curious to know why. I've been doing that in XWiki for some time now and I haven't seen any adverse effect and it was quite easy to implement, so I wonder what could be the problem... (they are synchronization stuff to handle but that's true for singletons too anyway).

Thanks again

[nickarls]

I'm not sure about the reasons. I guess adding the stuff mid-flight would have to cause a re-evaluation of all resolutions since it could cause ambiguous resolves and stuff.

Do they have to be real CDI beans in the full sense? Can they be wrapped in some other construct?

[vmassol]

They have to be real CDI beans in the sense that they need to be able to be referenced and injected into other beans (using @Any and Instance for example).

I've explained one use case that we already have above. Here's another one for the future (and this use case is the reason I was mentioned OSGi above):
* Ability to install extensions (in the form of jars) to XWiki by adding them at runtime (including version resolution).

Ideally it would be great to be able to use OSGi as the implementation and CDI as the programming model. That would probably need some new annotations, for example to specify version dependencies, or OSGi service properties in general (to be able to say for ex: inject me this dependency but only for implementations with a version greater than N, or a version range). I think that part is supported by CDI with Portable Extensions. The part that doesn't seem doable yet is the dynamic registration/unregistration of beans.

I'd really like to know if the dynamic registration/unregistration of beans will be considered as a use case in the future and what is the current CDI answer for people with my use case (I fear the answer is going to be: don't use CDI and use the OSGi programming model instead. A pity since CDI really looks very nice and is a standard now. IMO there should be a path to these use cases other than "don't use CDI").

Thxs

[nickarls]

You could mail the EG and present your usecases and see if they have anything planned.

[pmuir]

Right, although the spec doesn't support OSGi, it is possible to implement CDI over OSGi with Weld (it might need some bug fixes, but I think conceptually it is possible) with the kind approach you are considering. It requires some work though - if you are interested in helping out, we should discuss it, as it's something I would like to see done!

[cjalmeida]

Vincent,

for the first use-case, you could have a app-scoped MacroManager bean where you could put/instantiate Macro classes/scripts.

As for runtime modularity (OSGI or whatever), it sounds interesting. However, for most sysadmins, repackaging and restarting the container should be a smallish concern. Development modularity however, making good use of Weld extensions, decorators, interceptors and events, that's a must.

[vmassol]

Hi Pete,

I'm still making my mind for the XWiki next-gen programming model between CDI or not CDI (i.e. keep what we have now). The only 2 things that still make me hesitant a bit are:

CDI spec is too large. It's targeted at JEE6 and not at J2SE or even Web applications (XWiki is a web app). I really don't understand why there wasn't a spec for all platforms (J2SE, JEE) and then another spec on top of it that would have added the JEE specific stuff (EJB annotations, MDB stuff, etc). That would have been so logical to me and CDI would have been an all-purpose DI standard for all java development. So since it wasn't done like this, it raises the question of whether there'll be another DI framework in J2SE in the future or not. Anyone know anything about the future of CDI for J2SE? Yes, I know that Weld supports J2SE and web apps but it's not standard since it's not in the spec.

Non support for dynamic reg/unreg if beans

Apart from this, I find the spec great in most places. We'll make up our mind in the coming few days (I'm inclined to choose CDI at the moment) and if we choose CDI then we'll use Weld and then I can work with you on the topic of CDI over OSGi.

The two domains I can see to work on right now are:
dynamic reg/unreg of beans
adding new annotations to add properties for a dependency (such as version) so that OSGi LDAP style filters can work. A bean's version could be declared in beans.xml maybe (or another descriptor).

Do you see anything else?

Thanks

[vmassol]

Hi Cloves,

"for the first use-case, you could have a app-scoped MacroManager bean where you could put/instantiate Macro classes/scripts."

How would this MacroManager register the Macro beans against the CDI engine?

This is needed since these Macro need to be considered as standard managed beans so that they can be injected normally into other code (for ex, we have a WYSIWYG editor with an insert Macro dialog box that lists all Macros available in the wiki, including these macros defined in wiki pages - the editor simply does a CDI @Inject @Any Instance<Macro> macros (the equivalent of it using XWiki's component manager)).

"However, for most sysadmins, repackaging and restarting the container should be a smallish concern."

I don't agree. Let's take again one of our XWiki use case. We have the notion of wiki farms that run in a single WAR (single webapp). The farm admin is the one who starts/stops the farm. Each wiki in the farm has its own admins who have admins rights only for their wiki parts. These wiki admins must have the ability to install/uninstall extensions for their wikis only (and not for the whole farm) at runtime. They don't have access to the farm, so they can't restart it and the farm should definitely not be restarted as otherwise you're impacting all other wikis if you just want to add an extension for a single wiki.

Thanks

[vmassol]

(pete, sorry for my answer above, I forgot to click the "let me type some plain text, not markup' in my reply above and it got mangled, Here it is again)

Hi Pete,

I'm still making my mind for the XWiki next-gen programming model between CDI or not CDI (i.e. keep what we have now). The only 2 things that still make me hesitant a bit are:

* CDI spec is too large. It's targeted at JEE6 and not at J2SE or even Web applications (XWiki is a web app). I really don't understand why there wasn't a spec for all platforms (J2SE, JEE) and then another spec on top of it that would have added the JEE specific stuff (EJB annotations, MDB stuff, etc). That would have been so logical to me and CDI would have been an all-purpose DI standard for all java development. So since it wasn't done like this, it raises the question of whether there'll be another DI framework in J2SE in the future or not. Anyone know anything about the future of CDI for J2SE? Yes, I know that Weld supports J2SE and web apps but it's not standard since it's not in the spec.

* Non support for dynamic reg/unreg if beans

Apart from this, I find the spec great in most places. We'll make up our mind in the coming few days (I'm inclined to choose CDI at the moment) and if we choose CDI then we'll use Weld and then I can work with you on the topic of CDI over OSGi.

Two domains I can see we would need to work on in order to support CDI over OSGi are:
* dynamic reg/unreg of beans
* adding new annotations to add properties for a dependency (such as version) so that OSGi LDAP style filters can work. A bean's version could be declared in beans.xml maybe (or another descriptor).

Do you see anything else?

Thanks
-Vincent