Help

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

18 comments:
 
22. Sep 2009, 08:56 CET | Link

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

ReplyQuote
 
22. Sep 2009, 21:25 CET | Link
Wangliyu
Even Spring doesn't direct support JSR330, I think Rod Johnson was trying to ruin whomever tried to compete with Spring.

Anyway, good to see the progress, hopefully it can catch the JEE6 release.v
 
23. Sep 2009, 00:04 CET | Link
Ravi

SpringSource and Google co-submitted JSR 330

 
23. Sep 2009, 02:14 CET | Link
coredump

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 spec that no one follows to JCP at the point JSR 299 is about to finalize?

 
23. Sep 2009, 06:22 CET | Link
genman

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 psuedo 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 @NormalScope.

 
23. Sep 2009, 06:51 CET | Link
Bob Lee

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.

 
23. Sep 2009, 07:19 CET | Link
genman wrote on Sep 23, 2009 00:22:
Looks like 299 is using @Inject, @Named, and @Qualifier. But not javax.inject.Provider ... I think @Produces is much more useful anyway.

Provider is supported. javax.enterprise.inject.Instance extends it.

Was @Scope the old name and @NormalScope the new name for 299?

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

 
23. Sep 2009, 20:01 CET | Link
Siarhei
Gavin King wrote on Sep 23, 2009 01:19:
genman wrote on Sep 23, 2009 00:22:
Looks like 299 is using @Inject, @Named, and @Qualifier. But not javax.inject.Provider ... I think @Produces is much more useful anyway.
Provider is supported. javax.enterprise.inject.Instance extends it.
Was @Scope the old name and @NormalScope the new name for 299?
@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?

 
24. Sep 2009, 18:42 CET | Link
aeig
genman wrote on Sep 23, 2009 00:22:
It's somewhat unfortunate the naming. @ContextScope/@ContextualScope might be a better name than @NormalScope.

+1 What the hell is a 'normal' scope.

 
11. Nov 2009, 04:49 CET | Link

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 a name to a bean. As I see now, @ManagedBean has no advantages over @Named and is useless.

 
11. Nov 2009, 05:04 CET | Link

Agreed, @ManagedBean is more or less useless, unless you want to be able to obtain the bean from JNDI.

 
11. Nov 2009, 05:04 CET | Link

P.S. I argued for dropping @ManagedBean but the EE spec lead wanted to keep it.

 
11. Nov 2009, 14:00 CET | Link
Nik

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?

 
11. Nov 2009, 14:37 CET | Link

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 beans, and have all the other EE specs base their component models on this basic bean 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.

 
11. Nov 2009, 15:22 CET | Link
Nik

Now I haven't read the source code of any EJB containers but I used to think it was some Black Magic Business-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.

 
11. Nov 2009, 15:46 CET | Link

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 component environment injection stuff: @EJB, @Resource, @PersistenceContext.
  • the XML deployment descriptor: ejb-jar.xml

The other stuff is all more or less easy:

  • session beans with local interfaces and synchronous methods
  • container managed transactions and bean managed transactions
  • declarative and programmatic security
  • interceptors (CDI containers already have this)

You don't have to implement:

  • message-driven beans
  • asynchronous methods
  • timers
  • remote interfaces
  • web service endpoints
  • legacy 2.x/1.x features
 
11. Nov 2009, 15:48 CET | Link

(Of course, you might want to throw in async methods and timers in version 1.1 cos they're, well, really useful.)

 
11. Nov 2009, 20:43 CET | Link

JNDI binding certainly seems magical ;-)

Post Comment