I'm trying to build a JSF application, but I'm having this error:
java.lang.ClassNotFoundException: javax.servlet.descriptor.JspConfigDescriptor
java.lang.NoClassDefFoundError: javax/servlet/descriptor/JspConfigDescriptor
How is this caused and how can I solve it?
java.lang.ClassNotFoundException: javax.servlet.descriptor.JspConfigDescriptor
This class was introduced in Servlet 3.0. This error thus means that your webapp's runtime classpath is littered with arbitrarily downloaded JAR files from a completely different servletcontainer make/version which doesn't support Servlet 3.0, while the webapp is in turn deployed to a Servlet 3.0 compatible container. This would only result in classloading conflicts in all colors because multiple different versioned classes exist in the runtime classpath.
Littering /WEB-INF/lib folder with servletcontainer-specific JAR files is in turn a common starter's mistake in a wild attempt to "fix" compile errors they faced in their IDE. This should have been solved differently. See also How do I import the javax.servlet API in my Eclipse project?
In a nutshell: Never put arbitrarily downloaded servletcontainer-specific JARs in /WEB-INF/lib. Instead, configure your IDE project to set the desired target servletcontainer as "Target Runtime".
Related
I am creating a simple JSF application with one of my university colleagues, and I am having some trouble when I pull down the application from our repository. When I import the project into NetBeans IDE 8.0.1, the program does not compile correctly on the following CDI based annotation:
#Named
#RequestScoped
public class LoginController implements Serializable {...
It is informing me that it cannot find the following package:
import javax.enterprise.context.*;
Initially I had thought that I did not have the EJB and EAR plugin installed, however I have installed the Java EE bundle which I downloaded from the netbeans website. Are there any other JAR's, which I may be possibly missing, causing this specific error.
On my colleagues local machine everything works as expected without any issues at all, so I am left unclear why this is not happening on my computer.
yeah it seem this netbeans version lacking javax.enterprise package. Here is the solution
1) If you are using maven project, add javax.enterprise(cdi-api.jar) as dependency
2) For other projects, download cdi-api.jar, add this as external jar from project properties, it will enable CDI.
Yes you need to include another library. You are using the part that belongs to Java EE. By default java includes Java SE. So you need to add this library in your project.
Go to
Project Properties -> Libraries -> Add Library -> Java EE Web 7 Api Library
I had this problem too. The glassfish library structure has changed somewhat so instead of using the "Java EE from Glassfish" library we used the "Java EE from API" library and that fixed it.
Both proposed solutions are valid but the simplest one is the second one because you've got already everything needed in NetBeans 8.0.
Your problem is clearly the consequence of the default Java EE bundle (version 7) present in GlassFish 4.1. Of course, it is a NetBeans bug. Netbeans should have added the needed library to your project when you chose to work with Java EE 6.
I am on a Linux Mint machine where I installed the latest version of Java (HotSpot VM 1.7.0_45) and using Gradle 1.8.
I also have Groovy installed, version 1.8.6, but I think that does not matter as Gradle has its own groovy-all.jar.
My problem is that I could not compile my Groovy project using gradle because the JavaFX classes do not seem to be in the classpath. The errors are like this:
unable to resolve class javafx.scene.Node
# line 3, column 1.
import javafx.scene.Node
I finally fixed this by adding the following horrible hard-coded path into my dependencies:
compile files( "/usr/lib/jvm/java-7-oracle/jre/lib/jfxrt.jar" )
Is there a better way to add JavaFX to Gradle's compilation classpath so that it is visible to all my projects without me having to add this to each one of them??
I have tried everything I could imagine:
added the jfxrt.jar to the standard JRE (I confirmed gradle is using my standard java to run) ext folder, so that I now can compile java classes with javac and run them with java (I know that in this version of Java the JavaFX jar should be already in the JDK's classpath, but I still couldn't RUN, as opposed to compile, my Java app before doing this).
also added a soft link to the same jar in the groovy classpath, so that I can do something like shown below from the groovy shell and it works:
import javafx.application.Application as A ; println A
This also works in the Groovy Console.
It only does not work in Gradle!
Thanks for any help.
Use the JavaFX Gradle Plugin.
The JavaFX Gradle Plugin should be able to work out where the JavaFX runtime is located without you having to perform manual, environment specific configuration.
For further information on JavaFX classpath resolution (not Gradle related), see:
Compile code using JavaFX 2.0 (using command line).
Also note, if you are using Oracle Java 8 or newer, JavaFX classes are now on the default runtime classpath for an Oracle Java implementation.
Incidentally, the build system for the entire JavaFX system is based on Gradle, so there is definitely no incompatibility between JavaFX and Gradle.
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.
I used to deploy a JSF+Primefaces app in a Glassfish server without any trouble. Recently I upgraded my NetBeans version. I haven't had any problems with the most of the applications after that. But with one of them when I tried to do the deployment, it failed and this was the error message:
Error occurred during deployment: Exception while loading the app :
java.lang.IllegalStateException: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.RuntimeException:
com.sun.faces.config.ConfigurationException:
java.util.concurrent.ExecutionException:
com.sun.faces.config.ConfigurationException: Unable to parse document
'jar:file:/opt/glassfish3/glassfish/domains/domain1/applications/[name-of-the-application]/WEB-INF/lib/javax.faces.jar!/META-INF/mojarra_ext.taglib.xml':
null. Please see server.log for more details.
It seems like all is ok with the project (cleans and build well), but the error keeps appearing. This is the environment I'm using:
NetBeans 7.3.1
JSF 2.2 (Mojarra)
GlassFish Open Source Edition 3.1.1 (build 12).
PS: When I try to do the deployment with Glassfish 3 bundled in NetBeans, this is the error:
SEVERE: Error during deployment : class com.sun.faces.application.annotation.PersistenceUnit Scanner cannot access its superinterface com.sun.faces.application.annotation.Scanner
Thanks
Unable to parse document 'jar:file:/opt/glassfish3/glassfish/domains/domain1/applications/[name-of-the-application]/WEB-INF/lib/javax.faces.jar!/META-INF/mojarra_ext.taglib.xml
The path to the taglib file suggests that you shipped JSF 2.2 along with the webapp inside its /WEB-INF/lib instead of upgrading GlassFish itself. As GlassFish 3 itself ships with a JSF 2.1 implementation out the box, you need to instruct it to not load it in order to avoid version conflicts. You didn't state anywhere that you were doing that, so I guess that this is the whole cause of your problem.
Glassfish itself already ships with JSF bundled which get by default classloading precedence over the one bundled in the webapp. You basically need to tell Glassfish to use the webapp bundled JSF instead.
In order to achieve that, edit the /WEB-INF/glassfish-web.xml to add the following two lines.
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
If the file does not exist create it, you can find a sample xml file here. and add the two lines from above inside the <glassfish-web-app> tag.
GlassFish will then suppress its own bundled JSF from loading and rely on webapp-bundled JSF.
Alternatively, if you have full admin control over Glassfish, you can also copy the javax.faces.jar file from JSF 2.2 into the /glassfish/modules directory, hereby replacing the old one, in order to upgrade it from JSF 2.1 to JSF 2.2 so that it get applied on all webapps.
I downloaded binary which has javax.faces-2.1.13 as the latest binary release. I want to upgrade my GlassFish JSF library but it has jsf-api-jar and other impl. How do I update and where do I download the jars?
Just replace both jsf-api.jar and jsf-impl.jar in the Glassfish /modules folder by the single javax.faces.jar file.
Since Mojarra 2.1.6 the build system has been changed to comply Java EE Maven rules, see also issue 2028. This resulted in the API and impl being merged into a single JAR file.
if you having some issues after replacing faces files in glassfish/modules folder, like non-compatibility of you framework version with jsf 2.2,2.3 and etc (for example "icefaces 4.1.1 error 200 during update: javax.faces.viewstate not found") or some unexpected behaviour - dont forget to clean glassfish/domains/somedomain/osgi-cache