A BulkBeanException is being thrown when iBatis is attempting to apply a result map, but is not consistent across deployments via the same jar (local is fine, server deployment is not).
I figured out how to stop the problem (see my answer below), but am more interested in hearing about strategies to diagnose why the cglibification happened/happened differently in different runtime environments. I assume the inconsistent behavior is due to differences in the order in which libraries are loaded, but have not figured out how to confirm this ($PATH and $CLASSPATH resolved to the same thing in different environments). Is there something else I should be looking at?
Got error
java -jar <jar> on CentOS box
Mule runtime via Eclipse on OS X
Did not get error
java -jar <jar> on OS X
JUnit via Maven on OS X
JUnit via Eclipse on OS X
stack trace
Caused by: com.ibatis.common.jdbc.exception.NestedSQLException:
--- The error occurred in ibatis/MyClassName.xml.
--- The error occurred while applying a result map.
--- Check the MyClassName.result.
--- The error happened while setting a property on the result object.
--- Cause: net.sf.cglib.beans.BulkBeanException: 1
at com.ibatis.sqlmap.engine.mapping.statement.MappedStatement.executeQueryWithCallback(MappedStatement.java:204) ~[mybatis-2.3.5.jar!/:?]
at com.ibatis.sqlmap.engine.mapping.statement.MappedStatement.executeQueryForList(MappedStatement.java:139) ~[mybatis-2.3.5.jar!/:?]
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForList(SqlMapExecutorDelegate.java:578) ~[mybatis-2.3.5.jar!/:?]
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForList(SqlMapExecutorDelegate.java:552) ~[mybatis-2.3.5.jar!/:?]
at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForList(SqlMapSessionImpl.java:118) ~[mybatis-2.3.5.jar!/:?]
at org.springframework.orm.ibatis.SqlMapClientTemplate$3.doInSqlMapClient(SqlMapClientTemplate.java:298) ~[mybatis-2-spring-1.0.1.jar!/:1.0.1]
at org.springframework.orm.ibatis.SqlMapClientTemplate$3.doInSqlMapClient(SqlMapClientTemplate.java:296) ~[mybatis-2-spring-1.0.1.jar!/:1.0.1]
at org.springframework.orm.ibatis.SqlMapClientTemplate.execute(SqlMapClientTemplate.java:203) ~[mybatis-2-spring-1.0.1.jar!/:1.0.1]
... 77 more
The Java bean onto which iBATIS was attempting to apply the result map had unusual (non-bean-conformant?) setters. These setters did not return void as is standard, but returned the object itself so that set operations could be chained (we have some Haskell programmers working on this project :)).
Where it was occurring it was solved by changing the setter methods back to their previous state where they were defined with void return.
Had the same issue , ibatis was trying to set null value to primitive double which was causing the issue
Related
I have updated the Java version of our company application from 8 to 17.
On local machine it works fine, both in building and on run-time calls.
Also on GitHub it is deployed fine, along with the Junit test execution.
The problem is after I deploy the application on Heroku.
The Heroku build is on success, but on runtime, when I call the methods, I receive this error:
"message": "Handler dispatch failed; nested exception is java.lang.reflect.GenericSignatureFormatError: Signature Parse error: expected a class type\n\tRemaining input: java/util/concurrent/CompletableFuture",
It's something related to java reflection methods and the method's signature.
My controller rest method return a CompletableFuture Object.
Something is not good with the CompletableFuture.........
This error relates to this bug, which is being investigating.
Currently the workaround is to disable CompletableFuture instrumentation.
That can be done by adding the following to your newrelic.yml, under the common stanza:
class_transformer:
com.newrelic.instrumentation.java.completable-future-jdk8u40:
enabled: false
Update 2022-02-23: The bug in New Relic was caused by this bug in Java 17: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8282241
Update 2022-07-29: Java 19 early releases already contains a fix. Should be fixed in Java 17.0.5, to be released in Oct 2022.
Update 2022-10-19: Java 17.0.5 has been released with the fix to the bug that caused this issue.
When exec make-boot-jar.sh I get the following error:
2017-06-17 02:12:42,209 INFO - Successfully loaded base configuration from file at '/home/hadoop/terracotta-3.7.7/tc-config.xml'.
java.lang.ArrayIndexOutOfBoundsException: 9216
at com.tc.asm.ClassReader.readClass(ClassReader.java:2015)
at com.tc.asm.ClassReader.accept(ClassReader.java:469)
at com.tc.asm.ClassReader.accept(ClassReader.java:425)
Has anyone ever been in this situation?
Given the magic Terracotta was weaving inside a JVM and the fact that DSO is discontinued, I am pretty sure the error is because Terracotta 3.7.7 is not compatible with Java 8.
I've got a Tomcat webapp where I'm using AspectJ for logging and metrics, everything seems fine, but it keep creating several files like ajcore.20150310.113255.780.txt in the root folder. There is no exception in this files, so they are completely useless.
I've found this: https://eclipse.org/aspectj/doc/released/pdguide/ajcore.html
That states that using org.aspectj.weaver.Dump.exception="false" should disable this behavior, yet the files are still appearing. Is there any other way to completely disable the creation of this files? The other option mentioned: org.aspectj.dump.directory would also solve the problem, but it doesn't seem to work either.
This is the content of the file in case it helps for anything:
---- AspectJ Properties ---
AspectJ Compiler 1.7.1 built on Thursday Sep 6, 2012 at 16:39:22 GMT
---- Dump Properties ---
Dump file: ajcore.20150310.113255.780.txt
Dump reason: org.aspectj.weaver.BCException
Dump on exception: true
Dump at exit condition: abort
---- Exception Information ---
---- System Properties ---
... My system properties here
---- Command Line --- Empty
---- Full Classpath --- Empty
---- Compiler Messages --- Empty
Either of the following options may help:
Executing this code before any AspectJ weaving occurs (if possible): org.aspectj.weaver.Dump.setDumpOnExit(org.aspectj.bridge.IMessage.ABORT)
Adding this system property definition to your java command-line: -Dorg.aspectj.weaver.Dump.condition=abort
I think it is good that the AJ core dump happens because something seems to go wrong during LTW compilation:
Dump file: ajcore.20150310.113255.780.txt
Dump reason: org.aspectj.weaver.BCException
So there is an exception and you should investigate and fix it. Maybe some of your classes are woven with the logging code correctly and some are not. Run the weaver in verbose mode and check your console output, maybe you see something strange there. An AJ core file means that the weaver/compiler was shut down completely (abnormal termination).
As for the actual problem, I think that this
---- Command Line --- Empty
looks strange, as if no command line parameters were passed to the weaver. Also that no exception is actually logged is really unusual.
Which Java version are you on? I assume Java 7 because 1.6 is really old and Java 8 needs AspectJ 1.8. Anyway, can you try to use the latest AspectJ version 1.8.5 or at least the latest 1.7.4 from the old release and see if the problem still occurs?
Add this argument to your JVM run: -Dorg.aspectj.weaver.Dump.exception=false
And also see official docs
I was trying to upgrade my cassandra 1.2.13 to cassandra 2.0.5 but I was having some issues. I was follwing the instructions here:
https://github.com/apache/cassandra/blob/trunk/NEWS.txt
it says:
2.0.5
=====
...
Upgrading
---------
- If your cluster began on a version before 1.2, check that your secondary
index SSTables are on version 'ic' before upgrading. If not, run
'nodetool upgradesstables' if on 1.2.14 or later, or run 'nodetool
upgradesstables ks cf' with the keyspace and secondary index named
explicitly otherwise...
So since I have not initialized anything (any tables/kspaces and stuff) that matters I did:
nodetool upgradesstables
However when I do that command the following error is thrown at me:
objc[88756]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/java and /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
I tried googling that error but was still unsure how to proceed. Does someone know how to fix this without screwing up java environment?
I have a MAC OS X 10.9.1
it's a bug in JDK 1.7.0_45. you must upgrade your jdk.
see also Class JavaLaunchHelper is implemented in both. One of the two will be used. Which one is undefined
I want to do something with the HypergraphDB in Java. I'm not very familiar with this language and IDE Netbeans.
I followed steps describing the HGDB installation:Link to tutorial
Now I want to write an example in Java (using NetbeansIDE).
So I created new project, added refferences to the downloaded libraries. OK, now I'm able to import packages with HGDB. The only thing I have in my main method is HyperGraph HG = new HyperGraph(dbLocation);. This code compiles. But get following runtime error:
run:
checkpoint kbytes:0
checkpoint minutes:0
java.lang.IllegalStateException: There is 1 existing transaction opened against the Environment.
Aborting open transactions ...
aborting <Transaction id="28">
at com.sleepycat.je.Environment.close(Environment.java:383)
at org.hypergraphdb.storage.bje.BJEStorageImplementation.shutdown(BJEStorageImplementation.java:178)
at org.hypergraphdb.HGStore.close(HGStore.java:355)
at org.hypergraphdb.HyperGraph.open(HyperGraph.java:392)
at org.hypergraphdb.HyperGraph.open(HyperGraph.java:213)
at org.hypergraphdb.HyperGraph.<init>(HyperGraph.java:200)
at hgdbtest.HgdbTest.main(HgdbTest.java:16)
Exception in thread "main" org.hypergraphdb.HGException: java.lang.NoSuchMethodError: org.hypergraphdb.storage.bje.LinkBinding.objectToEntry(Ljava/lang/Object;Lcom/sleepycat/je/DatabaseEntry;)V
at org.hypergraphdb.HyperGraph.open(HyperGraph.java:395)
at org.hypergraphdb.HyperGraph.open(HyperGraph.java:213)
at org.hypergraphdb.HyperGraph.<init>(HyperGraph.java:200)
at hgdbtest.HgdbTest.main(HgdbTest.java:16)
Caused by: java.lang.NoSuchMethodError: org.hypergraphdb.storage.bje.LinkBinding.objectToEntry(Ljava/lang/Object;Lcom/sleepycat/je/DatabaseEntry;)V
at org.hypergraphdb.storage.bje.BJEStorageImplementation.store(BJEStorageImplementation.java:234)
at org.hypergraphdb.HGStore.store(HGStore.java:119)
at org.hypergraphdb.HGTypeSystem.addPrimitiveTypeToStore(HGTypeSystem.java:185)
at org.hypergraphdb.HGTypeSystem.bootstrap(HGTypeSystem.java:234)
at org.hypergraphdb.HyperGraph.open(HyperGraph.java:355)
... 3 more
Java Result: 1
BUILD SUCCESSFUL (total time: 4 seconds)
I guess it's caused by the native API of the BerkeleyDB.
According to the tutorial, in project options I supply the -Djava.library.path=$HGDB_ROOT/lib/native/$PLATFORM argument on Run card as a VM Option. Instead of the system variables I use full-path to the libraries.
My OS in Windows7. I'm not sure about using slashes or backslashes or double-backslashes as a path-separator.?
So a simply question is: how have I to set up the IDE for using the HypergraphDB?
Thank you for advices!
Judging from the stack trace, you are using the latest version of HyperGraphDB. In that version, the native API is not used. Rather, it's Java only libraries. You have to include the BerkeleyDB Java Edition 5.0.34 jar in your runtime classpath. You can get it either from the Oracle http://www.oracle.com/technetwork/products/berkeleydb/downloads/index.html or from the HyperGraphDB Maven repository: http://hypergraphdb.org/maven/org/hypergraphdb/hgbdbje/1.2/hgbdbje-1.2.jar
I had the same issue. I fixed it (by accident) by fixing the order of the libraries on which you're HyperGraphDB application relies on. The library je-[version].jar has to be ABOVE (and hence to be referenced before) db-[version].jar