I'm working on a project about migrating from jsf1.2 to JSF 2.2,I already removed the jsf 1.2 jars and I replaced them by jsf 2.2 jars! But when I'm trying to change schema namespace in faces-config file(new namespace definition for jsf 2.2) I got this exeception:
Caused by: javax.faces.FacesException: Class org.jboss.as.web.deployment.jsf.JandexAnnotationProvider is
not an instance of com.sun.faces.spi.AnnotationProvider
This seems like an inconsistence in your dependencies.
This Exception obviously points out, that
org.jboss.as.web.deployment.jsf.JandexAnnotationProvider
is not an extension of
com.sun.faces.spi.AnnotationProvider
However, I've done a little research using http://grepcode.com to get a better Picture of this Problem.
It seams, that JandexAnnotationProvider actualy is an extension of AnnotationProvider, at least after jboss-as-web version 7.0.0
Also Interesting was, that JandexAnnotationProvider disappeared after version 7.1.2.Final
I would suggest updating to the latest Version of jboss-as-web, which is 7.2.0
This class might got replaced for a reason related to your problem.
You can acquire this version at:
http://central.maven.org/maven2/org/jboss/as/jboss-as-web/7.2.0.Final/jboss-as-web-7.2.0.Final.jar
or as Maven dependency:
<dependency>
<groupId>org.jboss.as</groupId>
<artifactId>jboss-as-web</artifactId>
<version>7.2.0.Final</version>
</dependency>
Best regards,
J.Adam
Related
Glassfish 4.1.1
NetBeans 8.1
javax.faces-2.2.8-12.jar OR javax.faces-2.2.8-17.jar OR javax.faces-2.3.0-m06.jar
Reported as: JAVASERVERFACES-4182
I am experienced with JSF, and am confident this problem is not one of the typical causes of the infamous:
Target Unreachable, identifier 'viewBean' resolved to null
I am using a mini test web app to compare some JSF version as above, and rather than tediously copying various Mojarra implementation jars over the glassfish/modules I am using this in glassfish-web.xml:
<property name="useBundledJsf" value="true" />
<class-loader delegate="false" />
And between runs I use the NetBeans library jar manager to choose a JSF Mojarra version to test from a ./lib subfolder. When I use an application-specific Mojarra it is not resolving this (and the web app works fine when I use the built-in Mojarra in Glassfish):
import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;
#ManagedBean
#ViewScoped
public class ViewBean implements Serializable {
(and BTW yes I know javax.faces.bean.ManagedBean etc. are now deprecated).
I know that useBundledJsf is basically working at least partially because I have this in an index.xhtml landing page (before navigating to a page that uses the view scoped bean), and it echos the application-specific Mojarra jar version fine:
#{facesContext.class.package.implementationTitle}: #{facesContext.class.package.implementationVersion}
Q: Did Glassfish officially abandon support for 'useBundledJsf', and can somebody please shed some light on how to (now) use an application-specific Mojarra jar easily (so I can swap them in and out without impacting on other webapps) ?
I did not find the explanation I seek searching on the Glassfish JIRA.
On the Payara GitHub issues I found this:
useBundledJSF flag makes ServletContainerInitializer get an empty class set and breaks Mojarra 2.2.11 and up #170, where it reports:
We tried updating our Mojarra version in our application from 2.2.10
to 2.2.12. I was surprised that the application did not work anymore
after the update.
Digging a little deeper into the code it seems that from Mojarra
version 2.2.11 (+) the Mojarra library does not handle the annotation
scanning by itself anymore but relies on the container to provide the
classes which contain annotations.
When the flag "useBundledJSF" in glassfish-web.xml is set to true, the set of
classes is empty and this has the effect that no annotated bean can be found.
It seems I am experiencing something similar.
Possibly related: JAVASERVERFACES-3957 #FacesComponent is not detected when using JSF with Spring Boot
I am getting the below exception after migrating to JSF 2.2. Specifically, I'm upgrading Mojarra 2.1.17 to Mojarra 2.2.8.
java.lang.NoSuchMethodError: javax.faces.component.UIComponent.getPassThroughAttributes(Z)Ljava/util/Map;
at org.primefaces.renderkit.RendererUtils.renderPassThroughAttributes(RendererUtils.java:79)
at org.primefaces.renderkit.CoreRenderer.renderDynamicPassThruAttributes(CoreRenderer.java:119)
at org.primefaces.renderkit.CoreRenderer.renderPassThruAttributes(CoreRenderer.java:114)
at org.primefaces.renderkit.BodyRenderer.encodeBegin(BodyRenderer.java:44)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:823)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1611)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1616)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:399)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:273)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
When I check the UIComponent inside jsf-api-2.2.8.jar, I can see there is a method Map<String, Object> getPassThroughAttributes(boolean create);.
How is this caused and how can I solve it?
That method was introduced in JSF 2.2. This problem will thus happen when the webapp's runtime classpath is polluted with multiple different versioned JSF API libraries. In other words, you've still a JSF 2.0 or 2.1 API somewhere in the runtime classpath.
This suggests that you're trying to upgrade JSF by manually bundling it in the webapp and deploying it to a Java EE container which already bundles JSF out the box, such as WildFly, JBoss AS, GlassFish, WebLogic, WebSphere, etc. Your stacktrace is too short in order to be able to confirm that, but your question history confirms that you're using WebLogic.
In order to properly upgrade Mojarra in WebLogic, you should actually be replacing the JSF JAR(s) in /wlserver/modules folder.
In case you're actually using a barebones servletcontainer which doesn't bundle JSF out the box, such as Tomcat, then you'd need to verify if /WEB-INF/lib (or pom file in case of Maven) is free of duplicates in JSF API. Most common starter's mistake is having a javaee-api.jar in there too. This should be removed (or be set to provided). See also a.o. How do I import the javax.servlet API in my Eclipse project?
Using Wildfly 8.2.0.Final, which I believe uses Weld 2.2, I've reproduced this issue with 2 simple classes in a Maven multimodule project. One produces a javax.ws.rs.client.Client, another has an injection point for the same. Arquillian deployment fails with WELD-001408: unsatisfied dependencies.
The producer is in a library jar that gets included in the WEB-INF/lib for the consumer. Producer has a beans.xml in the META-INF with discovery-mode=annotation and the consumer has one in WEB-INF with discovery-mode=all.
Steps to reproduce:
Download this project and run mvn clean install from the root directory.
This is a critical bug. There're some other SO posts about Weld unsatisfied dependencies but most of them are because a beans.xml was missing. With CDI 1.2, beans.xml is optional, though my example does have couple. Any ideas?
Full disclosure: Also posted in Weld forum 255328
After days of trying to reproduce the issue in another project, but in vain, I reduced the original project to a CDI produce and a consumer and posted the code in JBoss forum and also opened a JIRA WELD-1921. Martin Kouba found out that the problem was caused by using the wrong Produces annotation! Instead of javax.enterprise.inject.Produces, I had javax.ws.rs.Produces. This obviously wasn't intentional and must've happened when I auto-imported the package in Eclipse and somehow picked the wrong one!
There were some other issues too but nothing I couldn't solve myself. Thanks a ton Martin.
I'd like to use <p:calendar> in my JSF app developed in Netbeans, so I added the PrimeFaces library. However, when I deploy the app, it errors as follows:
Context with name [/ManagedBeansWithComponents] has not yet been started
C:\Users\Dell-pc\Documents\NetBeansProjects\ManagedBeansWithComponents\nbproject\build- impl.xml:1040: The module has not been deployed.
See the server log for details.
BUILD FAILED (total time: 1 second)
And the server log says:
Source Document: jar:file:/C:/Users/Dell-pc/Documents/NetBeansProjects/ManagedBeansWithComponents/build/web/WEB-INF/lib/primefaces-3.5.jar!/META-INF/faces-config.xml
Cause: Class 'org.primefaces.component.fileupload.FileUploadRenderer' is missing a runtime dependency: java.lang.NoClassDefFoundError: org/apache/commons/fileupload/FileItem
How is this caused and how can I solve it?
java.lang.NoClassDefFoundError: org/apache/commons/fileupload/FileItem
There is the cause. It's crystal clear. The mentioned class is missing in the runtime classpath. The solution is rather straightforward: put the mentioned class (or, the JAR file containing it) in the runtime classpath. As the package name hints, it's available on http://commons.apache.org/fileupload (which in turn has by the way http://commons.apache.org/io as dependency). Just download and drop those JARs in the same place as PrimeFaces JAR and all should be well.
Unrelated to the concrete problem, note that this particular problem is in turn unintented by PrimeFaces. This problem should actually only occur when you register the FileUploadFilter for the <p:fileUpload> component in web.xml. However, since GlassFish 4.0, it is overzealously preloading every single JSF component and renderer class found in the classpath even if it's never used by the application. The class loading in turn causes all its runtime dependencies to be checked. If it's missing, then you get the NoClassDefFoundError. This problem is thus specific to GlassFish 4.0 and does not occur when using GlassFish 3.x or any other servletcontainer such as Tomcat or JBoss.
I have a related question. I am migrating my project from Jboss to TomEE. I was using Mojarra JSF, and have been having problems trying to get everything working using MyFaces (view Encryption problems, UI problems, ajax problems, etc). I just want to include Mojarra jars in my project, but looks like they are clashing with the built-in MyFaces jars that comes bundled with TomEE. I keep getting UnSupported exceptions.
Is there a way to specify that the Mojarra JSF should override myfaces? Is there a web.xml parameter or something? By the way, I am not using Maven (I've seen many examples with pom.xml dependency tags that cannot help me).
I tried that for 3 days, after making many tweaks(error stack-> google ->change some exotic xml parameter-> new error stack->google->change some exotic xml parameter etc....), I could make it work, except that EJB injection was not working anymore (getting null). So I surrendered and use myfaces instead of mojarra.