Home > JavaEE > Reusing front-end components in web applications

Reusing front-end components in web applications

In the Java SE realm, GUI components are based on Java classes with the help of libraries such as AWT, Swing or the newer JavaFX. As such, they can be shared across projects, to be inherited and composed.

Things are entirely different in the Java EE world, as GUI components are completely heterogeneous in nature: they may include static HTML pages, JavaScript files, stylesheets, images, Java Server Pages or Java Server Faces. Solutions to share these resources must be tailored to each type.

  1. Since Servlet 3.0 (Java EE 6), static resources, such as HTML, JavaScript, CSS and images can be shared quite easily. Those resources need to be packaged into the META-INF/resources folder of a JAR. At this point, putting the JAR inside the WEB-INF/lib folder of a webapp will make any such resource available at the webapp’s context root.
    A disadvantage of this approach is that shared resources are also exposed publicly, including JSP that are not meant to be.
  2. An alternative to share resources protected under WEB-INF, which is also available before Servlet 3.0, is to leverage the build tool. In this case, Maven offers a so-called overlay feature through the Maven WAR plugin. This requires both adding the WAR containing resources and dependencies as well as some POM configuration.
    
      ...
      
        
          
            maven-war-plugin
            2.4
            
              
                
                  ch.frankel.blog
                  resources
                
              
            
          
        
      
      
        
          ch.frankel.blog
          resources
          1.0.0
          war
          runtime
        
      
    

    At this point, resources belonging to the dependent WAR artifact will be copied to the project at build-time. Not resources existing in the project may be overwritten… on purpose or by accident. The biggest disadvantage of WAR overlays, however, is that resources have to be packaged in the WAR artifact while corresponding classes have to be in another JAR artifact.

  3. I’ve not much experience in Java Server Faces technology, but it seems sharing pages across different webapps requires the use of ResourceResolver.
  4. Finally, some frameworks are entirely built toward sharing GUI resources. For exaemple, with Vaadin, GUI components are based on Java classes, as for Java SE, thus making those components inheritable and composable. Furthermore, using images can be achieved in a few lines of code and is easy as pie:
    Image image = new Image("My image", new ClassResource("ch/frankel/blog/resources/image.png"));
    ui.setContent(image);

I think Java EE is sadly lacking regarding reuse of front-end resources. Of course, one can choose client-based frameworks to overcome this limitation though they bring their own pros and cons. In all cases, ease of reuse should be an important criteria for choosing front-end technologies.

email
Send to Kindle
Categories: JavaEE Tags: ,
  1. February 12th, 2014 at 06:54 | #1

    “I think Java EE is sadly lacking regarding reuse of front-end resources” – I totally agree. But what would you tell about HybridJava – most advanced components reuse solution?

  2. February 14th, 2014 at 18:00 | #2

    I would tell that the “most advanced component reuse solution” is quite a strong statement…

  1. No trackbacks yet.