My question is quite simple (to ask). How can I create and manage my Exceptions in a JSF application?
First we have the separation from normal and Ajax requests.
Problem solved by using FullAjaxExceptionHandler by Omnifaces.
Ok, now my Ajax exceptions follow the JSF/web.xml path. Next step is to create the mappings in web.xml:
<error-page>
<exception-type>java.lang.SecurityException</exception-type>
<location>/errors/security.xhtml</location>
</error-page>
The problem then is that Exceptions are not going to match above rules as they have been wrapped by other Exception types.
Ok, Omnifaces to the rescue again with FacesExceptionFilter.
Ok, so now I can throw Exceptions from my beans, e.g.
#PostConstruct
public void init() {
throw new SecurityException("Go away!");
}
Unfortunately this won't work, because Exception is thrown during bean initialization and not when calling a method.
Omnifaces unwrap method will stop to the occurrence of aFacesException and CDI (Weld) will wrap any exceptions during Bean initialization to a FacesException (which I assume is conforming to the spec).
I could write my own Exception filter that will not stop unwrapping a FacesException, you quickly realize that you might go deeper in the stacktrace than one would like.
How can I manage Exceptions during Bean initialization?
The managed bean creation and initialization is not supposed to throw an exception in first place.
You'd better move this security checking logic elsewhere. E.g. a real security framework (container managed via JAAS/JASPIC or 3rd party like Shiro), or a servlet filter, or if you
really really want to keep it in "the JSF house", use <f:viewAction> instead.
<f:viewAction action="#{bean.init}" />
(don't forget to remove the #PostConstruct annotation)
If you're not on JSF 2.2 yet, use preRenderView event instead.
<f:event type="preRenderView" listener="#{bean.init}" />
See also:
What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?
Is it possible to disable f:event type="preRenderView" listener on postback?
Related
In a JSF managed bean constructor, I load a entity from database usint a request parameter. Some times, the entity is not in database and I want to show other JSF (.xhtml) page with 404 message.
This is a sample of managed bean:
#ManagedBean(name = "someBean")
#RequestScoped
public class SomeBean implements Serializable {
private static final long serialVersionUID = 1L;
private SomeData someData;
public SomeBean() throws IOException {
someData = ... loads from database using JPA features
if(someData == null){
HttpServletResponse response = (HttpServletResponse) FacesContext
.getCurrentInstance().getExternalContext().getResponse();
response.sendError(404);
}
}
public SomeData getSomeData(){
return someData;
}
}
I configured the web.xml file something like that:
<error-page>
<error-code>404</error-code>
<location>/404.xhtml</location>
</error-page>
I have a JSF page to handle the entity loaded by managed bean. When the entity exists, I will use it in the page. Like that:
<h1>#{someBean.someEntity.name}</h1>
<h2>#{someBean.someEntity.description}</h2>
<ui:repeat value="#{someBean.someEntity.books}" var="book">
// ..........
</ui:repeat>
The page above works when the managed loads the data successfully.
The Problem
When the entity not exists and I send a 404 ERROR CODE, the JSF still process methods defined in the expression language of the first page.
This behavior makes the managed bean throws a NullPointerException, and a HTTP 500 ERRO CODE.
My 404 error page is not called. I do not know why.
I try send the 404 error even when the entity is found in database and the 404 error page works.
Enyone can explain this JSF behavior to this happiness? Or offer some kind to show the 404 error page without URL change ?
You're basically trying to perform front controller logic while rendering the view. You should do it before rendering the view. Because, once you start rendering the view, it's already too late to change the view to a different destination, e.g. an error page as in your case. You namely cannot take the already sent response back from the client.
In JSF 2.2 you can use <f:viewAction> for this.
<f:metadata>
<f:viewAction action="#{bean.init}" />
</f:metadata>
public void init() {
// ...
if (someCondition) {
context.getExternalContext().responseSendError(404, "some message");
context.responseComplete();
}
}
(note that whenever you need to import javax.servlet.* classes into your JSF backing bean, you should absolutely stop and look if the functionality isn't already available in ExternalContext or otherwise think twice if you're doing things the right way, e.g. perhaps you needed a servlet filter; also note that you need to explicitly tell JSF that you've completed the response, otherwise it will still attempt to render the view)
In JSF 2.0/2.1 you can use <f:event type="preRenderView"> for this. See also among others What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?
In case you're actually trying to validate a HTTP request parameter and you also happen to use OmniFaces, you may consider using <f:viewParam> with a true JSF validator and control the sendError with OmniFaces <o:viewParamValidationFailed>.
For a project we are migrating some java applications to WebSphere 8.5. In the process we are trying to get rid of some legacy frameworks. One of them is shale (apache attic). The only component from shale that is used is the view controller to instantiate a request scoped jsf managed beans for every page. Every bean has an init method that is called on page load. I'd like to use #PostConstruct on this method. The only problem I have that the bean gets instantiated when a method on the bean is called. Unfortunately the bean is not always called and the init method does populate data on a session scoped bean. There is a naming convention that links pages and beans so we could use a listener to instantiate the bean based on the request. Another solution might be changing the scope to viewscope (probably to much a hassle on websphere 8.5).
I was wondering if there is something I can do to make the PostConstruct work? And are there other options I'm missing?
edit:
I have a PhaseListener in place that performs the basic functionality. It matches the requested page to the corresponding bean (by naming convention). The following is used to instantiate the bean but it looks a bit ugly.
expressionFactory.createValueExpression(elContext, "#{" + managedBeanName + "}", Object.class)
Is there a more elegant way to do this?
Perhaps you could try using <f:event/> ?
In your view, you could add this to the page.
<f:event type="postAddToView" listener="#{backingBean.myInitMethod()"/>
https://stackoverflow.com/a/14004230/4706826
Gives you info on when the events get executed.
Put a #PostConstruct annotated method in the backing bean. This annotation tells the bean to execute the annotated method every time its constructor is being called.
Example:
#ManagedBean
#ViewScoped
public class MyManagedBean{
#PostConstruct
public void initView() throws Exception{
...initialize page values, execute database queries, etc.
}
In a JSF managed bean constructor, I load a entity from database usint a request parameter. Some times, the entity is not in database and I want to show other JSF (.xhtml) page with 404 message.
This is a sample of managed bean:
#ManagedBean(name = "someBean")
#RequestScoped
public class SomeBean implements Serializable {
private static final long serialVersionUID = 1L;
private SomeData someData;
public SomeBean() throws IOException {
someData = ... loads from database using JPA features
if(someData == null){
HttpServletResponse response = (HttpServletResponse) FacesContext
.getCurrentInstance().getExternalContext().getResponse();
response.sendError(404);
}
}
public SomeData getSomeData(){
return someData;
}
}
I configured the web.xml file something like that:
<error-page>
<error-code>404</error-code>
<location>/404.xhtml</location>
</error-page>
I have a JSF page to handle the entity loaded by managed bean. When the entity exists, I will use it in the page. Like that:
<h1>#{someBean.someEntity.name}</h1>
<h2>#{someBean.someEntity.description}</h2>
<ui:repeat value="#{someBean.someEntity.books}" var="book">
// ..........
</ui:repeat>
The page above works when the managed loads the data successfully.
The Problem
When the entity not exists and I send a 404 ERROR CODE, the JSF still process methods defined in the expression language of the first page.
This behavior makes the managed bean throws a NullPointerException, and a HTTP 500 ERRO CODE.
My 404 error page is not called. I do not know why.
I try send the 404 error even when the entity is found in database and the 404 error page works.
Enyone can explain this JSF behavior to this happiness? Or offer some kind to show the 404 error page without URL change ?
You're basically trying to perform front controller logic while rendering the view. You should do it before rendering the view. Because, once you start rendering the view, it's already too late to change the view to a different destination, e.g. an error page as in your case. You namely cannot take the already sent response back from the client.
In JSF 2.2 you can use <f:viewAction> for this.
<f:metadata>
<f:viewAction action="#{bean.init}" />
</f:metadata>
public void init() {
// ...
if (someCondition) {
context.getExternalContext().responseSendError(404, "some message");
context.responseComplete();
}
}
(note that whenever you need to import javax.servlet.* classes into your JSF backing bean, you should absolutely stop and look if the functionality isn't already available in ExternalContext or otherwise think twice if you're doing things the right way, e.g. perhaps you needed a servlet filter; also note that you need to explicitly tell JSF that you've completed the response, otherwise it will still attempt to render the view)
In JSF 2.0/2.1 you can use <f:event type="preRenderView"> for this. See also among others What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?
In case you're actually trying to validate a HTTP request parameter and you also happen to use OmniFaces, you may consider using <f:viewParam> with a true JSF validator and control the sendError with OmniFaces <o:viewParamValidationFailed>.
When should one use the f:viewAction or preRenderView event to initialize data for a page versus using the #PostConstruct annotation? Is the rationale to use one or the other based on the type of scope of the backing bean e.g. If the backing bean is #RequestScoped, then would the choice of using f:viewAction or preRenderView over #PostConstruct to initialize your backing bean prior to rendering the view be irrelevant as the two would result in the same effect?
f:viewAction or preRenderView
<f:metadata>
<f:viewAction action="#{myBean.initialize}" />
</f:metadata>
<f:metadata>
<f:event type="preRenderView" listener="#{myBean.initialize}"/>
</f:metadata>
or
#PostConstruct
public class MyBean
{
#PostConstruct
public void initialize()
{
}
}
When should one use the f:viewAction or preRenderView event to initialize data for a page verses using the #PostConstruct annotation?
Use the <f:viewAction> when you want to execute a method before the HTML is been rendered. This is particularly useful if you want to perform actions based on model values set by <f:viewParam> during update model values phase. Namely, they are not available at the moment the #PostConstruct runs. In JSF 2.0/2.1, this tag didn't exist and you have to use the preRenderView workaround.
If the backing bean is #RequestScoped, do they effectively do the exact same thing? (and so then it is up to developer choice? (#PostConstruct seems "cleaner").
No, they do definitely not effectively do the same thing. The #PostConstruct is intented to perform actions directly after bean's construction and setting of all injected dependencies and managed properties such as #EJB, #Inject, #ManagedProperty, etc. Namely, the injected dependencies are not available inside the bean's constructor. This will thus run only once per view, session or application when the bean is view, session or application scoped. The <f:viewAction> is by default only invoked on initial GET request, but can via onPostback="true" attribute be configured to be invoked on postback requests as well. The preRenderView event is invoked on every HTTP request (yes, this also includes ajax requests!).
Summarized, use #PostConstruct if you want to perform actions on injected dependencies and managed properties which are set by #EJB, #Inject, #ManagedProperty, etc during bean's construction. Use <f:viewAction> if you also want to perform actions on properties set by <f:viewParam>. If you're still on JSF 2.0/2.1, use preRenderView instead of <f:viewAction>. You can if necessary add a check on FacesContext#isPostback() to perform the preRenderView action on initial request only.
See also:
What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?
ViewParam vs #ManagedProperty(value = "#{param.id}")
Is it possible to disable f:event type="preRenderView" listener on postback?
Do you need to initialize managed bean's properties? --> Then, use #PostConstruct
Otherwise, do you need to work with params passed from other view? --> Then, use "preRenderView"
Is it possible to get a reference to the to-be-executed managedbean in the before-invokeApplication-phaselistener ?
Before the invoke application phase, it should be clear which managedBean that is going to execute the method.
For the sake of the example, assume there's 1 main manage bean to handle 1 jsf page.
So what i need is basically :
The user access the program from the menu
Because it's accessed from the menu, the main manage bean's init() method gets called to initialize stuffs like preparing data, doing authorization checks
Subsequent submits dont need to call the init() method anymore until it's reaccessed from the menu
To implement the point #2, im thinking of intercepting one of the phases
I've checked the API docs about getting the managed bean in the phases implementation, but i couldnt seem to find any.
After typing this question, i realize i could do this in #PostConstruct or the managed bean's constructor, but that would do only at the first time the bean is constructed, and my need is to call the method everytime the jsf is being accessed from the menu.
Any suggestions ?
Regards,
Albert Kam
You can access your managed beans via the ELContext/ELResolver. This is explained nicely in the MyFaces wiki (also works in vanilla JSF).
For example:
ELContext elContext = FacesContext.getCurrentInstance().getELContext();
NeededBean neededBean = (NeededBean) FacesContext.getCurrentInstance().getApplication()
.getELResolver().getValue(elContext, null, "neededBean");
See the MyFaces wiki entry for further explanation, and implementations for other JSF versions.
Your idea of using #PostConstruct is a good one. Consider changing your scope to something liked #ViewScoped, so the logic is executed everytime you navigate to that view.
Also, have a look at the PreRenderViewEvent (for JSF 2). This code is embedded in your facelet page:
<f:metadata>
<f:viewParam name="foo" value="#{bean.foo}"/>
<f:event type="preRenderView" listener="#{bean.doSomething}"/>
</f:metadata>
The f:event listener is executed before every page view.