I'm using a VMware jar in my Tomcat webapp to gather VM information. When launching JProfiler from inside IDEA 10.5 everything runs fine until I call into the VMware jar whereupon I get an IllegalAccessException.
Is there a way to prevent JProfiler from looking into the jar? I tried an exclusion filter on com.vmware.vim25 but that had no effect.
Here's the stack trace:
java.lang.IllegalAccessException: Class com.vmware.vim25.ws.XmlGen can not access a member of class java.lang.Object with modifiers "static transient"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
at java.lang.reflect.Field.doSecurityCheck(Field.java:960)
at java.lang.reflect.Field.getFieldAccessor(Field.java:896)
at java.lang.reflect.Field.get(Field.java:358)
at com.vmware.vim25.ws.XmlGen.toXML(XmlGen.java:696)
at com.vmware.vim25.ws.XmlGen.toXML(XmlGen.java:633)
at com.vmware.vim25.ws.XmlGen.toXML(XmlGen.java:707)
at com.vmware.vim25.ws.XmlGen.toXML(XmlGen.java:633)
at com.vmware.vim25.ws.XmlGen.toXML(XmlGen.java:584)
at com.vmware.vim25.ws.WSClient.createSoapMessage(WSClient.java:219)
at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:170)
at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:124)
at com.vmware.vim25.ws.VimStub.retrieveProperties(VimStub.java:77)
at com.vmware.vim25.mo.PropertyCollector.retrieveProperties(PropertyCollector.java:107)
at com.vmware.vim25.mo.ManagedObject.retrieveObjectProperties(ManagedObject.java:155)
at com.vmware.vim25.mo.ManagedObject.getCurrentProperty(ManagedObject.java:179)
at com.vmware.vim25.mo.ManagedObject.getManagedObjects(ManagedObject.java:221)
at com.vmware.vim25.mo.ManagedObject.getManagedObjects(ManagedObject.java:268)
at com.vmware.vim25.mo.ManagedObject.getVms(ManagedObject.java:298)
at com.vmware.vim25.mo.Datastore.getVms(Datastore.java:81)
[snip]
The JProfiler people got back to me and suggested trying a pre-release version of 7.1 as they've changed the way the product works in this area. This new version does indeed solve this problem so I'm now able to move forward.
Related
Every time I encounter this exception in IntelliJ, I fix it trivially and forget the fix easily.
Code:
package whatever;
import org.junit.Test;
public class TestClass
{
#Test
void test() {}
}
Scenario:
Add new TestClass.
Right-click TestClass.
Select "Run 'TestClass'" to run test cases.
The "Messages Build" pane shows:
Information:javac 9-ea was used to compile java sources
Information:Module "dummy" was fully rebuilt due to project configuration/dependencies changes
Information:8/16/17 11:35 PM - Compilation completed with 1 error and 0 warnings in 1s 663ms
Error:java: java.lang.ExceptionInInitializerError
What can possibly go wrong?
What are the likely issues in this simple scenario?
IntelliJ: COMMUNITY 2017.1 (idea-IC-171.4424.56)
To fix the issue, I do:
File -> Project Structure... -> Project Settings / Project -> Project SDK.
Change from "9-ea" to "1.8".
DETAILS
Apparently, the issue is discrepancies in selected JDK-s to build (java 9) and run (java 8).
I'm not sure how "9-ea" gets re-selected there for the same project - neither IntelliJ itself runs in "9-ea" JRE (according to Help -> About) nor JAVA_HOME env var is set to it nor other possible settings (like Maven -> Runner) suggest any "9-ea".
I also didn't manage to run the test under the same JDK (java 9) which it gets compiled under. However, it's unclear what JDK tests are run under because IntelliJ reports only about JDK for compilation.
If you use Lombok: For me it was a solution to set the newest version for my maven lombok dependency in the pom.xml.
*<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
<version>1.18.8</version>
</dependency>*
I was facing same error when i tried to run my application in IntelliJ-2019.2 version. Below are the steps i followed to resolve this issue.
Versions:
IntelliJ : IDEA-IntelliJ-2019.2
Java : jdk1.8_221
Go to below path in IntelliJ
File -> Project Structure -> Project -> Project SDK -> (select java version which you want to use )
(In my case under 'project SDK' java-11 was selected, I changed it to 'java8')
Click on 'Apply' and then 'OK'.
I feel I ran into this issue because IntelliJ was trying to compile my java classes using in-built java-11 whereas my java classes are built on java-8. So when i explicitly configured java-8 in IntelliJ, It worked!! Hope this helps.
I started seeing this exception once I installed Java 11 in my machine. JAVA_HOME was by default pointing to Java 11 and my project was still in Java 8. Changing JAVA_HOME to Java 8 jdk fixed the issue for me.
If you have multiple projects each running on a different JDK, use this command to temporarily change the Java version per command.
JAVA_HOME=/path/to/JVM/jdk/Home mvn clean install
If you have recently updated your IDE then you can try these steps.
Delete .idea directory for the idea project/workspace
Then go to File -> Invalidate Caches / Restart...
Once Idea is restarted re-add/import your module(s)
I faced a similar issue with JARs and Jena (while run from IntelliJ it works).
I was using Apache Jena v4.0.0 in my project and have built a JAR (with a main class for the JAR to act as a console app).
The JAR builts successfully with IntelliJ but when run throws java.lang.ExceptionInInitializerError ... Caused by: java.lang.NullPointerException. NPE suggests that something was not initialized properly.
The jar built with previous version Jena 3.17.0 works perfectly.
What I did to fix it
I've opened both the JARs, compared their META-INF folders and encountered the difference in
my.jar\META-INF\services\org.apache.jena.sys.JenaSubsystemLifecycle
The new version (jena v4.0.0) contains only one line:
org.apache.jena.tdb.sys.InitTDB
The old version (jena v3.17.0) contains two different lines:
org.apache.jena.riot.system.InitRIOT
org.apache.jena.sparql.system.InitARQ
I've added the old two lines to the file and repacked new JAR with it:
org.apache.jena.tdb.sys.InitTDB
org.apache.jena.riot.system.InitRIOT
org.apache.jena.sparql.system.InitARQ
It resolved my issue.
Update: recent Jena v4.4.0 builts with the same "bug".
I'm not an expert and there is probably a better way than patching a JAR by hand.
But I still hope that this solution will help someone like me.
I've faced an issue with configuring RabbitMQ with Spring Boot.
I need to override host value for my application. I use JavaConfig approach. I use auto configuration feature as well.
So I put spring.rabbitmq.host=myhost.com property into application.properties but RabbitMQ ConnectionFactory still created with localhost value.
UPDATE1: Seems like my embedded Tomcat instance doesn't pick up updates in property files. I've added some custom property and Spring can't resolve the placeholder for it.
I run my application in IntellijIdea 14 as a common java app.
All class changes are picked up by IntellijIdea&Tomcat but all resources folder content is not.
Is this IntellijIdea 14 related issue?
Thanks in advance.
If you do that from test-case, be sure to use:
#ContextConfiguration(initializers = ConfigFileApplicationContextInitializer.class)
For the test class.
I think the name of the initializer should say for itself.
Issue was resolved. There was issue with IntellijIdea 14 & 13 Gradle project setup/files compatibility. So Re-Import of the project is a solution.
I am trying to use ActiveMQ 5.10.0 with SoapUI 4.6 and Hermes 1.14. I get the error below when I try and add a queue. I presume Hermes can't find the type IdGenerator in any of the loaded jars. Which are:
activemq-client-5.10.0.jar
geronimo-j2ee-management_1.1_spec-1.0.1.jar
geronimo-jms_1.1_spec-1.1.1.jar
Does anyone know where this class is defined? I looked for activemq-util.jar in the binary distribution but I did not find such a file.
Error:
java.lang.NoClassDefFoundError: Could not initialize class org.apache.activemq.util.IdGenerator
at org.apache.activemq.ActiveMQConnectionFactory.getClientIdGenerator(ActiveMQConnectionFactory.java:969)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:363)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:331)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:303)
at org.apache.activemq.ActiveMQConnectionFactory.createQueueConnection(ActiveMQConnectionFactory.java:260)
at hermes.impl.jms.ConnectionManagerSupport.createConnection(ConnectionManagerSupport.java:147)
at hermes.impl.jms.ConnectionManagerSupport.createConnection(ConnectionManagerSupport.java:92)
at hermes.impl.jms.ConnectionSharedManager.reconnect(ConnectionSharedManager.java:81)
at hermes.impl.jms.ConnectionSharedManager.connect(ConnectionSharedManager.java:91)
at hermes.impl.jms.ConnectionSharedManager.getConnection(ConnectionSharedManager.java:104)
at hermes.impl.jms.ConnectionSharedManager.getObject(ConnectionSharedManager.java:142)
at hermes.impl.jms.ThreadLocalSessionManager.connect(ThreadLocalSessionManager.java:190)
at hermes.impl.jms.ThreadLocalSessionManager.getSession(ThreadLocalSessionManager.java:570)
at hermes.impl.jms.AbstractSessionManager.getDestination(AbstractSessionManager.java:460)
at hermes.impl.DefaultHermesImpl.getDestination(DefaultHermesImpl.java:367)
at hermes.browser.tasks.BrowseDestinationTask.invoke(BrowseDestinationTask.java:141)
at hermes.browser.tasks.TaskSupport.run(TaskSupport.java:175)
at hermes.browser.tasks.ThreadPool.run(ThreadPool.java:170)
at java.lang.Thread.run(Unknown Source)
This is very old but in case anyone else is trying to get this spun up... don't use the built in HermesJMS that comes with SoapUI. Apparently there's a bug in it that doesn't play nice with ActiveMQ v5.8 and following [I tried 5.11 & 5.13 and had the issue. The cheating fix is to install the standalone [I had to get it from sourceforge].
The sourceforge jar is installed with [assuming version 1.14]: java -jar hermes-installer-1.14.jar
Once installed you can tie this version to soapui or launch it with the bat/sh file. I still had issues with ActiveMQ version 5.13 but version 5.11 worked for me.
The IdGenerator class is located in the activemq-client jar. Here is the result of a search in the source tree:
/activemq-client/src/main/java/org/apache/activemq/util/IdGenerator.java
There's been no recent changes so I'd guess that the error is misleading and that it's actually some other missing dependency that's being loaded when the class is created. Is there more information in the log or a 'caused by exception' ?
For whom it may interest. This is kind of common issue I come accross from time to time. I call it jar version incompatibility. I was getting exception in title and other funny exceptions when using latest (but not actively developed) hermes 1.14 and currently latest Apache Active MQ 5.14. I've found out after a long struggle that it is fixed by using an older version of Active MQ - like 5.3.
I'm trying to upgrade an application to Java 7 from Java 6 and I'm getting a new exception that isn't present when running the application under Java 6.
Here's the first section of the stack trace:
java.lang.ClassCastException: java.lang.String cannot be cast to org.jboss.serial.finalcontainers.IntegerContainer
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readInt(DataContainer.java:1044)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:310)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:845)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.RegulrObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:845)
at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:364)
at java.util.ArrayList.readObject(ArrayList.java:733)
at sun.reflect.GeneratedMethodAccessor352.invoke(Unknown Source)
I found this JBoss bug, which is supposedly fixed...
https://issues.jboss.org/browse/JBSER-128
but the version it's fixed in (1.0.6.FINAL) hasn't been released yet:
https://issues.jboss.org/browse/JBSER
Has anybody run into this that could suggest a workaround?
The application runs in JBoss 6.0.0.
PS I am aware that JBoss 6 is past its EOL and not tested with Java 7.
Well, you could build the release yourself from the tag in the SVN repo. Or if you're really trusting (or want to do a quick experiment) download the binary I built (here, won't promise they stay online though).
Just replace all occurrences of the jar in the JBoss distribution and don't forget to enable the fix with system property
-Dorg.jboss.serial.sync_binary_formats=true
As highlighted here
https://issues.jboss.org/browse/JBSER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
Anyhow for me this worked for Vectors at least (there's other potential problems, but not being able to transfer CCHashMaps I'll survive ;) ).
I found a workaround solution for my problem. Since Java 7 changed the serialization behavior of Vector, I changed to ArrayList (which did not change) and the problem has been resolved.
Hope this helps somebody out there struggling with the same issue.
during "Build All and Deploy" of a worklight application, I get the following error.
An internal error occurred during: "Worklight application builder".
loader constraint violation: when resolving method "org.apache.commons.io.FileUtils.iterateFiles(Ljava/io/File;Lorg/apache/commons/io/filefilter/IOFileFilter;Lorg/apache/commons/io/filefilter/IOFileFilter;)Ljava/util/Iterator;"
the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader)
of the current class, com/worklight/builder/skins/impl/SkinBuilderImpl,
and the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader)
for resolved class, org/apache/commons/io/FileUtils,
have different Class objects for the type leUtils.iterateFiles(Ljava/io/File;Lorg/apache/commons/io/filefilter/IOFileFilter;Lorg/apache/commons/io/filefilter/IOFileFilter;)Ljava/util/Iterator;
used in the signature
Console output is
[2013-03-26 15:30:13] Worklight Server started successfully on localhost:8080
[2013-03-26 15:30:13] Activating Worklight project: AA...
[2013-03-26 15:30:28] FWLSE3005I: Application raw reports are disabled.
[2013-03-26 15:30:28] FWLST0010I: ====== Started server for project AA-project-customization; Worklight version=5.0.5.20130115-0926-developer-edition
[2013-03-26 15:30:28] Activation done.
[2013-03-26 15:30:28] Starting build process: application 'ap', all environments
I believe this bug is also discussed in https://www.ibm.com/developerworks/forums/thread.jspa?threadID=465649 (read only)
For me it seems that this bug is pretty well reproducable.
It occurs every time another plugin is installed which contains/uses the org.apache.commons.io package
In my case I have an org.apache.commons.io_2.0.1.v201105210651.jar in my plugins folder (which was delivered by Sonar 2.4.0). It contains the same java classes as plugins\com.worklight.worklight-3rd-parties_5.0.5.20130115-0926\target\dependency.
This is also a matter of ordering, as the error only occurs if Worklight is installed AFTER another org.apache.commons.io-using package was installed.
So I strongly believe that the problem is because there are different classes with the same (package) name (WHY ??)
I thought about setting classloader preferences (parent first etc). but I don´t know how and I don´t know where to set.
Just deleting the 3rd parties .jar´s only leads to other errors ...
Any hints are greatly appreciated.
Thank you very much !
As a workaround, can you try and delete the commons.io plugin from your eclipse?
Hopefully, Sonar is using import-package and not require-bundle, and it will work, and this way Worklight won't have conflicts.