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.
Related
I’m trying to use JAXB 2.2.11 in an osgi environment (Liferay DXP). I am having issues creating a JAXBContext. Based on some other sources found while researching like this and this, I have determined that in an osgi container I need to provide the correct classloader for JAXB to instantiate the context. So I have code like this:
ClassLoader cl package.with.jaxb.objects.ObjectFactory.class.getClassLoader();
JAXBContext jc = JAXBContext.newInstance("package.with.jaxb.objects ", cl);
This code causes a null pointer exception with the following stack trace:
Caused by: java.lang.NullPointerException
at javax.xml.bind.ContextFinder.handleClassCastException(ContextFinder.java:129)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:201)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:146)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:371)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:446)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:409)
Looking at the source for ContextFinder I can see that context must be null on line 129:
throw handleClassCastException(context.getClass(), JAXBContext.class);
I thought perhaps the problem was that my module has a dependency on jaxb-api 2.2.11 but the jaxb-impl classes are provided by rt.jar at runtime and are probably newer than 2.2.11 because Liferay DXP runs on JDK 1.8. To get around this issue, I have tried including jaxb-impl.jar 2.2.11 as a dependency in my osgi module, thinking then the jaxb-api & jaxb-impl versions would match. After that, trying to create a JAXBContent using the same code as above results in the following error:
ClassCastException: attempting to cast jar:file:/C:/Program%20Files/Java/jdk1.8.0_144/jre/lib/rt.jar!/javax/xml/bind/JAXBContext.class to bundleresource://623.fwk616113009:13/javax/xml/bind/JAXBContext.class. Please make sure that you are specifying the proper ClassLoader.
By the looks of this message, the JAXBContext that is getting instantiated is from the version of JAXBContext that is loaded via rt.jar. This is very confusing to me because I would expect the version of JAXBContext loaded by my module’s classloader to be used since I’ve included jaxb-impl.jar in my module and I’ve specified my module’s classloader is the one to be used in my call to JAXBContext.newInstance. Can anyone shed some light on how I can get jaxb 2.2.11 to work in an osgi container?
*Please note that I can’t upgrade the version of jaxb-api used by my module because the JAXB code is actually in a 3rd party jar that requires jaxb 2.2.11 (I have just eliminated the 3rd party jar from the equation for now by writing some test JAXB code).
After extensive research I found the following solution. Since it seemed like passing the bundle class loader as suggested by the accepted answer in this post had to be correct, I followed the path of figuring out why I was getting a NullPointerException when I tried that. After carefully looking over the source code for jaxb-api to follow the stack trace of the NullPointerException, I could see that the jaxb-api code does things like
classLoader.loadClass("com.sun.xml.internal.bind.v2.ContextFactory")
where classLoader is my bundle's class loader (since that's what I passed in) and ContextFactory is actually a class in jaxb-impl which is loaded by the bootstrap class loader. This is where the problem lies because my
bundle's classloader isn't going to be able to see classes loaded by the bootstrap class loader. This threw me for a while because I'm not used to how class loaders work in osgi. I incorrectly was thinking the classes loaded by the bootstrap class loader would be visible because I'm used to web app class loading where there is delegation. In osgi class loaders
are completely isolated from each other, things are only visible if they are exported. To get around the issue I found some helpful posts talking about similiar issues. It turns out there is a concept
called boot delegation in osgi where you can specify a list of classes/packages to always be loaded via the bootstrap classloader. So the end result is two steps:
1) Switch the thread's class loader to your bundle class loader before calling the code to get the JAXBContext:
ClassLoader currentClassLoader = Thread.currentThread().getContextClassLoader();
try {
// ObjectFactory here is in the same package as my classes to be marshalled
ClassLoader objectFactoryClassLoader = ObjectFactory.class.getClassLoader();
Thread.currentThread().setContextClassLoader(objectFactoryClassLoader);
// JAXB code goes here
} finally {
Thread.currentThread().setContextClassLoader(currentClassLoader);
}
2) Specify packages to be loaded using the boot delegation mechanism. This list needs to include the transitive dependencies of the classes you need loaded. In my case, I'm using Liferay so the list
is specific to Liferay and it goes in portal-ext.properties configuration file. Luckily I found this post where someone had done most of the work for me:
module.framework.properties.org.osgi.framework.bootdelegation=\
__redirected,\
com.liferay.aspectj,\
com.liferay.aspectj.*,\
com.liferay.portal.servlet.delegate,\
com.liferay.portal.servlet.delegate*,\
com.sun.ccpp,\
com.sun.ccpp.*,\
com.sun.crypto.*,\
com.sun.image.*,\
com.sun.jmx.*,\
com.sun.jna,\
com.sun.jndi.*,\
com.sun.mail.*,\
com.sun.management.*,\
com.sun.media.*,\
com.sun.msv.*,\
com.sun.org.*,\
com.sun.syndication,\
com.sun.tools.*,\
com.sun.xml.*,\
com.yourkit.*,\
org.eclipse.persistence.internal.jaxb,\
org.eclipse.persistence.internal.jaxb.*,\
javax.xml.*,\
sun.*
Helpful links:
Why can't JAXB find my jaxb.index when running inside Apache Felix?
What is the difference between bootdelegation and DynamicImport-Package in osgi
https://web.liferay.com/web/user.26526/blog/-/blogs/liferay-dxp-and-weblogic-
https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-0/bundle-classloading-flow
http://apache-felix.18485.x6.nabble.com/Classloading-for-JAXB-td4834670.html
Here is the workaround that worked for me using JDK 11, Liferay DXP/7.2, OSGI, with a sample Jax-RS web service created from Dev Studio. The error I was getting was as follows when trying to access the web service:
JAXBException occurred : Implementation of JAXB-API has not been found
on module path or classpath..
com.sun.xml.internal.bind.v2.ContextFactory cannot be found by
org.apache.aries.jax.rs.whiteboard_1.0.4.
What worked for me was to define the context factory at the system level to override the predefined context factory. Add the following system variable to your system
javax.xml.bind.JAXBContextFactory=com.sun.xml.bind.v2.ContextFactory
For example you can add this in your setenv.sh/bat file in Tomcat, or in eclipse you can access your server Launch Configuration, Arguments tab, under VM arguments
-Djavax.xml.bind.JAXBContextFactory=com.sun.xml.bind.v2.ContextFactory
This worked without adding any extra libraries since Liferay already has those libraries included.
How does this work? Refer to the javadoc for JaxBContext and read the Discovery of JAXB implementation Section. Using the /META-INF/services/javax.xml.bind.JAXBContext file did not work for me.
I hope this helps someone.
One final note for DXP users, if you get a permission denied on your service then you need to read about Service Access Policies
The best place to see how it should be done is Apache Karaf. It doesn't install any JAXB-API bundle - instead it uses org.apache.servicemix.specs.jaxb-api-2.2-2.7.0.jar inside lib/endorsed directory.
This way you won't use JAXB-API provided by rt.jar.
For implementation - it's best to use ServiceMix version of JAXB bundles:
org.apache.servicemix.bundles:org.apache.servicemix.bundles.jaxb-impl:2.2.11_1
org.apache.servicemix.bundles:org.apache.servicemix.bundles.jaxb-xjc:2.2.11_1
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.
My problem is this exception:
Caused by: <openjpa-2.1.1-r422266:1148538 nonfatal user error> org.apache.openjpa.persistence.ArgumentException: This configuration disallows runtime optimization, but the following listed types were not enhanced at build time or at class load time with a javaagent: "
I'm trying to get an very simple java application with jsf and jpa running, but there seems to be a problem with the enhancement of my entities. As far as I know, tries OpenJPA to enhance my entities at runtime, which are listet in the persistence.xml, however there is no agent to do this. The keyword for this is: Enhancing at Runtime, right?
I thought the enhancement will automatically done by the application server at deployment? How can I configure this?
My exactly environment:
Glassfish 3.1.1
Derby, which is integrated in Glassfish
OpenJPA 2.1.1
Mojarra JSF 2.1.3
Update #1:
After some comments I've added the following lines to my persistence.xml:
<property name="openjpa.DynamicEnhancementAgent" value="false"/>
<property name="openjpa.RuntimeUnenhancedClasses" value="supported" />
It works now, but OpenJPA throw this warning:
SEVERE: 52 myApp WARN [http-thread-pool-8080(5)] openjpa.Enhance - Creating subclass for "[class myApp.model.entities.AbstractEntity, class myApp.model.entities.Post]".
This means that your application will be less efficient and will consume more memory than it would if you ran the OpenJPA enhancer. Additionally, lazy loading will not be available for one-to-one and many-to-one persistent attributes in types using field access; they will be loaded eagerly instead.
I think this can't be the solution.
Update #2:
Refer to fvu's answer, I've tried to define the -javaagent jvm parameter in the domain.xml and over the web admin console. After a restart appeared the problem again.
Update #3:
Refer to update #2, I've played a bit around. There must be thrown an error, when the -javaagent parameter is used, but the file is missing, right?. Yes, there it is:
Waiting for domain1 to start .Command start-domain failed.
Error starting domain domain1.
The server exited prematurely with exit code 1.
Before it died, it produced the following output:
Error occurred during initialization of VM
agent library failed to init: instrument
Error opening zip file or JAR manifest missing : /tmp/openjpa.jar
If I copying the agent to this location, this error doesn't appear, but openjpa could still not enhance my entities!
If you're still having issues... I'd highly recommend biting the bullet and setting up build time enhancement. You'll be much happier in the long run if you get that going.
A couple of ideas:
add the Java agent for enhancement to GF's JVM option, see this link for an example of how to install a javaagent and OpenJPA's doc 5.2.3, enhancing at runtime. That emulates enhancer activation in desktop apps as closely as possible IMO.
However, when I read chapter 5.2.4 of the OpenJPA docs it might be capable of picking up the correct enhancer automatically. Try copying openjpa.jar to the domain's library directory, and check what happens after a server restart.
I deployed my app in Tomcat7 with jsf 2.1.2, while accessing my jsp page I am getting an IOException
org.apache.jasper.JasperException: /login.jsp (line: 4, column: 56) Unable to read TLD "META-INF/html_basic.tld" from JAR file "jndi:/localhost/AdminUI/WEB-INF/lib/jsf-impl-2.1.2.jar": java.io.IOException: The system cannot find the path specified
but the needed file is present inside the JAR under META-INF. Is this a jsf bug?
Tomcat is bundled with few api's like servlet-api, jsp-api which might be causing conflicts. So i suggest deploying the application with empty lib and add libraries based on the error logs (i mean the deployment errors not the compilation error) so this way you are sure that you add right libraries.
Note: some libraries are required for compilation and not for deployment purpose since the server is already packed with those!
I had the same issue which i solved by having only jsf-api, jsf-impl,jstl-x and log4j.x (in my case)