AbstractMethodError when creating Table using datasource instead of Source

[aartiPl]

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)

[regis1512]

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.

[regis1512]

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]

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]

the version 1.0.0 is already published, this will be fixed in the next version.

[aartiPl]

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]

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.