This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Whenever possible, use case 4 - POJO injection. If you'll notice, it doesn't require any specialized JSF code (annotations don't count - you can do the same thing via faces-config.xml).
By sticking to Inversion of Control POJO principles and not using framework-specific constructs, you insulate yourself from changes in the framework (The EL interface changed markedly between JSF1 and JSF2), you make it more likely that you can reuse the component in non-JSF projects, and you make it easier to test stand-alone where neither JSF nor a webapp container are running.
Note, however, that in order for this to work, you must also include a "set" method for the property which you wish to set. Otherwise the JSF framework cannot initialize the managed property, since it doesn't have any magical powers that allow bypassing normal protections for private members.
I could give an entirely separate lecture on the perils of user-defined logins, but that wasn't the question here.
Customer surveys are for companies who didn't pay proper attention to begin with.
massimo tarantelli wrote:thanks for the answer, anyway i've noticed that the 4) way doesn't work in the constructor...why? thanks
I didn't understand that. If you mean that managed property values are not available when the constructor executes, that's true. That's because the constructor is the very first thing that executes when you create a bean - you cannot apply the setUserLogin() method to an object that doesn't exist yet.
First the constructor is invoked. In JSF, this will always be a no-argument constructor as there is no provision in JSF to pass parameters to a managed bean constructor (and in any event, good JavaBean practice recommends always providing a no-args constructor).
Then the Managed Properties are set to inject values into the newly-constructed bean. It is good practice not to assume that these setter methods will be called in any particular order.
Finally, if the system supports it, the @PostConstruct method will be called, if one is defined. At @PostConstruct time, the bean has been fully constructed and all managed properties have been set.
After PostConstruct time, the bean can be used generally with confidence that it is properly initialized. Views can set/get properties, action methods can be invoked, and so forth.