I'm a beginner with JSF2, actualy i did not write a single aplication with it, only JSF 1.2 with a some frameworks. Just reading for a while. I Have a simple question what can solve a lot of problems without using spring or seam frameworks:
With a fully JEE 6 Application Server and JSF 2 can i use DI with my EJB's on ManagedBeans?
I must admit I don't know all the details but it depends a lot on the degree of component management you expect from the platform. With the new version 6 it's also possible to make plain Java classes injectable. On the other hand there are restrictions you have to know about, for example the specification doesn't allow to inject stateful components into stateless ones - in this case JNDI lookups should be used.
Perhaps someone with deeper knowledge can explain it in more detail
Joined: Mar 06, 2009
Marco Ehrentreich wrote: for example the specification doesn't allow to inject stateful components into stateless ones - in this case JNDI lookups should be used.
Thats make much sense.
Do you know some references do indicate? I would like to read it, actualy i'm doing a feel researches today.
but if i find something interesting i'll post here.
This would be nice!
A really good book I recently read is Real World Java EE patterns. It's not exactly a reference guide but it definitely shows a lot of real world use cases for JEE 5/6. It's in particular interesting if you have some knowledge about designing business applications in general or with other frameworks.
Although it sounds like a great way to reduce complexity, it's usually not all that feasible to use EJBs as managed beans, simply due to lifecycle differences. I think that's what you're really asking. There are 3 major problems:
1. Differences in lifecycles. Saving and EJB that's a managed bean can be challenging. Refreshing a detached EJB can be really challenging.
2. Conflicts with controllers. For example, a lot of commercial databases don't support native Boolean datatypes. Unless the persistence mechanism steps into the breach, you'll find it difficult to bind a JSF selectBooleanCheckBox to a numeric or character "boolean" property.
3. Extra-curricular requirements. For example, action processors, JSF datamodels and other stuff of that nature really shouldn't be part of an EJB, and in fact you're doing yourself major harm if you create EJBs that reference javax.faces resources. That makes them practically useless for anything but webapps, and one of the advantages of ORM is that you can use the same code for backend batch processors and other non-web functions as you do in the webapp itself.
I use Spring/JSF to inject JPA dataservice objects into JSF managed beans all the time. Most commonly my backing beans either present a façade for the actual datamodel object or contain one or more datamodel objects as properties. I don't usually use DI for this, though, since DI is a construction mechanism and my datamodel objects are usually changed in and out.
In summary, although it usually demands more source code files to NOT inject EJBs into managed beans (or use them AS managed beans), you actually get a more maintainable app if the backing, business, and data tiers remain distinct. When a function can move up and down in the tiers depending on usage, it leads to "treasure hunts", and that not only wastes time, but you always have to worry about whether you're invalidating the conditions that made it possible to "cheat" on the layering process.
An IDE is no substitute for an Intelligent Developer.
Note that the minimum requirement for JSF2 is a Servlet 2.5 container. Of course, in this environment you don't get the benefits offered by the EE6 stack such as CDI, EL Method invocation with parameters, and simple Bean Validation integration. On the other hand, the javax.faces.bean.* package was included in JSF2 specifically to enable the base support of managed bean dependency injection for the Servlet 2.5 use case of JSF2.