Open starksm64 opened 6 months ago
@arjantijms see if you know anything about this issue. I found a couple of references to it, but no solution. It is either a dialect configuration issue or some bug between Hibernate and Derby.
Hi, maybe it's an option to look at embedding an H2 database and use that for the tests. This is what the Security TCK does as well:
https://github.com/jakartaee/security/tree/master/tck/app-db
It can be done externally as well of course by defining the datasource in a GF specific way. It does depend on the TCK having the option to specify a data source for use by persistence.xml.
runner-web/src/test/java/org/hibernate/data/tck/ext/JPAProcessor.java seems to have the right dialect for Derby:
"org.hibernate.dialect.DerbyDialect"
If we are only running initially on Java 21, perhaps try updating runner-web/pom.xml to use the 10.17.1.0 version of Derby instead of 10.16.1.1. That probably will not help based on the error message but mentioning anyway.
If we could run on Java 17, that might be a better thing to try first as Derby 10.16.1.1
should work on Java 17.
I wonder if it could help to update https://github.com/jakartaredhat/hibernate-data-tck-gf/blob/master/runner-web/pom.xml#L35 to reference
I was not able to embed the h2 db because in an EE environment Hibernate is configured vi the JPA SPI and expects a JCA pool resource. With the latest changes to configure an h2 based connection pool, all tests are passing:
starksm@Scotts-Mac-Studio runner-web % mvn -Pstaging test
...
[INFO] Results:
[INFO]
[INFO] Tests run: 99, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 24.948 s
[INFO] Finished at: 2024-06-03T17:29:32-06:00
[INFO] ------------------------------------------------------------------------
I was not able to embed the h2 db because in an EE environment Hibernate is configured vi the JPA SPI and expects a JCA pool resource.
Although it's not necessary anymore now, potentially it may have worked by creating a data source using @DataSourceDefinition
?
The repo is setup to run the Jakarta Data TCK using Hibernate 6.6.0.Alpha1 and the GlassFish web-7.0.14.zip dist. It passes most tests, but there seems to be some Hibernate/Derby issue that is causing column index out of range failures: