Did you know? DZone has great portals for Python, Cloud, NoSQL, and HTML5!

Robert has posted 1 posts at DZone. View Full User Profile

@Inject and JSR-330

10.07.2010
Email
Views: 1344
  • submit to reddit
Subheadline: 
And my implementation of this JSR
I was very impressed by the CDI specification and the addition of the JSR-330 so that all IoC/DI products can play nice (EJB/Guice/Spring etc.). I had some ideas for extensions of the Guice framework once they supported these annotations. But the 2.1 was never released and after some investigation I found the JSR-330-TCK and it was done with plain JUnit so i could not resists trying to implement that, the rest is history.

 

Why is the JSR good:
- It makes the IoC/DI code independent of the vendor. (The only thing left thats vendor specific code is configuration and thats a limited area of code)

 

The following things have been done:

 

1. @Inject framework
An implementation of the JSR-330 specification. I know its light but that's what I want and for most parts that's all I need.
As soon as Guice 3.0 is released I will move the core framework to be based on this instead. But the most important part for me is the usage of the java.inject.@Inject.

 

2. @Inject Extensions (things built on the @Inject framework and its easy to use configuration support)

 

2a. Transactions (BETA), with EJB annotations and AspectJ
- Has JPA Managed Transaction
- Has JDBC Managed Transaction
- Has JUnit support (Runner)
- Has cross connected JPA/JDBC transactions (it can extract the active connection from JPA provider)

 

3b. JSF (BETA), an abstract implementation of the com.sun.faces.spi.InjectionProvider
- A simple Filter setup will activate the @Inject and Transactions (open-transaction-in-view)
- Also possible to add the AspectJ version for Transaction (can be used together with open-transaction-in-view)

 

More information:
http://alexandersson-robert.blogspot.com/2010/09/jsr-330-and-inject.html
http://code.google.com/p/java-simple-utils/wiki/Injection

 

Note: A standard that is missing for the moment is the way to configure (setup) these Containers. If a standard was created for this a developer using a framework would never create code based on these products. This is a quick wishlist that I can come up with.
Or am i missing something? Have not read all details for the CDI specification (mainly JSR-299) but i think config is vendor specific even here. I small wishlist from me for this would be to standardize.
- Package scanning with exclude/include handling
- Single item addition
- Module handling (a package of scanning and/or several single item's)
- FactoryInterface for legacy code produced instance management
- Java Config / XML Config (i prefer Java though)
Location: 
Sweden
0
Published at DZone with permission of its author, Robert Alexandersson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)