PrimeFaces, JSF 2.2 and CDI on Google App Engine

Introduction

Recently we did a proof of concept on Google App Engine, the cloud solution of Google. The Java version, supports servlets and you can already find various resources on the internet where the procedure is described to have the technologies listed in the title working on the platform.

But some of them are already quit old or give only a partial solution.  So I decided to put our findings together in this blog post.  All the frameworks are from the Apache group or have the Apache License.

We used version 1.9.1 of the Java GAE SDK.

JSF

The most difficult technology of the list is JSF. You can find various posts where you have to create your custom version of Mojarra to be able to deploy it.  This has to do with the use of JNDI sources which is not allowed on AppEngine.

We tried the Apache MyFaces 2.2.2 version and it went remarkable smooth.  We made the following  configuration options in the appengine-web.xml file.

    <sessions-enabled>true</sessions-enabled> 

    <threadsafe>true</threadsafe> 

    <static-files> 

        <exclude path="/**.xhtml" /> 

    </static-files>

The least obvious things was that we needed to tell AppEngine that xhtml files aren’t static, so that we can define it as an url pattern for the faces servlet.  Using this url extension is a best practice so that you can’t retrieve the raw html files of JSF.

EL 2.2

At this point, we were already able to deploy a JSF application and had the hello world style application working.  But if we tested with method expressions, like

<h:commandButton value="Greet" actionListener="#{testAction.doGreeting()}" />

We received an error that the brackets weren’t expected.  So it was clear that only value expressions are recognised and not the method expressions.

We tried various EL expression factories, and it turned out that the one of JBoss worked best.  But we weren’t able to use the latest version of the framework. we received following security exception

access denied ("java.lang.RuntimePermission" "modifyThreadGroup")

Although it is a CR release, it did the job so we stayed with this maven artefact  org.jboss.el:jboss-el:1.0_02.CR6

PrimeFaces

Plain JSF applications aren’t attractive, that is why you use some component library like PrimeFaces which became the de facto standard.  Adding this to artefact to the maven dependencies, we hit another issue, but this time we identified it as a known GAE bug.

It has to do with the handling of the If-Modified-Since request header.  But we quickly found an excellent solution by Derek Berube.

Adding the 2 classes and define the filter in the web.xml file, the problem was solved.

We even tried the latest PrimeFaces 5.0 version (it was just before it went into his first CR release) and there was no other issue we could see at first glance.  So this means you can now create web application targeted to mobile devices on Google App Engine.

CDI

As I’m a strong believer of Java EE, so I tried to use CDI for the middleware instead of the Spring approach too many people take without considering the alternatives.

There is an excellent Apache implementation of CDI, called OpenWebBeans.  The following artefacts where added to the project

• openwebbeans-impl
• openwebbeans-spi
• openwebbeans-web
• openwebbeans-jsf
• openwebbeans-el22

Regarding the configuration of OpenWebBeans, we just had to follow the procedure for a regular web server like Tomcat or Jetty.

After adding an empty beans.xml file and define the WebBeansConfigurationListener in the web.xml, the dependency injection worked like a charm.

Just as with JSF, there exists also for CDI an extension beyond the basic stuf and I choose CODI (Apache MyFaces Extensions CDI). Just adding the dependency was enough to make it work.

Other technologies

We also added the JPA option and used a maven plugin to handle the deploy to Google App Engine automatically when a mvn deploy command is issued.

I find it a pity that there is no database solution available for free on Google App Engine. It doesn’t need to be very powerful. Just a simple schema that you can use for demonstration purposes of your application.

This is in contrast with the JBoss OpenShift offering, where you can have a full Java EE stack with a database for free.  But that will be covered in another blog post.

Conclusion

Apart from one little issue (bug 8415) which can easily be bypassed, it was quit easy to assemble the required stack to have a JSF based web development environment on Google App Engine. This is in contrast with a few years back where various issues limited the possibilities.

CODI on Oracle WebLogic server 12c

Introduction

