java.lang.NoSuchFieldError: INSTANCE in Apache HttpComonents and Wildfly - wildfly

I get the following error when running an app using HttpComponents 4.3.6 in Wildfly. How can I fix this?
Caused by: java.lang.NoSuchFieldError: INSTANCE
at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(DefaultHttpRequestWriterFactory.java:52) [httpcore-4.3.3.jar:4.3.3]
at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(DefaultHttpRequestWriterFactory.java:56) [httpcore-4.3.3.jar:4.3.3]
at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<clinit>(DefaultHttpRequestWriterFactory.java:46) [httpcore-4.3.3.jar:4.3.3]
at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>(ManagedHttpClientConnectionFactory.java:72) [httpclient-4.3.6.jar:4.3.6]
at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>(ManagedHttpClientConnectionFactory.java:84) [httpclient-4.3.6.jar:4.3.6]
at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<clinit>(ManagedHttpClientConnectionFactory.java:59) [httpclient-4.3.6.jar:4.3.6]
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager$InternalConnectionFactory.<init>(PoolingHttpClientConnectionManager.java:494) [httpclient-4.3.6.jar:4.3.6]
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:149) [httpclient-4.3.6.jar:4.3.6]
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:138) [httpclient-4.3.6.jar:4.3.6]
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:114) [httpclient-4.3.6.jar:4.3.6]
at org.apache.http.impl.client.HttpClientBuilder.build(HttpClientBuilder.java:726) [httpclient-4.3.6.jar:4.3.6]
at org.apache.http.impl.client.HttpClients.createDefault(HttpClients.java:58) [httpclient-4.3.6.jar:4.3.6]

Every post on the subject says that this is because of a conflict between different versions of HttpComponents. In my case it was a conflict between the version I imported into my app, and the version supplied with Wildfly.
To work around it, you'll need a file called WEB-INF/jboss-deployment-structure.xml with the following:
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.apache.httpcomponents" />
</exclusions>
</deployment>
That will prevent wildfly from loading the older version and interfering with your new version.
See https://docs.jboss.org/author/display/WFLY8/Class+Loading+in+WildFly for more details.

Related

Cannot use MongoDB driver "mongodb-driver-sync" in OSGi Project: Unable to resolve

We are developing an OSGi application running on Apache Karaf. Our application uses Apache Camel and MongoDB.
First we successfully used a quite old version of "mongo-java-driver" (3.12.11): By adding this dependency to the modules pom.xml and to the osgi feature repository we were able to start our application and connect to MongoDB:
pom.xml (maven module1)
<dependency>
<groupId>org.mongodb</groupId>
<artifactId>mongo-java-driver</artifactId>
<version>3.12.11</version>
</dependency>
feature.xml:
<repository>mvn:org.apache.camel.karaf/apache-camel/3.18.4/xml/features</repository>
<feature name="module1" description="An OSGi module" version="1.0.1-SNAPSHOT">
<feature>scr</feature>
<feature prerequisite="true">aries-blueprint</feature>
<feature>camel-core</feature>
<feature>camel-blueprint</feature>
<feature>camel-cxf</feature>
<feature>camel-xslt-saxon</feature>
<feature>camel-jetty</feature>
<feature>camel-rabbitmq</feature>
<feature>camel-openapi-java</feature>
<feature>camel-jackson</feature>
<capability>osgi.service;objectClass=org.apache.aries.blueprint.NamespaceHandler;osgi.service.blueprint.namespace=http://camel.apache.org/schema/blueprint;effective:=active;
</capability>
<bundle dependency="true">mvn:org.mongodb/mongo-java-driver/3.12.11</bundle>
<bundle>mvn:my.own.project/module1/1.0.1-SNAPSHOT</bundle>
</feature>
But that driver is legacy, quite old and missing important features, so we would like to use a modern driver, namely mongodb-driver-sync (version 4.8.2).
We replaced the previous driver with "mongodb-driver-sync":
pom.xml (maven module1)
<dependency>
<groupId>org.mongodb</groupId>
<artifactId>mongodb-driver-sync</artifactId>
<version>4.8.2</version>
</dependency>
feature.xml:
<repository>mvn:org.apache.camel.karaf/apache-camel/3.18.4/xml/features</repository>
<feature name="module1" description="An OSGI module" version="1.0.1-SNAPSHOT">
<feature>scr</feature>
<feature prerequisite="true">aries-blueprint</feature>
<feature>camel-core</feature>
...
<!-- <bundle dependency="true">mvn:org.mongodb/mongo-java-driver/3.12.11</bundle>-->
<bundle dependency="true">mvn:org.mongodb/mongodb-driver-sync/4.8.1</bundle>
<bundle>mvn:my.own.project/module1/1.0.1-SNAPSHOT</bundle>
</feature>
This fails when starting the feature in Karaf:
Error executing command: Unable to resolve root: missing requirement [root] osgi.identity;
osgi.identity=mesh; type=karaf.feature; version="[1.0.1.SNAPSHOT,1.0.1.SNAPSHOT]";
filter:="(&(osgi.identity=mesh)(type=karaf.feature)(version>=1.0.1.SNAPSHOT)(version<=1.0.1.SNAPSHOT))"
[caused by: Unable to resolve mesh/1.0.1.SNAPSHOT: missing requirement [mesh/1.0.1.SNAPSHOT] osgi.identity; osgi.identity=mesh-vms-tso01; type=karaf.feature
[caused by: Unable to resolve mesh-vms-tso01/1.0.1.SNAPSHOT: missing requirement [mesh-vms-tso01/1.0.1.SNAPSHOT] osgi.identity; osgi.identity=mesh-vms-tso01; type=osgi.bundle; version="[1.0.1.SNAPSHOT,1.0.1.SNAPSHOT]"; resolution:=mandatory
[caused by: Unable to resolve mesh-vms-tso01/1.0.1.SNAPSHOT: missing requirement [mesh-vms-tso01/1.0.1.SNAPSHOT] osgi.wiring.package; filter:="(&(osgi.wiring.package=com.btc.mesh.core.camel)(version>=1.0.0)(!(version>=2.0.0)))"
[caused by: Unable to resolve mesh-core/1.0.1.SNAPSHOT:
missing requirement [mesh-core/1.0.1.SNAPSHOT] osgi.wiring.package; filter:="(&(osgi.wiring.package=com.mongodb)(version>=4.8.0)(!(version>=5.0.0)))"]]]]
I also tried version 4.1.0 because an older documentation mentioned that it is a valid OSGI bundle:
The mongodb-driver-sync artifact is a valid OSGi bundle whose symbolic
name is org.mongodb.driver-sync."
https://mongodb.github.io/mongo-java-driver/4.1/driver/getting-started/installation/
But we also had no luck. Does the symbolic name help in any way?
After version 4.3.x the documentation moved from mongodb.github.io to www.mongodb.com and the reference to OSGi has been removed. The MANIFEST file of all mentioned drivers looks quite similar including the bundle information. So, AFAIK , OSGi should work. Very confusing.
So, we need your help
Has anyone more information about a modern MongoDB driver which is ready for OSGI?
Or maybe we are doing something wrong when integrating the driver into our OSGI module?
Thanx

