Migrating a Java EE 6 app from GlassFish v3 to JBoss 6.0-M5

[agoncal]

Hi,

I've develop a small application that uses most of the Java EE 6 specifications : JPA 2.0, Managed Bean 1.0, Servlet 3.0, EJB 3.1 (with Stateless, Singleton), JAX-RS 1.1, Interceptor 1.1, JSF 2.0 (with composite components) and CDI with @Inject. So, as you can see, even if the application is simple, it uses plenty of Java EE 6 technologies. The code is packaged into a war and deploys on GlassFish 3.0.1 and works well.

As an exercise I now want to see if this code can run on JBoss 6.0-M5 without too many changes (to check portability). I have two problems :

@ApplicationPath with JAX-RS doesn't seem to work

I try to avoid XML as much as I can. So, to have access to my REST resources, I use the following code :

@ApplicationPath("rs")
public class ApplicationConfig extends Application {
}

This way, any URL with rs/* will be interpreted as a RESTful resource. Again, this works fine with GlassFish, but with JBoss I have the following exception :

15:51:09,578 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/demo15
15:51:09,593 ERROR [org.apache.catalina.core.StandardContext] Context [/demo15] startup failed due to previous errors: java.lang.IllegalArgumentException: Invalid <url-pattern> rs/* in filter mapping
        at org.apache.catalina.core.StandardContext.validateFilterMap(StandardContext.java:2033) [:6.0.0.20100911-M5]
        at org.apache.catalina.core.StandardContext.addFilterMap(StandardContext.java:1973) [:6.0.0.20100911-M5]
        at org.jboss.web.tomcat.service.deployers.JBossContextConfig.processWebMetaData(JBossContextConfig.java:328) [:6.0.0.20100911-M5]
        at org.jboss.web.tomcat.service.deployers.JBossContextConfig.applicationWebConfig(JBossContextConfig.java:211) [:6.0.0.20100911-M5]
        at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:409) [:6.0.0.20100911-M5]
        at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:182) [:6.0.0.20100911-M5]
        at org.jboss.web.tomcat.service.deployers.JBossContextConfig.lifecycleEvent(JBossContextConfig.java:206) [:6.0.0.20100911-M5]
        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [:6.0.0.20100911-M5]
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3773) [:6.0.0.20100911-M5]
        at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:299) [:6.0.0.20100911-M5]
        at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:138) [:6.0.0.20100911-M5]
        at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461) [:6.0.0.20100911-M5]
        at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) [:6.0.0.20100911-M5]
        at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.0.0.20100911-M5]

JSF pages are not displayed

Again, without any web.xml, I rely on the defaults, so I use the *.faces extension for my JSF pages. When I hit the url of my page (localhost:8080/demo15/newBook.faces) I have a 404. I've tried several extensions (*.jsf) or path (/faces/*) but I have a 404. In the JSF 2.0 spec (paragraph 11.1.2) it's written that url-patterns /faces/* and *.faces are recommended, but not required. So I'm wondering if this is the case with JBoss or if I need to configure the FacesServlet in a web.xml file

Thanks,

Antonio

[agoncal]

I confirm that having the following web.xml makes the JSF webapp work (not the REST resources). Do you know if it's possible to avoid such a web.xml (as in GlassFish where it is completely optional) :

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">

    <!-- Faces Servlet -->
    <servlet>
       <servlet-name>Faces Servlet</servlet-name>
       <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
       <load-on-startup>1</load-on-startup>
    </servlet>

    <!-- Faces Servlet Mapping -->
    <servlet-mapping>
       <servlet-name>Faces Servlet</servlet-name>
       <url-pattern>*.faces</url-pattern>
    </servlet-mapping>
</web-app>

[jaikiran]

For the JSF related question, maybe this might help http://community.jboss.org/wiki/JSFonJBossAS6

[agoncal]

Thanks for the link. It's a bit disturbing to read the following :

here are several conditions that signal the JSF deployer to add a JSF configuration to your WAR:

• A FacesServlet is declared in WEB-INF/web.xml or a web-fragment.xml
• A faces-config.xml file is found in WEB-INF
• A faces-config.xml file is found in META-INF of some jar in WEB-INF/lib
• A *.faces-config.xml file is found in META-INF of some jar in WEB-INF/lib
• The javax.faces.CONFIG_FILES context param is declared in WEB-INF/web.xml or  a web-fragment.xml.
• The org.jboss.jbossfaces.JSF_CONFIG_NAME context param is declared in WEB-INF/web.xml or a web-fragment.xml
• "alwaysAddJSF" is set to true in jsf-integration-deployer-jboss-beans.xml.

All these points are either about the web.xml (which is supposed to be optional), the faces-config.xml (which is also supposed to be optional) or JBoss specific configuration. How can you say "in JSF 2.0 the faces-config.xml is optional but you need it to trigger JSF support".

[henk53]

So maybe "alwaysAddJSF" should just be defaulted to true then for the GA release of JBoss AS?

Otherwise JBoss AS 6 simply isn't spec compliant it seems.

[agoncal]

I read the JSF 2.0 specification and this is what's written :

11.1 Web Application Deployment Descriptor
(...) Portable JSF-based web applications must include the following configuration elements, in the appropriate portions of
the web application deployment descriptor. (...)

11.1.1 Servlet Definition
<servlet>
  <servlet-name> faces-servlet-name </servlet-name>
  <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>

11.1.2 Servlet Mapping
When using extension mapping the following mapping is recommended, but not required:
<servlet-mapping>
  <servlet-name> faces-servlet-name </servlet-name>
  <url-pattern>*.faces</url-pattern>
</servlet-mapping>

So it looks like if you want to be portable, you need to define the FacesServlet and the *.faces mapping. GlassFish has all that by default, but the spec says you shouldn't rely on these defaults to have a portable app as these defaults are recommended, but not required

[jaikiran]

I just moved this thread to our JSF forum where you stand a better chance of getting answers to these questions.

[henk53]

Antonio Goncalves wrote:

I read the JSF 2.0 specification and this is what's written :

11.1 Web Application Deployment Descriptor
(...) Portable JSF-based web applications must include the following configuration elements, in the appropriate portions of
the web application deployment descriptor. (...)

11.1.1 Servlet Definition
<servlet>
  <servlet-name> faces-servlet-name </servlet-name>
  <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>

11.1.2 Servlet Mapping
When using extension mapping the following mapping is recommended, but not required:
<servlet-mapping>
  <servlet-name> faces-servlet-name </servlet-name>
  <url-pattern>*.faces</url-pattern>
</servlet-mapping>

So it looks like if you want to be portable, you need to define the FacesServlet and the *.faces mapping. GlassFish has all that by default, but the spec says you shouldn't rely on these defaults to have a portable app as these defaults are recommended, but not required

Interesting, so actually it's Glassfish that's a little bit wrong here. For a RI you would say that by default it operates in standard compliance mode. I, and I figure other people too, often quick check if something works on Glassfish in a certain way to see if it's 'standard behavior'.

But maybe the real error is with the ones writing down those specs and voting on it. Sad that they didn't declare it to be truly optional. It seems to me that the spirit of the Java EE 6 discussions where about having these things as truly optional. Even Lincoln Baxter thinks btw that faces-config is optional: http://ocpsoft.com/java/spring-to-java-ee-a-migration-guide-cdi-jsf-jpa-jta-ejb/