JSF’s built-in declarative tags are ill-suited for handling this sort of recursion. JSF builds a stateful component tree that is persisted between requests. If the view is restored in a subsequent request, the view state may not reflect changes in the model. I would favour an imperative approach. You have two options as I see … Read more
The symptoms of the JSF components not being parsed at all indicates that the FacesServlet hasn’t run. This will happen when the request URL doesn’t match the url-pattern of the FacesServlet as definied in web.xml. This would mean that the actual url-pattern of the FacesServlet isn’t *.xhtml at all. Are you looking into and editing … Read more
Is there any generally acceptable way of solving issues like this one? You basically want to fire an ajax request first and in its oncomplete check if it’s successful, and then trigger a synchronous request to download the file (note that you can’t download files with ajax). You could make use of FacesContext#validationFailed() (or OmniFaces … Read more
@ViewScoped beans are stored in HTTP session. Any objects which are stored in the HTTP session needs to implement Serializable. See also JSF managed bean causing java.io.NotSerializableException during Tomcat deployment and java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException. The NotSerializableException is usually self-explaining since it mentions the full qualified name of the class which needs to be serialized … Read more
@ManagedBean just declares that a certain bean is managed by JSF (makes it available to expression language among others). @ViewScoped lets you declare a specific scope the bean will live in. The default (when you don’t specify any scope) is @RequestScoped, which means your bean will live through a single request and will then be … Read more
No, the <f:event> is not strictly required to be placed inside <f:metadata>. It can be attached to any component. It’s indeed for pure self-documentary purposes placed inside the <f:metadata> whenever you have a bunch of <f:viewParam>s and would like to hook a <f:event> to invoke an action after all those view parameters have been set. … Read more
You could create a custom EL function for this with which you can ultimately end up like: <h:commandLink … title=”#{my:format(msg[‘someMessage’], someBean.value)}” /> You can use the MessageFormat API to perform the job, exactly as <h:outputFormat> is doing under the covers. An alternative is to create a custom component which does the same as JSTL’s good … Read more
You need to fetch it while inside a transaction (thus, inside the service method), and not while outside a transaction (thus, inside e.g. JSF managed bean init/action method), that would thus throw a LazyInitializationException. So, your attempt hardware.getConnectivities().size(); has to take place inside a transaction. Create if necessary a new service method for the purpose … Read more
You’re abusing a CDI managed bean as a business service. It has no clues of transaction management. You’d need to manually manage transactions. As this is usually a pain and you’re apparently using Glassfish, which is a fullworthy Java EE container supporting EJBs, you’d rather like to use a fullworthy EJB for this. When using … Read more
Just bind the buttons to different action methods which each return a different outcome. <h:commandButton value=”Go to page 1″ action=”#{bean.goToPage1}” /> <h:commandButton value=”Go to page 2″ action=”#{bean.goToPage2}” /> with public String goToPage1() { // … return “page_1”; } public String goToPage2() { // … return “page_2”; } Navigation cases are not necessary. JSF 2.0 supports … Read more