Known Issues (CDI)
This wiki lists known issues of OmniFaces CDI features in combination with specific application servers. Note: for known issues with general features, head to Known Issues (general).
All CDI features have been tested in OmniFaces showcase application which is deployed in flavor of a Java EE 6 compatible WAR in various containers. The compatibility matrix is listed in compatibility matrix.
The story changes when OmniFaces is included in multiple WARs enclosed in the very same EAR. In contrary to what most developers would intuitively expect, the CDI context is in this case not WAR-wide, but EAR-wide. This unclarity in the CDI specification has been discussed numerous times at the following places:
In a nutshell, a CDI extension which is enclosed in a JAR in a WAR in an EAR is not applied on a per-WAR basis, but only once on a per-EAR basis for only one WAR. This has the consequence that only one of the WARs can make use of the features offered by the CDI extension and other WARs can not. In the case of OmniFaces 1.6 this has in turn the consequence that CDI converter/validator/viewscope works in only one WAR of the EAR. In case of the CDI converter/validator it also caused a deployment failure because of an uninjectable extension in other WARs which had a variant of the infamous "WELD-001408 Unsatisfied dependencies" exception as the root cause. See also issue 251.
For the CDI converter/validator this has been workarounded/fixed by lazily collecting all converters/validators eligible for injection inside a CDI application scoped bean instead of proactively collecting them inside a CDI extension.
For the CDI viewscope there's no workaround/solution as it really needs to be initialized through a CDI extension. There's no way of registering a new CDI context other than through AfterBeanDiscovery#addContext() which should take place in a CDI extension. This means that the OmniFaces CDI @ViewScoped would work in only one WAR of such an EAR. Again, this is not a problem in OmniFaces and can not be solved from the OmniFaces side.
So far, those issues are fleshed out in this blog and the following EAR-capable application servers have been tested for the CDI features:
| Application Server | @FacesConverter/Validator |
@ViewScoped |
@Param |
|---|---|---|---|
| JBoss EAP 6.1 | works in all WARs | works in only one WAR | works in all WARs |
| JBoss WildFly 8 alpha 4 | works in all WARs | works in only one WAR | works in all WARs |
| GlassFish 3.1.2.2 | works in only one WAR | works in only one WAR | works in all WARs |
| GlassFish 4.0 | works in all WARs | works in only one WAR | deploy fails when @Param is used |
| Geronimo 3.0.0.4/3.0.1 | works in all WARs | works in only one WAR | works in only one WAR |
| WebLogic 12.1.2 | works in all WARs | works in neither war | works in all WARs |
In case of GlassFish 3.1.2.2, the CDI converter/validator works in only one WAR because of classloading issues (the application scoped bean didn't pass the instanceof test on the interface due to a bug in GlassFish). In other WARs it should deploy just fine, but appear as uninjected (i.e. the EJB and CDI bean are never injected and remains null).
In case of GlassFish 4.0, the EAR deployment fails with WELD-001408 when the code in at least one WAR uses the @Param. The EAR deployment is however successful when the code doesn't use @Param anywhere.
In case of Geronimo 3.0.0.4/3.0.1, the @ViewScoped and @Param MAY work in all WARs, but it's untestable since @Named in war2 is not processed and all @Named beans from war1 are directly available in war2 :X However, directly injecting a CDI bean that only exists in war2 works in the converter that also only exists in war2, so CDI itself partially works. See also https://issues.apache.org/jira/browse/GERONIMO-6492
In case of WebLogic 12.1.2, in war1 ViewScopeManager is processed in ViewScopeExtension, but in war2 ViewScopeContext is added in ViewScopeExtension (different instance). Both are needed to make it work and each war only has half of the functionality, resulting in nothing working at all.
Noted should be again that all of those CDI features work perfectly fine when deployed as a standalone WAR or as single WAR in an EAR. The problem only manifests when you use multiple WARs with OmniFaces in the same EAR. Also noted should be that it's important that OmniFaces isn't blocking the deployment of the EAR in any way. Version 1.6 did it, but it's thus fixed in 1.6.1 for EAR-capable containers, in 1.6.2 also for Tomcat and in 1.6.3 also for Google AppEngine. Also noted should be that OmniFaces can simply not be included as an EAR library due to dependencies which are typically only available inside the WAR, like JSF, Servlet and EL.