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.
Related
I got this exception Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001456 Argument "resolvedBean" must not be null and found the following on the web here:
This is an ordering issue in GlassFish. What happens is that the loadFlows() method of http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java
is being invoked before WeldBootstrap.endInitialization() has finished. It is necessary to fully initialize Weld before invoking producers (which loadFlows() does).
What is that ordering issue? I mean which libraries need to be on top and load earlier?
I build a jsf 2.2 web application with glassfish 4.0.
I had two ocpsoft rewrite jar files in glassfish4.0/glassfish/lib and glassfish4.0/glassfish/domains/domain1/lib that initialized before weld. I deleted them both and got rid of that exception.
Since this is the only stack overflow question with this error message, I wanted to share my problem in case someone else had the same error but different problem.
I had a maven dependency that included org.apache.httpcomponents:httpclient:4.5.5 as a runtime exception. I explicitly added the transitive httpclient dependency into my pom and it fixed my problem.
My project is using log4j2, and everything looks fine until running an application that uses a third party library that uses log4j 1.x. When our application starts, we get an annoying stack trace involving a ClassNotFoundException on org.apache.log4j.ConsoleAppender. I noticed that one of our dependencies has a log4j.properties inside its jar referencing org.apache.log4j.ConsoleAppender, so I'm guessing that's the reason for the stack trace. A couple other dependencies causing this error include most anything using JBoss logging classes, like embedded glassfish and the eclipse persistence packages.
I tried adding log4j-1.2.bridge api jar to the classpath and it had no effect.
It seems a little ridiculous to include both the jars for log4j2 and log4j1.x in our application classpath. Is there any other alternative or fix?
These links provided answers for me:
https://issues.apache.org/jira/browse/LOG4J2-172
https://issues.jboss.org/browse/JBLOGGING-95
It looks like we are using an out-dated version of JBoss logging that doesn't support log4j2. However, I'm still not sure what to do for the one dependency that includes a log4j.properties.
[edit] It turns out adding log4j-jcl-2.0 jar worked for that dependency.
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.
I have made a jsf 1.1 portlet in weblogic 10.3, but in one scenario I need tomahawk library help. I just dropped the jar file and supporting ones in lib folder in WEB-INF in my portal application, but when I hit the url it gives me error of NoClassdef..... exception for classes in tomahawk jar and jsp compilation fails.
I am new to weblogic, I'll really appreciate if someoe can suggest what I might be doing wrong.
The setup is that whole application goes as ear. Ear contains app-inf and weblogic specific xml files, main portal web application goes as war inside this ear. I am using workshop that ships with weblogic portal 10.3. Well this project was migrated from weblogic portal 9.3.
Note: I dont want to but this jar in domain/lib, when I did so I dont know why it loaded my application and all the class defined in servlet startup with load-on-startups got fired well before time and none of the classes were found by server.
Jsf libraries currently used are in shared mode.
java.lang.NoClassDefFoundError means the runtime version of the class in the classpath is not the same as that at compile time.
Note: it's not a ClassNotFoundException.
Your problem is in fact multiple versions of the class being found.
Also, JSF 1.2 libraries are bundled with Weblogic server, so it can cause this exception if one of those classes is again added into the WEB-INF/lib. Which is the exact class on which the error is thrown, do you have multiple versions of Tomahawk lying around in WEB-INF and domain/lib?
Remove the extras and keep one in WEB-INF/lib only.
Update:
The docs state that Separate JSF 1.2 and JSTL 1.2 JAR files and implementation JAR files are also provided in the WL_HOME/server/lib/api.jar file.
Check for that class javax/faces/webapp/UIComponentELTag in this jar.
I still think you should use the weblogic.xml setting to force the WEB-INF/lib class to get loaded in preference to that in server/lib with
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
Being new to weblogic and infrastructure I messed up with different versions. Figured out it was just because of incompatible jars.