Migration to Jakarta: ClassNotFoundException: com.sun.xml.internal.ws.spi.ProviderImpl

While migrating from Java 8 to Java 11 and switching from EE to the newest Jakarta libraries according to https://wiki.eclipse.org/New_Maven_Coordinates and Maven central, we get the following runtime exception in our (still SOAP-based) client application:
Exception in thread "main" javax.xml.ws.WebServiceException: Provider com.sun.xml.internal.ws.spi.ProviderImpl not found
at javax.xml.ws.spi.FactoryFinder$1.createException(FactoryFinder.java:31)
at javax.xml.ws.spi.FactoryFinder$1.createException(FactoryFinder.java:28)
at javax.xml.ws.spi.ServiceLoaderUtil.newInstance(ServiceLoaderUtil.java:73)
at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:82)
at javax.xml.ws.spi.Provider.provider(Provider.java:66)
at javax.xml.ws.Service.<init>(Service.java:82)
at [...]
Caused by: java.lang.ClassNotFoundException: com.sun.xml.internal.ws.spi.ProviderImpl
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at javax.xml.ws.spi.ServiceLoaderUtil.nullSafeLoadClass(ServiceLoaderUtil.java:60)
at javax.xml.ws.spi.ServiceLoaderUtil.safeLoadClass(ServiceLoaderUtil.java:93)
at javax.xml.ws.spi.ServiceLoaderUtil.newInstance(ServiceLoaderUtil.java:71)
... 5 more
The solution described in Getting java.lang.ClassNotFoundException: com.sun.xml.internal.ws.spi.ProviderImpl despite the dependencies are defined doesn't work and doesn't use Jakarta.
If I'm not wrong, the Jarkarta libraries shouldn't contain "com.sun.xml."packages or reference such, but javax.xml.ws.spi.Provider obviously STILL DOES reference such class:
private static final String DEFAULT_JAXWSPROVIDER =
"com.sun"+".xml.internal.ws.spi.ProviderImpl";
So, does anyone know if there is a Jakarta equivalent to the missing library containing ProviderImpl, or how I could workaround the problem with Jakarta?
Thanks in advance!
I finally found a workaround for my problem. According to the answer given in How to use WebServices on Java 11? package javax.jws does not exist the reference implementation of JAX-WS should be included with Java 11:
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-ri</artifactId>
<version>2.3.2</version>
<type>pom</type>
</dependency>
Unfortunately, compiling our project with this dependency using the latest maven-compile-plugin 3.8.0 causes the exception described in https://jira.apache.org/jira/browse/MCOMPILER-355. It should be fixed in 3.8.1 but the version is not available yet.
As a workaround I got our project working with the hint given in Getting java.lang.ClassNotFoundException: com.sun.xml.internal.ws.spi.ProviderImpl despite the dependencies are defined, combined with an additional dependency (namely resolver that is also linked in the pom.xml of jaxws-ri) to avoid an subsequent java.lang.ClassNotFoundException: com.sun.org.apache.xml.internal.resolver.CatalogManager:
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>rt</artifactId>
<version>2.3.2</version>
</dependency>
<dependency>
<groupId>com.sun.org.apache.xml.internal</groupId>
<artifactId>resolver</artifactId>
<version>20050927</version>
</dependency>
Maybe this helps someone running into the same problem.
Throwing my 5 cents into the ring as I had "the same problem". What resolved it to me was to stick with the version two of the jaxws-rt package, since version 3.0.0 did fail with the same results as mentioned above.
So what I used to get my JDK 8 source running without any modification was:
// https://mvnrepository.com/artifact/com.sun.xml.ws/jaxws-rt
implementation group: 'com.sun.xml.ws', name: 'jaxws-rt', version: '2.3.3' //3.0.0 did not work!
// https://mvnrepository.com/artifact/javax.xml.ws/jaxws-api
implementation group: 'javax.xml.ws', name: 'jaxws-api', version: '2.3.1'
// https://mvnrepository.com/artifact/javax.jws/javax.jws-api
implementation group: 'javax.jws', name: 'javax.jws-api', version: '1.1'

