JBoss 7.1, OmniFaces 1.6, Eclipse Kepler, CDI 1.0
I have found the following situation with new Omnifaces 1.6, when I updated from OmniFaces 1.5 to OmniFaces 1.6. I suppose it has something to do with new interesting CDI features of OmniFaces 1.6.
I have two JSF based WAR projects in one EAR archive, both projects have OmniFaces as dependency and they both will be deployed. In deployment, OmniFaces 1.6 ends up in /WEB-INF/lib of both WAR projects. At start of JBoss the IllegalArgumentException was thrown.
java.lang.IllegalArgumentException: Registering converter 'class org.omnifaces.converter.ListConverter' failed, duplicates converter ID 'omnifaces.ListConverter' of other converter 'class org.omnifaces.converter.ListConverter'.
at org.omnifaces.cdi.converter.ConverterExtension.processConverters(ConverterExtension.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:241)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:229)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:207)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:569)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:559)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:60)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:38)
at org.jboss.weld.bootstrap.events.ProcessManagedBeanImpl.fire(ProcessManagedBeanImpl.java:30)
at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:123)
at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:204)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:344)
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82)
at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
If I remove one WAR project, then the exception dissapears and I can use the other WAR project in EAR.
Is it possible to use OmniFaces 1.6 in more as one project, and deploy to JBoss 7.1.1 in one EAR?
This bug has been fixed in 1.6.1. There's quite a story behind this bug, so I just wrote a blog on that: CDI behaved unexpectedly in EAR, so OmniFaces 1.6.1 released!
Summarized: CDI context isn't WAR-wide, but EAR-wide. As to the particular exception you faced, it's because there was only one CDI ConverterExtension being loaded from one WAR which is then applied EAR-wide and thus processing all #FacesConverter classes from both WARs instead of the WAR where the CDI extension was being loaded from.
Note that this is not a problem in OmniFaces. This is a problem in the way how CDI works in EARs.
Update: as per issue WELD-2143 this peculiar problem has finally been fixed in Weld 2.3.5. I have tested it in a patched WildFly 10.0.0 and confirmed that all OmniFaces CDI features which depend on an Extension, the #ViewScoped, #Eager and #Param work again in both WARs in a single EAR.
So, if you struggle with using aforementioned OmniFaces CDI features in an EAR with multiple WARs, make sure you upgrade Weld to at least version 2.3.5. The problem remains open in OpenWebBeans.
Related
I am using WebSphere 8.5 which has a default implementation of JSF 2.0. I would like to use JSF 2.2. I was trying to find out which JAR files should I be getting to have my application use JSF 2.2?
For MyFaces, you'll want myfaces-impl and myfaces-api as well its runtime dependencies commons-beanutils, commons-collections, commons-digester, and commons-logging. For Mojarra, you'll just need jsf-api and jsf-impl.
Whichever implementation you use, make sure to follow the instructions for packaging third-party JSF implementations on WebSphere:
Configuring JavaServer Faces implementation
I am using TomEE Plus 1.7.2 Server and try to start a webapp with OmniFaces included, but I get a Nullpointer exception:
WARNUNG: Could not instantiate eager request scoped beans for request /index.xhtml. Possibly the CDI request scope is not active. If this is indeed the case, see JavaDoc on org.omnifaces.cdi.Eager on how to remedy this.
java.lang.NullPointerException
at org.omnifaces.cdi.eager.EagerBeansWebListener.requestInitialized(EagerBeansWebListener.java:78)
When I use the EagerBeansFilter as shown at OmniFaces docs, I get a slight variation:
WARNUNG: Could not instantiate eager application scoped beans. Possibly the CDI application scope is not active. This is known to be the case in certain Tomcat and Jetty based configurations.
java.lang.NullPointerException
at org.omnifaces.cdi.eager.EagerBeansRepository.instantiateApplicationScopedAndRegisterListener(EagerBeansRepository.java:69)
Is this server not combinable with omnifaces?
TomEE is after WildFly one of most tested servers for OmniFaces, particularly because it uses almost everywhere in Java EE a different implementation as compared to WildFly (Apache vs Oracle). In the OmniFaces compatibility matrix you can find TomEE versions which successfully ran through all pages in OmniFaces showcase.
Those exceptions mentioned in your question will be thrown when CDI BeanManager couldn't find the OmniFaces EagerBeansRepository, which is an #ApplicationScoped bean. This in turn indicates a misconfigured CDI environment (e.g. wrong beans.xml or missing JNDI/listener configuration) or a dirty build (e.g. duplicate libraries). Verifying the CDI configuration and performing a full clean/rebuild should solve the problem.
At least, OmniFaces 2.2 or newer is technically incompatible with TomEE 1.x, because TomEE 1.x ships with JSF 2.1 and OmniFaces 2.2 or newer has a hard dependency on JSF 2.2 due to new <o:viewAction> tag. So, unless you modify TomEE to provide JSF 2.2, OmniFaces 2.2 or newer won't deploy and should fail deployment with below exception:
java.lang.NoClassDefFoundError: javax/faces/component/UIViewAction
The latest OmniFaces version which successfully deploys on a stock TomEE 1.7.x server is OmniFaces 2.1. If you want to use OmniFaces 2.2 or newer on a stock TomEE, then you need to upgrade to TomEE 7.x.
I'm using OmniFaces 1.6 currently, with an application running JSF 2.2.6, Weld 1.1.9, on a Tomcat 7.
I've tried updating OmniFaces to 2.0, but when I do, I get this error message while launching the application (and the application doesn't start):
This OmniFace version requires CDI, but none was found on this environment. OmniFaces 2.x requires a minimum of JSF 2.2
It links to this page: http://omnifaces.org/cdi/
The problem is that, as I said, the application definitely uses JSF 2.2 and CDI.
Any ideas on what could be wrong?
I had same issue with you.
Please check this
http://omnifaces.org/cdi/
here are the additional instructions:
Install CDI 1.1+ in this environment.
For Tomcat users who don't have freedom in server choice, refer this
article: How to install CDI in Tomcat? When installing Weld, make
sure that you're using a minimum of version 2.2.0! Older versions have
initialization ordering bugs.
Switch to a CDI 1.1 capable environment.
For Tomcat users who have full freedom in server choice, just replace
Tomcat by TomEE, or perhaps even by WildFly.
I'm trying to use the excellent OmniFaces library on a Glassfish v2.1 server.
It works well until I try to use the org.omnifaces.util.Faces class. In this case, I encounter a
java.lang.ClassNotFoundException: javax.servlet.ServletRegistration
From what I've gathered, it seems this class appeared with the Servlet 3.0 specification.
Glassfish v2.1 is only Servlet 2.5 compatible but OmniFaces documentation indicates that it only requires Servlet 2.5.
Is there something I'm missing ? Is this a dependency that was accidentally added ?
Full configuration is :
Myfaces 2.1.12
Glassfish v2.1.1 (9.1_02 Patch12)
OmniFaces 1.6
Thank you for your answers.
I've come across this article that explains things a bit more but I'm still confused as to whether or not it should work on Glassfish 2.1.
OmniFaces is indeed supposed to be Servlet 2.5 compatible, but that's not thoroughly tested as the development and showcase environments are Servlet 3.0 based. See also https://github.com/omnifaces/omnifaces/wiki/Java-EE-5-and-6-compatibility, so it may happen that something accidently slipped through. This is one of those things.
As per issue 298, this has been fixed for the current 1.8 snapshot.
As the questions states, is OmniFaces compatible with JSF 2.2?
Will it have dependencies only on JSF or other Java EE dependencies as well? I.e. will it be able to run just with Tomcat + JSF?
OmniFaces 1.6 showcase application has been tested on GlassFish 4 with Mojarra 2.2.2 and Tomcat 7.0.42 with Mojarra 2.2.3. There were no problems when using OmniFaces 1.6 with Mojarra 2.2.x. Only Glassfish 4 has a problem with using the #{now} and #{startup} beans from OmniFaces, but this is not OmniFaces' fault. For any known issues you can keep track of known issues wiki.
OmniFaces 1.x has no other required dependencies than Servlet, EL and JSF, with the minimum versions 2.5, 2.1 and 2.0 respectively. Tomcat already provides Servlet and EL out the box. You only need to supply JSF yourself (which in turn has a dependency on JSTL 1.2 which is also absent on Tomcat).