Seems hsqldb is the one, have to admit I was expecting derby to be easier but seems their runtime reflection and bytecode generation makes it actually a bad candidate for now. Anyway happy to not have to use another docker container to test openjpa :).
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 19 mars 2021 à 21:09, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > Hsqldb works well with jpa - it is tomee default ;) - and probably last > one to try. > I still hope to be able to pregenerate derby code at some point but will > follow that advice short term - until you want to give it a try ;). > > Le ven. 19 mars 2021 à 20:27, Raymond Augé <raymond.a...@liferay.com> a > écrit : > >> What about hypersonic? No reason it shouldn't work with jpa but not sure >> about native image. >> >> On Fri, Mar 19, 2021 at 12:33 PM Romain Manni-Bucau < >> rmannibu...@gmail.com> wrote: >> >>> Quick follow up: derby has some runtime code generation+loading (see my >>> last comment on https://issues.apache.org/jira/browse/DERBY-7108) so it >>> can not be the simplest solution to get openjpa knight. What about a fake >>> driver to validate openjpa and see if we can come with a java 8 (seems >>> their last release is j9 :s) solution with derby? Worse case we can move to >>> a remote connection for the DB and reuse test containers we already have in >>> the project. >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> >>> >>> Le jeu. 18 mars 2021 à 16:51, Romain Manni-Bucau <rmannibu...@gmail.com> >>> a écrit : >>> >>>> Hi all, >>>> >>>> Just to let you know, I just pushed an "openjpa" branch on arthur >>>> repository. >>>> It contains two new modules/knights: openjpa and derby. >>>> Goal is to be able to use openjpa in a native app easily (it is already >>>> doable with a lot of conf). >>>> >>>> integration-test/src/test/resources/integration-tests/openjpa >>>> <https://github.com/apache/geronimo-arthur/tree/openjpa/integration-test/src/test/resources/integration-tests/openjpa> >>>> provides >>>> the test I'm trying to run. >>>> It is not yet a setup which can be merged but current setup enables to >>>> run the test from this folder using "mvn clean package -Parthur >>>> arthur:native-image@runtime && ./target/openjpa.graal.bin >>>> -Dorg.slf4j.simpleLogger.defaultLogLevel=INFO" command. It means that >>>> if you modify derby/openjpa knight, you recompile the knight (mvn install) >>>> and can rerun this command from the test folder directly to see if it >>>> changes something/works - it is faster than recompiling everything or going >>>> through docker test layer. >>>> >>>> It seems that openjpa EMF started and fails when sending DDL to derby >>>> due to a threadlocal issue: >>>> >>>> Exception in thread "main" <openjpa-0.0.0-rnull nonfatal general error> >>>> org.apache.openjpa.persistence.PersistenceException: XJ001.U : [0] >>>> org.apache.derby.shared.common.sanity.AssertFailure, [1] ASSERT FAILED >>>> lcc=org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext@24a77e1e >>>> getContextOrNull=null >>>> at org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:625) >>>> at org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:489) >>>> at >>>> org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings(JDBCBrokerFactory.java:177) >>>> at >>>> org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings(JDBCBrokerFactory.java:182) >>>> at >>>> org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl(JDBCBrokerFactory.java:138) >>>> at >>>> org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:213) >>>> at >>>> org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:166) >>>> at >>>> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:262) >>>> at >>>> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:177) >>>> at >>>> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:167) >>>> at >>>> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:64) >>>> at >>>> org.apache.geronimo.arthur.integrationtests.OpenJPAMain.main(OpenJPAMain.java:77) >>>> Caused by: java.sql.SQLException: XJ001.U : [0] >>>> org.apache.derby.shared.common.sanity.AssertFailure, [1] ASSERT FAILED >>>> lcc=org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext@24a77e1e >>>> getContextOrNull=null >>>> at >>>> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:115) >>>> at >>>> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:141) >>>> at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:252) >>>> at org.apache.derby.impl.jdbc.Util.javaException(Util.java:274) >>>> at >>>> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:437) >>>> at >>>> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353) >>>> at >>>> org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2405) >>>> at >>>> org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:88) >>>> at >>>> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQueryUsingSystemTables(EmbedDatabaseMetaData.java:3642) >>>> at >>>> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQuery(EmbedDatabaseMetaData.java:3686) >>>> at >>>> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQuery(EmbedDatabaseMetaData.java:3713) >>>> at >>>> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.doGetCols(EmbedDatabaseMetaData.java:1969) >>>> at >>>> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getColumns(EmbedDatabaseMetaData.java:1941) >>>> at >>>> org.apache.commons.dbcp2.DelegatingDatabaseMetaData.getColumns(DelegatingDatabaseMetaData.java:227) >>>> at >>>> org.apache.commons.dbcp2.DelegatingDatabaseMetaData.getColumns(DelegatingDatabaseMetaData.java:227) >>>> at >>>> org.apache.openjpa.lib.jdbc.DelegatingDatabaseMetaData.getColumns(DelegatingDatabaseMetaData.java:137) >>>> at >>>> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingDatabaseMetaData.getColumns(LoggingConnectionDecorator.java:737) >>>> at >>>> org.apache.openjpa.lib.jdbc.DelegatingDatabaseMetaData.getColumns(DelegatingDatabaseMetaData.java:137) >>>> at >>>> org.apache.openjpa.jdbc.sql.DBDictionary.getColumns(DBDictionary.java:4428) >>>> at >>>> org.apache.openjpa.jdbc.schema.SchemaGenerator.generateTables(SchemaGenerator.java:532) >>>> at >>>> org.apache.openjpa.jdbc.schema.SchemaGenerator.generateSchema(SchemaGenerator.java:368) >>>> at >>>> org.apache.openjpa.jdbc.schema.SchemaGenerator.generateSchemas(SchemaGenerator.java:303) >>>> at >>>> org.apache.openjpa.jdbc.schema.SchemaTool.getDBSchemaGroup(SchemaTool.java:1314) >>>> at org.apache.openjpa.jdbc.schema.SchemaTool.drop(SchemaTool.java:410) >>>> at org.apache.openjpa.jdbc.schema.SchemaTool.run(SchemaTool.java:375) >>>> at org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:571) >>>> ... 11 more >>>> Caused by: ERROR XJ001: XJ001.U : [0] >>>> org.apache.derby.shared.common.sanity.AssertFailure, [1] ASSERT FAILED >>>> lcc=org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext@24a77e1e >>>> getContextOrNull=null >>>> at >>>> org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory.java:170) >>>> at >>>> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:75) >>>> ... 36 more >>>> Caused by: org.apache.derby.shared.common.sanity.AssertFailure: ASSERT >>>> FAILED >>>> lcc=org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext@24a77e1e >>>> getContextOrNull=null >>>> at >>>> org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) >>>> at >>>> org.apache.derby.iapi.util.InterruptStatus.restoreIntrFlagIfSeen(InterruptStatus.java:245) >>>> at >>>> org.apache.derby.impl.jdbc.EmbedConnection.prepareMetaDataStatement(EmbedConnection.java:2889) >>>> at >>>> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.prepareSPS(EmbedDatabaseMetaData.java:3803) >>>> at >>>> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQueryUsingSystemTables(EmbedDatabaseMetaData.java:3635) >>>> ... 28 more >>>> >>>> >>>> The not debug mode looks more raw - yeah, jdbc driver still publish not >>>> debuggable jars but derby is easy to build from sources and then you can >>>> set it as systemPath in the pom to debug: >>>> >>>> Caused by: ERROR XJ001: XJ001.U : [0] java.lang.NullPointerException, >>>> [1] >>>> at >>>> org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(Unknown >>>> Source) >>>> ... 42 more >>>> Caused by: java.lang.NullPointerException >>>> at org.apache.derby.impl.sql.compile.CastNode.bindCastNodeOnly(Unknown >>>> Source) >>>> at org.apache.derby.impl.sql.compile.CastNode.bindExpression(Unknown >>>> Source) >>>> at >>>> org.apache.derby.impl.sql.compile.ResultColumn.bindExpression(Unknown >>>> Source) >>>> at >>>> org.apache.derby.impl.sql.compile.ResultColumnList.bindExpressions(Unknown >>>> Source) >>>> at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(Unknown >>>> Source) >>>> at >>>> org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(Unknown >>>> Source) >>>> at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(Unknown >>>> Source) >>>> at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(Unknown >>>> Source) >>>> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) >>>> at org.apache.derby.impl.sql.GenericStatement.prepareStorable(Unknown >>>> Source) >>>> at >>>> org.apache.derby.iapi.sql.dictionary.SPSDescriptor.compileStatement(Unknown >>>> Source) >>>> at >>>> org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(Unknown >>>> Source) >>>> at >>>> org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(Unknown >>>> Source) >>>> at >>>> org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(Unknown >>>> Source) >>>> at org.apache.derby.impl.sql.compile.ExecSPSNode.generate(Unknown >>>> Source) >>>> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) >>>> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) >>>> at >>>> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown >>>> Source) >>>> ... 34 more >>>> >>>> Overall it is mainly about making derby graalifyable I think. >>>> I need to switch to another topic for a moment so if anyone wants to >>>> continue the experimentations just jump in. >>>> >>>> The small side notes I can gives are: >>>> >>>> 1. we can do a dbcp2-knight and a commons-logging-knight (for now they >>>> are in openjpa one - it is commented as such), these ones should be easy >>>> since already coded, just not packaged properly >>>> 2. the immediate fix for deby will likely sit either >>>> in org.apache.geronimo.arthur.knight.derby.DerbyExtension or a substitution >>>> in the same module >>>> 3. if easier we can use another database (h2 does not work and will >>>> likely not work in embedded mode so hsqldb can be saner - at least I don't >>>> know for this one) >>>> >>>> If you are motivated to proove openjpa runs in native mode and finish >>>> this branch, don't hesitate to answer this thread, I'd also be happy to >>>> discuss more on slack or by mail details if it helps. >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>> <http://rmannibucau.wordpress.com> | Github >>>> <https://github.com/rmannibucau> | LinkedIn >>>> <https://www.linkedin.com/in/rmannibucau> | Book >>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>>> >>> >> >> -- >> *Raymond Augé* (@rotty3000) >> Senior Software Architect *Liferay, Inc.* (@Liferay) >> OSGi Fellow >> >