Oracle released recently their EE6 compliant version of the WebLogic server. It is a full EE6 profile, so everything you need is at your disposal.  Adam Bien did a smoke test and I made a small demo application where some CDI beans are defined inside a jar file placed in the WEB-INF\lib directory of the war file.
All these tests passed so we are ready to test some real world like application.  Just as JSF is an open system (it is build with extensibility in mind), CDI (Contexts and dependency injection, JSR-299) adhere to the same philosophy. And thus any real world application should use one of the extensions that make the life of the developer easy.
One of the popular CDI extensions is Apache MyFaces CODI, which brings you some goodies that you can use in your project.  You can read about the project on the wiki page.

 

Testing CODI

Testing CODI was done with the scope testing program that you can find here. I made the required adjustments in dependency scopes so that it works on any EE6 server. After deploying it on the Oracle WebLogic Server, I received the following error:

java.lang.IllegalStateException: No bean found for type:
org.apache.myfaces.extensions.cdi.core.api.config.CodiCoreConfig at
org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getOrCreateBeanByClass(CodiUtils.java:198)

Apparently this kind of error occurred also on older Glassfish v3 versions. So someone posting this issue on the mailing list received a solution very rapidly.

 

How to package a CODI application for WebLogic 12c?

So I tried the suggestions in the mailing list and the scope testing program works, except for one small issue. And it is not related to WebLogic only, in fact all containers running on Weld have the same problem. A method annotated with @PostConstruct isn’t executed when it is defined on a method in a super class of a bean with a custom scope.
This is the contents of the pom.xml file:

<dependency>
    <groupId>org.apache.myfaces.extensions.cdi.bundles</groupId>
    <artifactId>myfaces-extcdi-bundle-jsf20</artifactId>
    <version>${myfaces_codi.version}</version>
    <scope>provided</scope>
</dependency>
…
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>2.2</version>
    <executions>
        <execution>
            <id>unpack-codi</id>
            <phase>process-test-resources</phase>
            <goals>
                <goal>unpack-dependencies</goal>
            </goals>
            <configuration>
               <includeGroupIds>org.apache.myfaces.extensions.cdi.bundles</includeGroupIds>
                <includeArtifactIds>myfaces-extcdi-bundle-jsf20</includeArtifactIds>
                <outputDirectory>
                    ${project.build.directory}/classes
                </outputDirectory>
            </configuration>
        </execution>
    </executions>
</plugin>

Some words of explanation:

Defining the CODI dependency as provided, means that it isn’t included in the packaged war, but you can use the classes in you code.

The maven-dependency-plugin is used to unpack the contents of the CODI jar into the classes directory so that the required classes are available in the war file.

The last thing that needs to be done is to copy the contents of the beans.xml found in the CODI jar file, into the beans.xml file of your web application.

This way, you can use CODI, on the Oracle WebLogic Server 12c.

UPDATE: Seems that there is also a problem when the 'autodeploy' directory is used.  So for the moment only regular deployed WAR files can be used as described above.

CDI Specializes

Introduction

CDI is what I call a modern specification / framework. The emphasis
is placed on a few concepts and their usage and not on a limited list of
functionalities that should be implemented and covered. And it is easy to
extend it or change a few internal implementations. In the specification,
there is explicitly noted that portable extensions should be possible. The
most known extensions at this moment are CODI, maintained by the MyFaces
project, and Seam 3, the JBoss lead project.

And the specializes in the title could refer to this; a blog entry
about the additional functionalities that can be found in CODI and Seam 3
on top of the standard. Because, once you are familiar with the concepts,
you have a complete new set of tools at hand to handle dependencies and
managed beans in a type safe way. And those two projects have defined for
you some very common additions that you will use very often.

But the goal of this text is different. I'll try to explain you one
of the concepts in CDI offered by the annotation
javax.enterprise.inject.Specializes. The goodies of those CDI extensions
might be a subject of another entry. In the mean time, you can read their
documentation on how to use the provided functionality.