After hearing more about EJB 3, and talking to various people, why are we putting dependency Injection semantics in an EJB spec?
I can see one reason: “Let’s just get EJB 3 done”
This is a reason for not splitting the persistence API into a truly seperate JSR (although it IS mean to be a seperate spec/tck/runtime).
Dependency injection is a very generic concern, and one that should be shared throughout a bunch of specs. One tiny JSR could flush out the semantics
of dependency injection, and end up with javax.dependency.*.
Then EJB 3 would specify that “When you @Inject a transaction manager…. you must do X”. A future Servlet spec could do the same thing for their resources, etc etc.
Also, lightweight containers would have the option of groking these annotations too, without needing some ejb.jar.
Wouldn’t that be nice?
December 18th, 2004 at 6:06 am
The problem is, apart from saying ‘use POJOs with constructors or properties and the odd annotation here and there’, there’s not a whole lot to put in the DI spec :).
Maybe the DI spec is gonna be the JSR which tries to standardise common annnotations? (Not that we need annotations for DI)
December 18th, 2004 at 8:08 pm
God forbid a small spec ;)
May 28th, 2006 at 7:17 am
Free Gay Ass Galleries http://GayAss69.servik.com/
November 7th, 2008 at 1:29 am
http://www.batteryfast.co.uk/hp/dv1000.htm hp dv1000 battery,
November 13th, 2008 at 6:48 am
http://www.batteryfast.co.uk laptop batteries
November 17th, 2008 at 1:57 am
dell inspiron b120 battery