Thanks Craig.
At the risk of straying from the subject a bit--I am curious about the JSF bean lifecycle management and why the current strategy was chosen. In the EJB lifecycle, the container manages a pool of scope-agnostic beans that are brought into session on use. The reason for this choice (apart from service interception), I assume, is to obviate the creation (and gc) overhead of new EJBs.
Is there a particular reason that JSF doesn't take this approach (with a jsfActivate() and jsfPassivate() to replace constructor/finalizer semantics)? Isnt the creation/gc overhead of a webapp equal to (or greater) than an EJB app (considering that a page could be requested many more times than EJB calls that it subsequently generates)? I believe that other web frameworks (like Jakarta Tapestry) take the pooled bean approach.
Nothing stops you from implementing pooling on your own ... but I've seen a lot of cases where pooling gets in the way, too. For example, in JSP 1.1 custom tag instances were pooled, but they were lightweight enough that it just got in the way of performance when the object create/GC behavior of JVMs improved. Therefore, in JSP 2.0 simple tag instances are no longer pooled.
JSF is primarily focused on being the foundation for the UI tier ... so the "backing beans" you tend to write as adapters from the presentation tier to the model tier tend to be light weight enough that pooling would have a similar lack of benefit (and perhaps would even hurt performance). Pooling makes sense on the more heavyweight objects, and I'd look to my EJB server to help on pooling those, rather than the front end framework.
(In EJB3, you'll also find it beneficial to design your business objects with a more lightweight touch, however, because the amount of work the container has to do is substantially smaller.)
Are there any plans in future JSF releases to adopt something like this? I would strongly endorse it as a JSF and myfaces user; our beans are already taking significant performance hits due to the complex nature of the business logic, any help from the stack would be helpful.
In JSF 1.2, which is part of Java EE 5, you get the benefits of resource injection from the container into managed beans, and support for the common JSR-250 annotations (such as @PostConstruct and @PreDestroy) for free. There was no reason to include them explicitly in the JSF spec -- at least when you're running in a EE 5 container like Glassfish.
In the JSF 1.1 mean time, or with JSF 1.2 in a non-EE5 container, you can get post-construct and pre-destroy semantics from the Shale[1] framework (specifically, the init() and destroy() callbacks), plus two other lifecycle events (preprocess and prerender) that are particularly useful in webapps. ... you can get these callbacks via either implementing the ViewController interface, or using Shale-supplied annotations if you're running on Java SE 5. In the latter case, you get managed beans configuration via annotations as well.
Craig
[1] http://struts.apache.org/struts-shale/
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Craig McClanahan
Sent: Monday, 26 June 2006 10:16 AM
To: MyFaces Discussion
Subject: Re: managed propertiesI choose scope for a managed bean just like as for any other bean in a Java based webapp ... if the information is specific to a user but longer lived than a single request, I use session scope. Otherwise, I generally use request scope to avoid multiple instantiations of the same bean.
Spring 1.x didn't support "request" or "session" scope directly ... I'm glad to see they are adding a way to do that in 2.x.
Dhanji.
Craig
This correspondence is for the named persons only.
It may contain confidential or privileged information or both.
No confidentiality or privilege is waived or lost by any mis transmission.
If you receive this correspondence in error please delete it from your system immediately and notify the sender.
You must not disclose, copy or relay on any part of this correspondence, if you are not the intended recipient.
Any opinions expressed in this message are those of the individual sender except where the sender expressly,
and with the authority, states them to be the opinions of the Department of Emergency Services, Queensland.
