If you deploy a JSF application in WildFly 8, you can omit to define the JSF serlvet mapping. In this case three default mappings will be active out of the box.
Tested on WildFly 8.0.0.CR1 and JBoss EAP 6.2.0.GA
This behavior is not mentioned in the JSF 2.1 spec. But it explicitly allows implementations to use proprietary means to invoke the JSF lifecycle.
In addition to FacesServlet, JSF implementations may support other ways to invoke the JavaServer Faces request processing lifecycle, but applications that rely on these mechanisms will not be portable.
This default mapping can be problematic as it provides several path to access resources within your web application. Especially if you use security constraints to protect parts of your application. For instance if you restrict access to <context-root>/secure/* using a security constraint in your web.xml, web resources can still be accessed via <context-root>/faces/.
This post is intended to give an overview of the state of web accessibility (a11y) in general and within the JavaEE world in particular. The first section outlines the how and why of accessibility, followed by an introduction to web accessibility. The next section deals with common a11y problems in an average JSF web application. Finally, we summarize the current state of a11y in JavaEE. Continue reading
The good old JBoss Seam framework introduced the usage of stateful session beans (SFSB) as backing beans for JSF applications. The trick was to bind the lifecycle of a SFSB to a web context, such as the session or the request context. Meanwhile this concept was integrated into the Java EE by the Context and Dependency Injection (CDI) specification. We really like to use SFSB in JSF because it provides a comfortable way to access the logic and persistence layer with an automatic and painless transaction management.
We also like to modularize our applications by separating its different layers into different Maven modules. Thus, usually the web and application logic are bundled as EJB archives, whereas the web pages are stored in a WAR archive. All modules are combined to an application as an EAR archive. In our opinion this approach is more maintainable than to mix everything into one big WAR archive.
Sometimes the web logic has to access JSF classes, i.e. to query the locale used in the current request. To do this with the JBoss EAP 6, a particularity must be taken into account. By default in the EAP6 only WAR archives containing a JSF descriptor have access to the JSF classes, EJB jars do not.
This is due to rules for implicit class loading dependencies which are added automatically by the application server at deployment time. To access JSF classes from an EJB archive, the EJB jar has to state an explicit dependency to the faces module. This is pretty simple, if you know how to do it.
The last months, I often looked at web pages of projects using JSF and discovered an extensive use of the tag
h:outputText. It needs some practice to fast read HTML pages. But if the pages are cluttered with additional tags they become unreadable. When I asked the developer, why they designed the page like this, I often got the impression it was because they found it in the web or in some other part of the application, copied the code, and adapted it. This is a valid approach if the adaption phase contains improvement and consolidation. But, because of some uncertainty when to use the tag and when not to use it, the code was not cleaned up. Thus, I decided to write a short post, adding my 2 cents to the story.
We are migrating an existing Java EE Application from JBoss AS 6 to JBoss AS 7. This blog post introduces our experience we have gained during the migration of the application to the new JBoss AS 7.
Overview of the application
The application is a Java EE application based on EJB, JPA and it contains a web application built with JSF. Furthermore, the application contains a web service to interact with a third-party system and some MBean’s for administration and configuration.
How do you test your JSF application? Using JSFUnit allows you to perform integration test of your JSF application. The tests are run inside the container. JSFUnit tests can access the internal state of your application. The JSFUnit documentation describes how JSFUnit can be integrated into a Maven build environment. It leverages the maven-cargo-plugin and the maven-surefire-plugin to deploy the tests to an application server and execute them using JUnit.
However this is only explained for a plain Web archive (.war). It remains unclear how a JSF application can be tested which is packaged within an Enterprise archive (.ear). Continue to read if you are interested to see how we used JSFUnit to test our EAR based JSF application and how we integrated it in our Maven build environment.