Phase Listener for a Specific Managed Bean

[Mani Natrajan]

Hi,
Is there any way by which i can associate a phase listener to a specific managed bean.
I want to listen to the events of only one managed bean in my project.
Is it possible to achieve this?

Thanks
Mani Natarajan

[Tim Holloway]

I think that this is one of those cases where you're thinking about a specific technological solution too soon.

What specific benefits do you expect to see by doing this? What does the bean do in a purely business sense that makes you think that a phase listener is even appropriate as a solution?

[Mani Natrajan]

Thanks for the response.
I have a bean in request scope and have to redirect to an error page when the bean does not have proper values (they are found if they are proper from a bean in application scope, where i have data cached).
I need to do this check after all my bean (bean in request scope)properties are set. So I of thought phase listener being an appropriate solution for this.
Initially I did this check in the @PostConstruct method, but it was too late to redirect then. (It showed the current page and only then redirected to the error page).
Do you think there is a better solution for this other than using a phase listener?.

Mani

P.S I am working on an already designed project and not desiging a new one.

[Tim Holloway]

Well, let me see if I can figure out what you're attempting.

Are you saying that you have a page that references a request-scope bean that's created by cloning data from an application scope bean? And that, if the application-scope bean's data isn't valid for that request that you want to instead display an error page? And that throwing a FacesException in @PostConstruct is too late, because the page is already rendering?

Probably the cleanest solution is to check BEFORE routing to that page in the action processor that sets the new page and its new request object up. If the data isn't valid for the request, redirect the action directly to the error page. Plain-vanilla JSF, no special magic required.

That, of course, doesn't work if someone attempts to access the request-bean page via direct URL request. For a case like that, I suppose that one approach would be to use a Filter and verify the session bean data in the Filter. Redirect the URL if the verification fails.

Access to the actual request bean isn't necessary, since beans aren't directly addressable in any case, and especially at request scope where they have no existence outside the URL request/response cycle. Although I might put a static validation method in the request bean if it makes sense from a "keep-everything-together" point of view.

Another approach, if you're looking for wiring flexibility would be to inject the application-scope bean into the request bean, have the setter verify the required properties, and throw a FacesException if the properties don't fit.

You very probably will see an undesired URL returned to the client's navigation bar in many of these cases along with the error page. A solution for that is to subclass FacesException and create a custom error page (which is better than a standard stack trace, anyway). That page would then have a link back to the application mainstream. It won't fix the URL, but the important part from the user's point of view is that the application will have a smooth flow of control and not be thrown into esoteric technical displays. And, if you're really obsessive about the URL, you can probably make the error page forward. But it's probably not worth the trouble.

[Mani Natrajan]

You got my point/issue excatly right.
I was more interested/inclind to this approach
"Another approach, if you're looking for wiring flexibility would be to inject the application-scope bean into the request bean, have the setter verify the required properties, and throw a FacesException if the properties don't fit. "

I already have my application bean injected in my request bean , the reason why i could not follow it is because:

In my request bean i have two parameters and this bean can accessed from the calling bean in two different ways.
The first case sends only the first parameter and the second case only sends the second parameter.
So i had to look for a place after both the set methods are fired to write my little validation and that made me look out for other options.

I got a new thought now, i will split my bean in to two and call different beans at different times from my calling bean depending upon my case.
In this case i can throw a business expcetion from my setter and redirect to the error page.

Thanks
Mani

[Tim Holloway]

That's probably the cleanest way to go. Backing beans are best implemented as view models in their own right. Too many people try and do things like force backing beans to be domain model objects. Keep it simple and even if you end up with more classes, they'll be less expensive to maintain.