I'm trying really hard to emphasize to the community that CDI and Weld are not just a dependency injection solution
. We did not come at this from the point of view of trying to solve dependency injection
, or of trying to build a better Spring
.
What I was really thinking about when I started working on Seam was state management in event driven architectures. How can you ensure that an event is processed with the correct set of state for the context(s) it carries with it? I wanted to get away from the awful front controller
pattern, where some big stupid stateless method is responsible for coordinating everything involved in processing the event, from state retrieval and storage, to service location, to orchestration.
There were a couple of frameworks which were ahead of their time in this respect. The one that got me started was XWork, a dependency injection solution that was part of earlier versions of WebWork. That's why I was kind of excited when I saw the same ideas in JSF (setting aside many other problems with JSF 1.0).
It's also why I pushed back so hard when some people questioned the existence of the event notification facility in CDI. Though it appeared to some folks to be a kind of cute feature stuck on the side of a dependency injection container, that's not what it was to me at all. Indeed, the idea of event processing was right at the core of what we were trying to achieve in JSR-299.
If It's not about DI, why the hell 66% of is ?
@Alex: Don't forget JPA2 and Validations! :)
Well, if Java EE would be build from scratch there would probably have been something like a spec which would specify how qualifiers, stereotypes and resolution works and on top of that would be , , etc which would all build on the first spec. I assume that since 299 was a bit late (better late than never), this was the one opportunity to squeeze in whatever goodness that could be had ;-)
Because that's the name that other JCP members wanted us to use as a condition of their support for the spec and its inclusion in the EE platform. We're hoping that most people will read further into the spec than the title.
Well, JSF2 was released a while ago. Hibernate Validator 4 (the Bean Validation RI) just went final recently. Weld will go 1.0 sometime this month. Hibernate 3.4 is already in beta, so I guess you can start considering it for use in development.
Seam3 and RichFaces4 are somewhat further off, since we're just getting started on development now. However, as far as I know, RichFaces3 will still run on JSF2 (someone let me know if this is not the case!), and we should be able to have some of the most important components of Seam2 ported over to CDI quite quickly. Note that Seam3 does not really need to be a release. We can deliver the individual components incrementally.
So, it's quite possible that you'll be able to start using the new stack for development sometime this year.
In fact, so many features of Seam made it into CDI and JSF 2 that if you just dropped an empty jboss-seam3.jar into an EE 6 server you would just think that stuff was renamed ;-)
I mean Hibernate 3.5.
Nevertheless the majority of CDI users will use it as a DI framework. Additionally I think that the DI part of Weld is the best way to get started with it.
I have been a long time user of Spring, although my interest in Spring is slowly diminishing. In the beginning it was great because using some configuration file, you could see how the objects of the system are glued together (even though XML isn't the nicest language to program in). But with the introduction of all the annotations/auto-wiring options DI has lost a lot of value in my opinion.
If I want to understand a system that uses annotation based DI, I need to look at all the Java sources again to see how components interact. Perhaps I'm the only one suffering from this problem.
Since any archive that deploys is wired unambiguously, tooling should be able to generate a graph for you
Right, this is exactly the kind of thing that tooling can easily do...
I'm indeed extremely surprised that absolutely noone in any early review of the specification has ever talked about the event / observer concept of JSR-299. It seems to me that it's a far better way of building loosely coupled components than any kind of dependency injection. I also wonder why the specification does not include asynchronous events, maybe it will be a Seam extension.
Asynchronous events was present at some point, they will probably re-appear as an extension at some point. Using events instead of DI is a bit of too loosely coupled for my taste. And would probably lead to a lot of interesting stuff such as exception handling etc...
Yep, async events and JMS event mappings can be implemented as a portable extension.
RichFaces 4 is in Alpha now, correct me if I'm wrong. Obviously still some work to go but everything shy of Seam 3 is available for the adventurous, it seems. :)
http://www.jboss.org/richfaces/download/milestones.html
RichFaces 3.3.X extended the core of JSF 1.2 in order to implement some of its features. This resulted in some integration issues with JSF 2. These are being investigated and RichFaces 3.3.3 ( due out end of year ) should have basic JSF 2 compatibility. We'll have a wiki to define any remaining issues.
RichFaces 4.0 is farther off as Gavin suggests. It is hard to nail down an exact date, but an ALPHA is available with 8 components.
- Alton Brown, Good Eats
If by DI we're just referring to the @Inject tags then yes it's definitely a small part of it. We can get by with just using Component.getInstance() or whatever CDI's equivalent is.
After using Seam, it feels to me that it's more about the contexts and the flexibility in how they manage the lifecycle of the components they contain (like the EntityManager).
Event notifications have saved me from the hell of compounding complexity every time I need to add a new component which may or may not have effects on other components (sorry Web beans) in their scope. When adding component x plus 1, it's terrible to have to go out to x other components to add references to this new component as well as all the 'observer' calls. It adds up, and Events notifications help avoid this problem.