Minimal 3-tier Java EE app, without any XML config

21 August 2011, by: Development

Older versions of Java EE and Java frameworks in general were rather heavy with regard to required XML for configuration. Notorious were EJB2, Spring 2.x, JSF 1.x, Servlet 2.5 and many more.

These days things have improved quite a lot. In this post I’ll demonstrate a very simple, yet 3-tiered, Hello word application for Java EE. It uses JSF 2.1 and EJB 3.1 and absolutely not a single line of XML configuration.

The entire application consists of just 3 files: page.xhtml, BackingBean.java and BusinessBean.java. To run the application, create a dynamic web project called ‘mytest’ in Eclipse (EE edition) and delete everything that’s generated by default in WebContent. Copy page.xhtml to WebContent and copy both .java files to src. Add the app to your server (e.g. GlassFish 3.1) and browse to localhost:8080/mytest/page.jsf to see all the action.

The following shows the code of the 3 files involved:

page.xhtml

  1. <html xmlns="http://www.w3.org/1999/xhtml"
  2.     xmlns:h="http://java.sun.com/jsf/html"
  3. >    
  4.     <h:body>
  5.  
  6.        #{backingBean.hello}
  7.  
  8.         <h:form>      
  9.             <h:inputText value="#{backingBean.name}" />                    
  10.             <h:commandButton value="Say Hello" action="#{backingBean.sayHello}" />
  11.         </h:form>
  12.  
  13.     </h:body>
  14. </html>

BackingBean.java

  1. import javax.ejb.EJB;
  2. import javax.faces.bean.ManagedBean;
  3.  
  4. @ManagedBean
  5. public class BackingBean {
  6.  
  7.     String name;
  8.     String hello;
  9.  
  10.     @EJB
  11.     BusinessBean businessBean;
  12.  
  13.     public void sayHello() {
  14.         hello = businessBean.generateHello(name);
  15.     }
  16.  
  17.     public String getName() {
  18.         return name;
  19.     }
  20.  
  21.     public void setName(String name) {
  22.         this.name = name;
  23.     }
  24.  
  25.     public String getHello() {
  26.         return hello;
  27.     }
  28. }

BusinessBean.java

  1. import javax.ejb.Stateless;
  2.  
  3. @Stateless
  4. public class BusinessBean {
  5.  
  6.     public String generateHello(String name) {
  7.         return String.format("Hello, %s!", name);
  8.     }    
  9. }

The following shows that the project in Eclipse only has the 3 mentioned files:

The deployment itself also consists of only the 3 files mentioned (no IDE generated magic), although one extra step has been performed and that’s that the .java classes have been compiled to their .class versions and have been put into a newly generated directory WEB-INF/classes:

A simple exploded Java EE application deployment to GlassFish

Note the use of a couple of conventions that make this all work:

  • The context root is by default the name of the directory in which the app is deployed (technically: the exploded war name).
  • JSF by default maps the JSF controller servlet to *.jsf (and to /faces/* and *.faces).
  • Facelets files have a default suffix of .xhtml.
  • The backing bean’s default name in EL is the simple class name with the first letter de-capitalized.
  • The backing bean is by default in request scope.
  • The bi-directional binding from the view (page.xhtml) to the model via the EL expression #{backingBean.name} takes advantage of the JavaBean naming conventions for getters/setters.
  • The EJB is by default pooled and transactional.
  • A no-interface view is created for the EJB by default (since it doesn’t implement business interfaces).

Everything that is defaulted can be configured differently as needed. For instance, the default name in EL for the backing bean can be set to a different name via an attribute on the ManagedBean annotation, and the EJB can be made not transactional via an extra annotation. Some things would require XML to be configured differently. For instance, alternative mappings for the Faces Servlet or the default Facelets file suffix have to be configured in a web.xml file.

Finally, note that the goal of this example is to demonstrate one of the simplest possible setups and doesn’t necessarily adheres to all best practices. In reality, for non-trivial applications you’d want to declare you instance variables as private, definitely would not use the default package for your classes, probably create separate packages for your backing and business code, make sure *.xhtml is not directly accessible (e.g. by mapping the Faces Servlet directly to .xhtml in web.xml), and if your application really grows you might want to consider putting the business code in a separate module, add interfaces to the beans, etc etc.

But the point is that Java EE (and various other Java frameworks as well), now allow you to start with very simple defaults, making the barrier to enter much lower than before. You can then refactor and configure when the need arrises.


Arjan Tijms

10 comments to “Minimal 3-tier Java EE app, without any XML config”

  1. sumit says:

    thanks for sharing!
    BTW, are there any new annotations in the ejb spec that can make the life easier for us?

  2. John says:

    I don’t understand your usage of the word ’3-tier’ in this context…

  3. development says:

    @John

    In this case, the first tier is the view (the .xhtml page), the second is the model (the BackingBean) and the third one is the service layer (the BusinessBean).

    Being a Hello world application, it’s of course a little exaggerated, but the idea is that the view is a clean template, with only markup, components and bindings. The model tier delegates to the service layer and does things that are in the intersection (like caching the name in the example, but normally also generating feedback messages, or returning navigation outcomes).

    It are 3 tiers, since the view is only bound to the model, and the model is only bound to the service. Requests flow in only one direction (e.g. the service can’t call the model or view) and the response also flows back in only one direction.

    For a more traditional interpretation of 3-tier, the application should actually let the service layer call out to some data storage layer, which indeed doesn’t happen in the example.

  4. aus says:

    This is 3 layer rather than 3 tier. Layers are logical, tiers are physical.

  5. Authoring JSF pages in pure Java | J-Development says:

    [...] possible to create a JSF application completely in Java. No Facelets or JSP files, and following Minimal 3-tier Java EE app, without any XML config, no web.xml or faces-config.xml is required either. There doesn’t even have to be a WEB-INF [...]

  6. marketingconcept says:

    Java configuration is tough to. You have to required a lot of codes just to finished the program. But I think java is more easy to used compared to some program.

  7. kenalex says:

    Implementing same in HybridJava would be even more minimal.

  8. Reply to Comparing Java Web Frameworks « henk53 says:

    [...] really good and a completely different experience compared to the old 1.x releases. See  Minimal 3-tier Java EE app, without any XML config for a very simple introduction and JSF 2.0 tutorial with Eclipse and Glassfish  plus [...]

  9. พัฒนา JSF แบบไม่ต้องใช้ไฟล์ web.xml | MagicKiat's Weblog says:

    [...] http://jdevelopment.nl/minimal-3tier-java-ee-app-xml-config [...]

  10. Robert Cooke says:

    We are also trying to do something similar some of the constrains we hold our self to are zero conf, no application container and strong typed templating. Our project is called Core9 a nice thing is that it uses the new JDK8 nashorn engine to use javascript as an embedded scripting language.

Type your comment below:


9 + four =

css.php best counter