how to install new jsf library in JBoss AS 7

[bcn]

I am looking for a guide about how to install a different jsf lib like Mojarra 2.1 in JBoss AS 7.

The equivalent of:

http://docs.jboss.org/jbossas/6/JSF_Guide/en-US/html_single/index.html#adding.jsf.config

But I can't find any information.

On startup, the following line is printed:

17:29:45,530 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-10) Initializing Mojarra 2.0.4 (FCS b09-jbossorg-4)

I guess you have to install a new module, but how to tell jboss to pick it up and use it for my web app?

Where is the mojarra default module?

Thanks

[ssilvert]

Hi,

For AS7, we don't have any way to easily upgrade or select the JSF version like we did in AS6.  This is being discussed for a future release but it is not on the schedule just yet.  Stay tuned.

Stan

[bcn]

What happens if I include the jsf 2.1 jars in WEB-INF/lib? Will they be used instead of the default?

I tried, but get the same line printed as above. May not mean anything though.

Thanks

[hostalp]

Yeah I'd also like to use 2.1 but so far no success.

I did a simple test with filtering out the server's JSF stuff via jboss-deployment-structure.xml:

<jboss-deployment-structure>  <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
  <deployment>
    <exclusions>
      <module name="javax.faces.api" />
      <module name="com.sun.jsf-impl" />
    </exclusions>

  </deployment>
</jboss-deployment-structure> 

And though I expected the application to fail it still initizalizes the server's JSF RI 2.0.4. I tried to override is somehow with own JSF impl. but no success so far.

Anyway.. I'm getting the following exception on startup of our app:

20:12:46,357 FINE  [javax.enterprise.resource.webcontainer.jsf.application] (MSC service thread 1-16) java.lang.NoSuchMethodException: org.jboss.as.web.deployment.jsf.JandexAnnotationProvider.<init>(javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider): java.lang.NoSuchMethodException: org.jboss.as.web.deployment.jsf.JandexAnnotationProvider.<init>(javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider)
at java.lang.Class.getConstructor0(Class.java:2706) [:1.6.0_25]
at java.lang.Class.getDeclaredConstructor(Class.java:1985) [:1.6.0_25]
at com.sun.faces.spi.ServiceFactoryUtils.getProviderFromEntry(ServiceFactory.java:83) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.spi.AnnotationProviderFactory.createAnnotationProvider(AnnotationProviderFactory.java:70) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.config.ConfigManager$AnnotationScanTask.<init>(ConfigManager.java:753) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:331) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:226) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_25]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_25]

[swd847]

In jboss-deployment-structure.xml you need to exclude if from the war itself:

<jboss-deployment-structure> 

<ear-subdeployments-isolated>true</ear-subdeployments-isolated>
  <sub-deployment name="mywar.war">
    <exclusions>
      <module name="javax.faces.api" />
      <module name="com.sun.jsf-impl" />
    </exclusions>
  </sub-deployment>
</jboss-deployment-structure>

Not sure if this will actually make it work or not, but it is worth a try

[hostalp]

Moving exclusions under war sub-deployment got me a bit forward but this is quite strange to me - I'd expect the exclusions to have the desired effect at the deployment level. Anyway still no luck, I can see the container still initializes Mojarra 2.0.4 - even when I comment out its entry in modules/org/jboss/as/web/module.xml and replace it with my own jsf2 entry.

But it's actually a bit mixed - some stuff gets loaded from bundled 2.0.4 and some from the added 2.1.2, really strange.

As for getting rid of javax.faces.api module, that doesn't work either - even though I comment out all javax.faces.api dependencies I found:

modules/org/jboss/as/web/module.xml

modules/org/jboss/as/weld/module.xml

modules/org/jboss/jsfunit/core/module.xml

modules/org/jboss/weld/core/module.xml

...and just to make sure, renamed both module directories to something else so that they aren't found in any case...

I'm still getting an exception which reveals it tries to load that module anyway:

org.jboss.modules.ModuleNotFoundException: Module javax.faces.api:main is not found
at org.jboss.modules.LocalModuleLoader.findModule(LocalModuleLoader.java:121)
at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:245)
at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:194)
at org.jboss.modules.LocalModuleLoader.preloadModule(LocalModuleLoader.java:97)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:176)
at org.jboss.modules.Module.linkImports(Module.java:1039)
at org.jboss.modules.Module.relink(Module.java:1151)
at org.jboss.modules.ModuleLoader.relink(ModuleLoader.java:400)
at org.jboss.as.server.moduleservice.ServiceModuleLoader.relinkModule(ServiceModuleLoader.java:204)
at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:64)
... 5 more

So it looks like it's hardcoded somewhere as I really couldn't find any other module dependencies referring to those two JSF related.

Currently the only way I managed to use it was to modify the javax.faces.api and com.sun.jsf-impl modules themselves.

Still the following exception can be seen at FINE level during initialization:

