Repository navigation
AbstractMethodError when creating Table using datasource instead of Source #13
Description
I get AbstractMethodError when I use Datasource in Table instead of Source:
HikariConfig poolConfig = new HikariConfig();
poolConfig.setJdbcUrl("jdbc:h2:mem:test");
poolConfig.setUsername("user");
poolConfig.setPassword("password");
poolConfig.setMaximumPoolSize(3);
poolConfig.setMinimumIdle(1);
ds = new HikariDataSource(poolConfig);
taskDao = new TaskDao(new Sql2o(ds), new TaskResultSetHandler());
table = new Table(ds, "tasks");
//source = new Source("jdbc:h2:mem:test", "user", "password");
//table = new Table(source, "tasks");
Exception:
java.lang.AbstractMethodError: org.h2.jdbc.JdbcConnection.getSchema()Ljava/lang/String;
at com.zaxxer.hikari.proxy.ConnectionJavassistProxy.getSchema(ConnectionJavassistProxy.java)
at org.assertj.db.type.AbstractDbElement.getSchema(AbstractDbElement.java:187)
at org.assertj.db.type.Table.collectPrimaryKeyName(Table.java:316)
at org.assertj.db.type.Table.loadImpl(Table.java:348)
at org.assertj.db.type.AbstractDbData.load(AbstractDbData.java:128)
at org.assertj.db.type.AbstractDbData.getRowsList(AbstractDbData.java:286)
at org.assertj.db.api.AbstractDbAssert.hasNumberOfRows(AbstractDbAssert.java:229)
at .......TaskDaoTest.testCreateTasksTable(TaskDaoTest.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:78)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Activity
regis1512 commentedon Jul 12, 2015
Hello,
I succeeded to reproduce the problem.
It is when we use the constructor with a DataSource and not with a Source.
It is because ConnectionJavassistProxy#getSchema() is a proxy.
In AbstractDbElement#getSchema(Connection) method, the getSchema() method is checked to verify if it is abstract (because of the proxy it is the proxy method which is verified).
The proxy method is not abstract but the method in H2 is abstract. So there is the error.
I will see how to avoid this problem.
It will be is a next release.
Thanks.
Fix the Issue #13 (#13)
regis1512 commentedon Jul 12, 2015
I tried to fix it (i just commit the fix). But because i am in holidays with a old/small portable computer i can not well test that.
Please let me know if it is better.
aartiPl commentedon Jul 13, 2015
Hi, can you please publish 1.0 artifact with your fix? I have added dependency on version 1.0 and it behaves the same as before...
joel-costigliola commentedon Jul 13, 2015
the version 1.0.0 is already published, this will be fixed in the next version.
aartiPl commentedon Jul 13, 2015
Right. I have tested code from repo and it works correctly right now. It will be great if the next (minor) release happens soon... Thanks!
regis1512 commentedon Aug 10, 2015
The version 1.0.1 is released since 09-Aug-2015 (http://search.maven.org/#artifactdetails|org.assertj|assertj-db|1.0.1|bundle)
I close the issue.