JBossDeveloper

I would be surprised if there ever would be another DI framework for the Java platform. I think the foundation is solid and future revisions of the specification can expand it.

If the platform would be built from scratch without any political needs, there would probably be Managed Beans and the typesafe resolving and injection at the core. Then EJB would build on top of MB and events, interceptors etc on top of those. And everything would be usable everywhere (injections in any server-generated instance).

The same goal is still reachable but due to history and political facts, things have been done in another order but I think we're getting there.

I understand that JPA was close to being EE-only, too.

Hi Vincent,

Actually I have a similar use case where I'm trying to get away from home-grown component management. In my use case, there's a script which user executes to do some business stuff. The scripting engine component binds some so called module beans to the script context in order to be used within the script, which is nothing but javascript in scripting api in SE 6. In my case I want to manage the modules with CDI because they are stateful AND contextual to what the user is doing.

I don't want to question your requirements but I was looking to CDI in order to get rid of doing component management myself.

The only requirement which would make sense for me to use OSGI is to dynamically change the bean that is being used by the scripting engine, meaning dynamically determine or swap the already injected bean. Which for now I can leave without.

Vincent Massol wrote on Apr 13, 2010 08:48:


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.

Yes, we would have liked to have standardized this model for Java SE as well as Java EE. But others in the JCP don't always share our vision. I can say that CDI is likely to gain a standalone standardized bootstrap in an upcoming maintainence release of CDI - this will allow it to be bootstrapped (in a standard) inside plain Java SE. With this, writing a portable version of Servlet becomes much easier. Probably as part of this the spec will make it clearer what parts of the support are targeted at Java EE only.

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).

I agree, this is what I see as being needed. I think we can do the support in two phases. IMO with your first point the support is pretty usable, so we should work on this first. The versions stuff can be added (as it is very useful, but not critical for all apps).

Let us know whether you decide on CDI, and drop by IRC :-)

dynamic registration / unregistration will probably be needed for hot deployment as well

Stuart Douglas wrote on Apr 14, 2010 02:41:


dynamic registration / unregistration will probably be needed for hot deployment as well

This IMO is somewhat different problem to OSGi. It's possible the solution is the same, but we should consider this.

OSGi allows you to replace a bundle (which equates 1-1 to a bean archive in CDI, both naturally in the spec and the way Weld is written), and have other bundles which depend on it see the updated class definitions. In other words, we would want to do this by replacing the BeanManager responsible for the bundle.

With hot-deployment, the granularity could be at the class level; in this case we need to replace the bean definition (and graph of depending bean definitions) rather than the whole BeanManager. In practice, it's probably sensible to stick with replacing the BeanManager initially, and see how that works for people. This is also much better defined in terms of replacing the depending bean definitions.

I see your point. If you don't register the bean (instatiate with newInstance()), it won't be managed and within it you won't be able to inject dependencies. Sorry, the MacroManager is not a solution.