Drools compatibility with Java 11

When deploying an ear application containing a drools kie engine 7.20.0.Final on Wildfly 16.0.0.Final, I get a deployment failure exception that sun.reflect.ReflectionFactory class cannot be loaded. The application deploys fine with Java 8.
I understand that Java 11 has removed support for sun.reflect.Reflection. Does drools rely on it? The drools documentation only says the Java requirement is for Java 1.5 and nothing more.
Is drools compatible with Java 11?
Solved. Turns out the removal of sun.reflect from Java 11 was a red herring. the actual problem was with Wildfly 16 which didn't make the module available. Solution was to create a jboss-deployment-structure.xml as follows:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<deployment>
<dependencies>
<system export="true">
<paths>
<path name="sun/reflect"/>
</paths>
</system>
</dependencies>
</deployment>
</jboss-deployment-structure>
See this post: Mockito, Java 9 and java.lang.ClassNotFoundException: sun.reflect.ReflectionFactory

an internal error occurred during: uploading code to lambda

This exception is thrown while uploading code to lambda. I tried but no where found the solution.
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
at com.amazonaws.util.Md5Utils.md5AsBase64(Md5Utils.java:104)
at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:1647)
at com.amazonaws.eclipse.lambda.upload.wizard.util.UploadFunctionUtil.performFunctionUpload(UploadFunctionUtil.java:95)
at com.amazonaws.eclipse.lambda.upload.wizard.UploadFunctionWizard.doFinish(UploadFunctionWizard.java:111)
at com.amazonaws.eclipse.core.plugin.AbstractAwsJobWizard$1.run(AbstractAwsJobWizard.java:35)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException cannot be found by com.amazonaws.eclipse.javasdk_1.11.248
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 6 more
Make sure Eclipse is running with Java 8. AWS Toolkit requires JAXB for the upload to AWS S3, but JAXB was deprecated in Java 9 & 10, and removed from Java 11. If you're running Eclipse under Java 9, 10, or 11, Eclipse/AWS Toolkit won't find JAXB and you'll get this error.
You can resolve the problem by specifying the JVM Eclipse should use on startup. Instructions for various platforms found here: https://wiki.eclipse.org/Eclipse.ini
Another option is to add javax.xml.bind:jaxb-api to your dependencies
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.1</version>
</dependency>

Jboss Wildfly EJB3 and Mybatis Deployment Error: NoSuchMethodError javax.persistence.Table.indexes()[Ljavax/persistence/Index;

I'm trying to deploy a EAR file to Jboss Wildfly (8.1.0) but im getting the following exception:
Caused by: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;
My EAR file contains an EJB jar which contains mybatis (version 3.2.7) persistnence Units which have a Dependency on the cglib (version: 3.1).
This very same ear file deploy's and works without issues in JBoss 7 (version 7.1.1)
Based on the error saying the method isnt found but i know the class and method are there it must be some class conflict in the new version of jboss.
I managed to find the answer after some investigation and dissecting of the ear file. The problem was the asm.jar included in my EJB jar as a sub dependency of cglib. There is a class conflict between the jboss included jar and the EAR jar. To fix it simply add a maven exclusion on the cglib dependency for the asm sub dependency.
<exclusions>
<exclusion>
<groupId>org.ow2.asm</groupId>
<artifactId>asm</artifactId>
</exclusion>
</exclusions>