I have a Spring web application that can operate in “special” mode where mockito is used to spy on certain objects. Some of those objects are final (protobuf messages). I know, this may smell like a bad idea but lets say it’s an experiment. When enabling mock-maker-inline extension so final objects can be spied on I’m running into issues that seem to be related to byte buddy and loading some native libraries. When not using extension (and not spying on final classes) everything works as expected. Below is truncated stack trace.
java.lang.IllegalStateException: Could not initialize plugin: interface org.mockito.plugins.MockMaker (alternate: null)
…
Caused by: java.lang.IllegalStateException: Failed to load interface org.mockito.plugins.MockMaker implementation declared in sun.misc.CompoundEnumeration#60cc2b75
…
Caused by: java.lang.reflect.InvocationTargetException
…
Caused by: org.mockito.exceptions.base.MockitoInitializationException:
Could not initialize inline Byte Buddy mock maker.
It appears as if your JDK does not supply a working agent attachment mechanism.
Java : 1.8
JVM vendor name : AdoptOpenJDK
JVM vendor version : 25.265-b01
JVM name : OpenJDK 64-Bit Server VM
JVM version : 1.8.0_265-b01
JVM info : mixed mode
OS name : Mac OS X
OS version : 10.15.7
…
Caused by: java.lang.IllegalStateException: Error during attachment using: net.bytebuddy.agent.ByteBuddyAgent$AttachmentProvider$Compound#633c165e
…
Caused by: java.lang.reflect.InvocationTargetException
…
Caused by: java.lang.UnsatisfiedLinkError: Native Library /Users/…/.sdkman/candidates/java/8.0.265.hs-adpt/jre/lib/libattach.dylib already loaded in another classloader
This is an unfortunate limitation of JVMs that is solved in Java 9+. In Java 8-, the attachment library can only be bound by a single class loader. It seems as if Byte Buddy and another library attemts a self-attach (maybe EhCache) and bind the virtual machine API.
Can you identify what other library is self-attaching and possibly prevent this?
In my case the project contained an older version of JMockit 'org.jmockit:jmockit:1.24' which was clashing with mockit-inline. Removing JMockit entirely or upgrading it to 1.49 resolves the problem
https://github.com/mockito/mockito/issues/1879#issuecomment-783326979
Related
I must have something misconfigured - a missing library perhaps?
I get this error when trying to play a .wav sound in the simulator.
I have jfxrt.jar in the build path.
Exception in thread "JavaFX Application Thread" java.lang.UnsatisfiedLinkError: com.sun.media.jfxmediaimpl.platform.gstreamer.GSTMediaPlayer.gstGetAudioSpectrum(J)J
at com.sun.media.jfxmediaimpl.platform.gstreamer.GSTMediaPlayer.gstGetAudioSpectrum(Native Method)
at com.sun.media.jfxmediaimpl.platform.gstreamer.GSTMediaPlayer.<init>(GSTMediaPlayer.java:57)
at com.sun.media.jfxmediaimpl.platform.gstreamer.GSTMediaPlayer.<init>(GSTMediaPlayer.java:62)
I'm guessing that you are running on one VM while having the jfxrt.jar from another VM in the path. Try making sure that you are running on Java 8 where this should "just work". Make sure that in the "Library" section in netbeans JDK 8 is selected.
I am using template Spring Boot application with servlets. When I add to the application latest Jersey (for jax-rs) and then add Groovy framework to the application (only for testing) I start having problems running the application from within IntelliJ.
It seems that some libraries on the Groovy classpath collide with the libraries coming from Jersey (servlet-api and ASM) but I am not yet 100% sure this is the problem. For sure the classpath IntelliJ builds is different from maven's
seems to be connected to the tricks that the spring-boot maven plug-in does, but that's only a suspicion. running via java -jar fails, while running via mvn spring-boot:run works (from the command line as well from IntelliJ).
I get this exception:
Caused by: org.apache.catalina.LifecycleException: A child container failed during start
looks like part of the problem was how I set-up my gmaven.
when I set it up like in this post https://stackoverflow.com/a/19539452/672738 the problem is gone and my application happily boots with java -jar in IntelliJ
I just solve this problem.
Groovy also includes the servlet-api lib which is conflict with the lib imported by spring boot.
You can just exclude the servlet-api from groovy.
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".
Has anyone had success implementing IBM Worklight 5.0.6 Adapters using the Groovy language? Ie. Instead of calling a Java class from the JS adapter call a Groovy class. We have tried this and it seems to work most of the time but randomly we will get strange errors when invoking an adapter procedure. Ie.
Failed to create DGM method proxy : java.lang.NoSuchMethodException: org.codehaus.groovy.runtime.dgm$24.<init>(java.lang.String, org.codehaus.groovy.reflection.CachedClass, java.lang.Class, [Ljava.lang.Class;)
FWLSE0101E: Caused by: java.lang.NoSuchMethodException: org.codehaus.groovy.runtime.dgm$24.<init>(java.lang.String, org.codehaus.groovy.reflection.CachedClass, java.lang.Class, [Ljava.lang.Class;)
Unit tests executing the Groovy code run fine within Eclipse and the Groovy code seems to be compiling fine down to .class files and included in the adapter package. We're wondering if this is an issue with Groovy itself or invoking Groovy within the Worklight server container. I believe Worklight is using Rhino behind the scenes which may also be a culprit?
We are using Groovy 2.1.5 and the Eclipse plugin 2.8
did you open the .war and check if all compiled classes and libraries are actually in there?
We had the case quite often that the WL Eclipse Plugin/Build did not compile and package our Java Classes for the Adapter in the "server" folder ... they were missing in the .war file that we deployed and we got all sorts of Rhino, ClassNotFound etc. errors.
In addition to previous answer. You can always force a rebuild by selecting the project in the Enterprise Explorer or Navigator views, then select menu Project -> Clean -> Clean Projects Selected Below (the only choice should be your project).
This will clean the binaries, then rebuild your entire project.
I imported a netbeans project into eclipse ( Pulsar for Mobile Developers.Version: Helios Service Release 1, Build id: 20100917-0705).
I have two errors multiple times -
The method nextInt() in the type Random is not applicable for the arguments (int)
The method equalsIgnoreCase(String) is undefined for the type String
The project works fine in netbeans but I am unable to debug it due to OutOfMemoryError and hence the switch to eclipse.
I have seen this but it did not solve my problem.
Any other hint to solve this problem ?
Salil
This is a bug on the WTK/eclipse integration https://bugs.eclipse.org/bugs/show_bug.cgi?id=315209
1.The method nextInt() in the type Random is not applicable for the
arguments (int)
2.The method equalsIgnoreCase(String) is undefined for the type String
The above two problems were solved by compiling the code using the latest Nokia S40 SDK.
The project works fine in netbeans but
I am unable to debug it due to
OutOfMemoryError and hence the switch
to eclipse.
Java Me 3.0 SDK comes installed with NetBeans but it is missing the Java_Platform_ME_SDK.exe found in C:\Java_ME_platform_SDK_3.0\toolbar\bin. I had to remove the default J2ME platform ( C:\Program Files (x86)\NetBeans 6.9.1\mobility\Java_ME_platform_SDK_3.0 ) and add the platform installed here - C:\Java_ME_platform_SDK_3.0.
Using Java_Platform_ME_SDK.exe I increased the emulator heap size to maximum and now I am able to debug my application.
Salil