FINE  [javax.enterprise.resource.webcontainer.jsf.application] (MSC service thread 1-2) java.lang.NoSuchMethodException: org.jboss.as.web.deployment.jsf.JandexAnnotationProvider.<init>(javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider): java.lang.NoSuchMethodException: org.jboss.as.web.deployment.jsf.JandexAnnotationProvider.<init>(javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider)
at java.lang.Class.getConstructor0(Class.java:2706) [:1.6.0_25]
at java.lang.Class.getDeclaredConstructor(Class.java:1985) [:1.6.0_25]
at com.sun.faces.spi.ServiceFactoryUtils.getProviderFromEntry(ServiceFactory.java:83) [jsf-impl-2.1.2.jar:2.1.2-FCS]
at com.sun.faces.spi.AnnotationProviderFactory.createAnnotationProvider(AnnotationProviderFactory.java:70) [jsf-impl-2.1.2.jar:2.1.2-FCS]
at com.sun.faces.config.ConfigManager$AnnotationScanTask.<init>(ConfigManager.java:807) [jsf-impl-2.1.2.jar:2.1.2-FCS]
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:348) [jsf-impl-2.1.2.jar:2.1.2-FCS]
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:225) [jsf-impl-2.1.2.jar:2.1.2-FCS]
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_25]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_25]

[bcn]

I cheated jboss and copied jsf-impl.jar and jsf-api.jar to the respective folders and renamed them to replace jboss-jsf-api_2.0_spec-1.0.0.Final.jar etc.

So it loaded well and printed that it initialized Mojarra 2.1.2.

Should this work or are there any side-effects?

But, irrespective of the jsf version, I get an exception, for which I opened a new thread:

http://community.jboss.org/thread/169487

Maybe you have an idea.

Thanks,

Ulrich

[henk53]

I'm wondering why the brand new JBoss AS 7 is shipping with a relatively old Mojarra implementation. There are some very annoying issues in 2.0.4 (like e.g. sessions always being created even when not needed, which can be killing for a public website) and the infamous "null source" exception.

[fastroller]

Well I did the same as U J above except that I deleted the originals and modified the module.xml to use jsf-api.jar and jsf-impl.jar. I was using 2.1.1 with AS6.1 without any problems but now I get the following:

Multiple JSF Applications found on same ClassLoader.  Unable to safely determine which FactoryManager instance to use. Defaulting to first match.

This is not a problem with JBoss, see http://java.net/jira/browse/JAVASERVERFACES-2029. It does appear to marked as fixed in 2.1.2, so I'll just download the latest-and-greatest.

[jason.greene]

Petr H wrote:

Moving exclusions under war sub-deployment got me a bit forward but this is quite strange to me - I'd expect the exclusions to have the desired effect at the deployment level. Anyway still no luck, I can see the container still initializes Mojarra 2.0.4 - even when I comment out its entry in modules/org/jboss/as/web/module.xml and replace it with my own jsf2 entry.

But it's actually a bit mixed - some stuff gets loaded from bundled 2.0.4 and some from the added 2.1.2, really strange.

The reason this happens is that JSF has to integrate with the server for injection and annotation scanning. So what is happening is our JSF deployment processor is picking up the JSF artififacts and using the JSF apis that it is linked again. To prevent this from happening we need to add a feature to disable it entirely. Is that something you feel would be useful (even though resource injection likely wouldnt work)?

We definitely want to ship JSF 2.1 in some update at least as an optional selection:

https://issues.jboss.org/browse/AS7-403

[hostalp]

Yes it would be awesome even with those restrictions (at least they aren't an issue for us). As JSF 2 evolves quite quickly a.t.m. (for example recently we were facing many functional and performance issues fixed later and there are still others to be resolved etc), an option to simply replace/update the JSF would be definitely welcome.

[ssilvert]

u j wrote:

I cheated jboss and copied jsf-impl.jar and jsf-api.jar to the respective folders and renamed them to replace jboss-jsf-api_2.0_spec-1.0.0.Final.jar etc.

So it loaded well and printed that it initialized Mojarra 2.1.2.

Should this work or are there any side-effects?

Annotations won't work as expected.  There was a change in the Mojarra SPI for that.

If you want a better build of AS7 with JSF 2.1.2, try this branch:

https://github.com/ssilvert/jboss-as/tree/JSF_20_to_JSF_21

I thought this might be useful for those wanting to try their apps/components on 2.1 right away.  Everything should be working properly including bean validation, annotations, JSP/JSTL, etc.  This is not the final implementation of JSF 2.1 on AS7, but please let me know if you find anything strange.

Stan

[fastroller]

Just thought I'd post a warning with the latest release of Mojarra 2.1.3. The download now no longer splits the implementation from the API. The single jar called javax.faces.jar is a combination of both. To upgrade  7.0.x with this jar you will need to edit the jar and remove the API (javax.faces.*) folder before moving to modules/com/sun/jsf-impl/main. In my case I also renamed the jar to jsf-impl.jar. Don't forget to upgrade the faces API module if you're upgrading to 2.1.

[gimbal]

As a side note: in a JSF 2/Richfaces 4.1 webapp in DEVELOPMENT mode I was getting annoying "component needs to be wrapped in UIForm parent" (or somewhere along that line) warnings. This warning was however incorrect, even wrapping the entire page in a form did not resolve it. This is related to a bug that was supposedly fixed in JSF 2.1.3:

http://java.net/jira/browse/JAVASERVERFACES-2147

I was still getting this in combination with Richfaces (only in pages that use components from the rich namespace), but upgrading the JSF implementation to 2.1.4 exactly as Andrew Wheeler describes resolved it.