I've just submitted a revised PFD[1] of JSR-299 (now named Contexts and Dependency Injection for the Java EE platform) to the JCP. There are four notable changes in this revision:
- re-use of dependency injection annotations defined by JSR-330
- replacement of the notion of deployment types with the new @Alternative declaration
- removal of the ability to dynamically register event observers
- constructor injection for EJB session beans
The biggest change from a user point of view is that the @Inject annotation is now used to declare bean constructors, initializer methods and injected fields.
I would like to thank Mike Keith from Oracle for his work on alignment of JSR-330 with JSR-299.
Work on the 299 RI and TCK is moving extremely rapidly, and we hope to have a release of the RI that implements PFD2 in a couple of weeks. And before the end of the year you guys should see the release of the at least two application servers with built-in support for 299. (The first application server with built-in support for 299, Resin 4, is already available.)
| Attachments: | ||||
|---|---|---|---|---|
|
JSR-299-PFD2.pdf (JSR-299-PFD2.pdf, 532 KiB, application/pdf) |
Since the first version submitted to the JCP, every draft has some siginificant changes compare to the ealier version. However, as a developer I am very glad to see the evolution of JSR 299, JSR 330 and some else from unstable to stable.
Anyway, have a good day :-)
Anyway, good to see the progress, hopefully it can catch the JEE6 release.v
SpringSource and Google co-submitted JSR 330
You are right, Rod Johnson is the co-author of JSR330, but so far I don't see spring support it (even in Spring3.0Mx), and there is no RI and TCK for that. What's the purperse of propose the that no one follows to JCP at the point JSR 299 is about to finalize?
Looks like 299 is using @Inject, @Named, and @Qualifier.
But not javax.inject.Provider ... I think @Produces is much more useful anyway.
Was @Scope the old name and @NormalScope the new name for 299?
Calling @Scope is also unfortunate, as it is really a scoping designation but has different meanings in 299.
It's somewhat unfortunate the naming. @ContextScope/@ContextualScope might be a better name than .
Provider and @Produces have nothing to do with each other. You use Provider to get instances from the injector. You use @Produces to provide instances to the injector.
Provider is supported. javax.enterprise.inject.Instance extends it.
@Scope is defined by 330, and has 330 semantics (the semantics of a 299 pseudo-scope). @NormalScope is defined by 299 and has the semantics of a 299 normal scope.
Wow, that's a lot of changes, guess I'll need to re-read the spec again. Is there a version with marked changes (to se the difference)? Or is it changed so much?
+1 What the hell is a 'normal' scope.
What does it mean for overlap between common annotation update including the ManagedBean annotation that marks a bean that needs DI and lifecycle Management and the @Named annotation wich as far as i have tried also support @PostConstruct, @PreConstruct and duh ... dependency Injection. Shouldn't the @Named just add to . As I see now, @ManagedBean has no advantages over @Named and is useless.
Agreed, @ManagedBean is more or less useless, unless you want to be able to obtain the bean from JNDI.
P.S. I argued for dropping @ManagedBean but the EE spec lead wanted to keep it.
Do you see that at some point, the EJB and CDI containers will be merged so that EJBs per se no longer exist, we have stateful or stateless POJO:s with scopes/contexts, interceptors and everything else in one single container?
Nik, I plan to blog on this topic soon. But yes, at least some of us beleieve that the direction of the managed beans, CDI, interceptors and EJB specs is to make the services traditionally defined for EJB components be available for all , and have all the other EE specs base their component models on this basic model.
More immediately, I think it would be interesting to explore implementing EJB Lite as an extension to CDI, rather than as a cut-down version of a complete EJB container.
Now I haven't read the source code of any EJB containers but I used to think it was some -code but after getting to know Weld more, I would be surprised if was that different or that much more complicated...
It would be nice if the circle would be completed and both POJO:s EJB:s would take the form of some Contextual Managed Bean which would enjoy all the services and functionality that once was EJB (or CDI) bean only.
Look, I would be willing to bet that some EJB containers do contain some very scary and magical code. But I don't believe that it's really required to implement the spec. I mean, if you look at what's in EJB Lite, there's nothing really very complex there at all. You could just about do it as a CDI portable extension.
The toughest stuff to implement in EJB Lite would be:
The other stuff is all more or less easy:
You don't have to implement:
(Of course, you might want to throw in async methods and timers in version 1.1 cos they're, well, really useful.)
JNDI binding certainly seems magical ;-)