mojarra

I'm strugging with my own resource-implementation. The getInputStream -method doesn't get called. My handler: public class ResourceHandlerWrapperImpl extends ResourceHandlerWrapper { private final ResourceHandler wrapped; public ResourceHandlerWrapper(final ResourceHandler wrapped) { this.wrapped = wrapped; } @Override public ResourceHandler getWrapped() { return wrapped; } @Override public Resource createResource(final String resourceName, final String libraryName) { if (AppConstants.RESOURCE_MEDIA_LIB.equals(libraryName)) { return new MediaResource(resourceName); } else { return super

We've been running a web app on a development server and recently somebody built a production server for us (with supposedly) the exact same tomcat config including the JSF libraries in the /lib directory. When I try to deploy my app the new server is throwing a rather confusing error message that I'd love some help understanding. catalina.out Both Production and Devel logs look similar up to this point: 24-Jun-2015 13:16:47.880 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive /opt/fleetforecaster/ff-tomcat/webapps/ROOT.war 24-Jun

I tried the last version of JavaServer Faces 2.2 (Mojarra 2.2.4) and noticed changing my query string in this unwanted way: page.jsf?jftfdi=&jffi= instead of page.jsf I've found that it is the new JSF 2.2 feature. But these query params(jftfdi, jffi) spoil me SEO-friendly urls. How can I disable it? This is a bug in Mojarra. They should not have been appended when there's no means of any flow navigation configuration ( by the new @FlowScoped annotation and <j:flow-xxx> tags ). Basically, the OutcomeTargetRenderer class who's responsible for HTML output generation of the <h:link> and <h:button>

This question is specific to the OmniFaces @ViewScoped bean (however of interest to wider discussion about memory leakage and resource disposal with JSF @ViewScoped). It is based on the results of this NetBeans8.1 test web app available on GitHub: Investigation of undesirable holding of references to various forms of JSF @ViewScoped beans by navigation type https://github.com/webelcomau/JSFviewScopedNav That test web app has a comprehensive README with complete instructions, as well as annotated test web pages comparing obsolete JSF2.0-style @ManagedBean @ViewScoped , JSF2.2-style CDI-friendly

I'm using Mojarra 2.2.4 on GlassFish 4 with Java 7. As I understand from BalusC's answer to How and when is a @ViewScoped bean destroyed in JSF? , @ViewScoped beans should be destroyed in three cases: Post-back with non-null outcome Session expiration Maximum number of logical views in session exceeded My beans are being destroyed in the first two cases, but not when the maximum number of logical views is exceeded. I have verified that the beans do expire when the maximum is exceeded (I get a ViewExpiredException), but they are still not destroyed until the session itself expires. For memory

When using something like <h:panelGrid columns="1"> <ui:repeat var="o" value="#{mybean.list}"> <h:outputText value="#{o.text}"/> </ui:repeat> </h:panelGrid> with lets say 10 list entries I only get 1 row e.g.: one tr with 1 td whereas when I use c:forEach i get 10 (but c:forEach is in fact evil, it messes up everything with ajax) I use mojarra 1.2 - is this a typical Mojarra bug which does not exist in the MyFaces implementation? Will it disappear in 2.x of the Mojarra releases? BalusC The output is fully as expected and specified. The <ui:repeat> is a render time tag, not a view build time

Memory per Session grows We are experiencing high memory consumption using JSF 2.2 (2.2.12) with Mojarra. After investigating our load tests it turned out that the size of the data in our ViewScoped Beans is quite high (sometimes more than 1MB). Anyway - when navigation from view to view, the session memory size grows and grows. We can't decrease the size of the beans on short-term, so this behavior has quite some impact. Solution 1 - Changing Context Params (not working) Now - we played around with the offical context parameter from Mojarra which are set to 15 by default: com.sun.faces

I am trying to use Glassfish 4.0 with Java EE 7 XML namespaces to test the sample below. <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://xmlns.jcp.org/jsf/html" xmlns:ui="http://xmlns.jcp.org/jsf/facelets" xmlns:f="http://xmlns.jcp.org/jsf/core"> <h:head> <title>Title</title> </h:head> <h:body> <h:form> <ul> <ui:repeat value="#{appLoad.movieList}" var="movie"> <li> <h:link value="#{movie.title}" outcome="movie" includeViewParams="true"> <f:param name="id" value="#{movie.id}"/> </h:link> </li> </ui:repeat> </ul> </h:form> </h:body> </html> It links to the following page movie.xhtml :