[jira] [Comment Edited] (OPENJPA-2919) Connection pool can be exhausted when connections are killed on the DB side
[
https://issues.apache.org/jira/browse/OPENJPA-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820042#comment-17820042
]
Romain Manni-Bucau edited comment on OPENJPA-2919 at 2/23/24 12:26 PM:
---
I don't use dbcp since some years but using tomcat-dbcp the keys are 1. enforce
a global default query/statement timeout (validation + runtime) + 2. ensure
validation runs often enough for your infra (can be from every 10mn to every
30s depending the perfs and instability).
was (Author: romain.manni-bucau):
I don't use dbcp since some years but using tomcat-dbcp the keys are 1. enforce
a global default query/statement timeout (validation + runtime) + ensure
validation runs often enough for your infra (can be from every 10mn to every
30s depending the perfs and instability).
> Connection pool can be exhausted when connections are killed on the DB side
> ---
>
> Key: OPENJPA-2919
> URL: https://issues.apache.org/jira/browse/OPENJPA-2919
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.2.2
>Reporter: Dénes Bodó
>Priority: Critical
> Labels: deadlock, robustness
> Attachments: Screenshot 2024-02-23 at 09.02.19.png
>
>
> Apache Oozie 5.2.1 uses OpenJPA 2.4.2 and commons-dbcp 1.4 and commons-pool
> 1.5.4. These are ancient versions, I know.
> h1. Description
> The issue is that when due to some network issues or "maintenance work" on
> the DB side (especially PostgreSQL) which causes the DB connection to be
> closed, it results exhausted Pool on the client side. Many threads are
> waiting at this point:
> {noformat}
> "pool-2-thread-4" #20 prio=5 os_prio=31 tid=0x7faf7903b800 nid=0x8603
> waiting on condition [0x00030f3e7000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00066aca8e70> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:1324)
> {noformat}
> According to my observation this is because the JDBC driver does not get
> closed on the client side, nor the abstract DBCP connection
> _org.apache.commons.dbcp2.PoolableConnection_ .
> h1. Repro
> (Un)Fortunately I can reproduce the issue using the latest and greatest
> commons-dbcp 2.11.0 and commons-pool 2.12.0 along with OpenJPA 3.2.2.
> I've just created a Java application to reproduce the issue:
> [https://github.com/dionusos/pool_exhausted_repro] . See README.md for
> detailed repro steps.
> h1. What we tried so far
> I got in touch with DBCP team who confirmed that in case of an error in the
> connection the client (in this case OpenJPA is the client of DBCP) should
> handle the exception like closing the connection: DBCP-595. I agree with them
> as based on the investigation I did I can also confirm that DBCP is really
> robust when the client releases the broken connection object after catching
> SQLException. Please check the 4 comments on DBCP-595 for extra details.
> h1. Ask
> OpenJPA team!
> * Could you please confirm that my findings are valid?
> * Did I do anything wrong in my repro program?
> * Oozie has retry logic implemented:
> [https://github.com/apache/oozie/blob/318fac5/core/src/main/java/org/apache/oozie/service/JPAService.java#L397L427]
> but this cannot avoid the reported dead lock.
> * Do you have any questions I can answer to help in the investigation?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OPENJPA-2919) Connection pool can be exhausted when connections are killed on the DB side
[
https://issues.apache.org/jira/browse/OPENJPA-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820042#comment-17820042
]
Romain Manni-Bucau commented on OPENJPA-2919:
-
I don't use dbcp since some years but using tomcat-dbcp the keys are 1. enforce
a global default query/statement timeout (validation + runtime) + ensure
validation runs often enough for your infra (can be from every 10mn to every
30s depending the perfs and instability).
> Connection pool can be exhausted when connections are killed on the DB side
> ---
>
> Key: OPENJPA-2919
> URL: https://issues.apache.org/jira/browse/OPENJPA-2919
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.2.2
>Reporter: Dénes Bodó
>Priority: Critical
> Labels: deadlock, robustness
> Attachments: Screenshot 2024-02-23 at 09.02.19.png
>
>
> Apache Oozie 5.2.1 uses OpenJPA 2.4.2 and commons-dbcp 1.4 and commons-pool
> 1.5.4. These are ancient versions, I know.
> h1. Description
> The issue is that when due to some network issues or "maintenance work" on
> the DB side (especially PostgreSQL) which causes the DB connection to be
> closed, it results exhausted Pool on the client side. Many threads are
> waiting at this point:
> {noformat}
> "pool-2-thread-4" #20 prio=5 os_prio=31 tid=0x7faf7903b800 nid=0x8603
> waiting on condition [0x00030f3e7000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00066aca8e70> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:1324)
> {noformat}
> According to my observation this is because the JDBC driver does not get
> closed on the client side, nor the abstract DBCP connection
> _org.apache.commons.dbcp2.PoolableConnection_ .
> h1. Repro
> (Un)Fortunately I can reproduce the issue using the latest and greatest
> commons-dbcp 2.11.0 and commons-pool 2.12.0 along with OpenJPA 3.2.2.
> I've just created a Java application to reproduce the issue:
> [https://github.com/dionusos/pool_exhausted_repro] . See README.md for
> detailed repro steps.
> h1. What we tried so far
> I got in touch with DBCP team who confirmed that in case of an error in the
> connection the client (in this case OpenJPA is the client of DBCP) should
> handle the exception like closing the connection: DBCP-595. I agree with them
> as based on the investigation I did I can also confirm that DBCP is really
> robust when the client releases the broken connection object after catching
> SQLException. Please check the 4 comments on DBCP-595 for extra details.
> h1. Ask
> OpenJPA team!
> * Could you please confirm that my findings are valid?
> * Did I do anything wrong in my repro program?
> * Oozie has retry logic implemented:
> [https://github.com/apache/oozie/blob/318fac5/core/src/main/java/org/apache/oozie/service/JPAService.java#L397L427]
> but this cannot avoid the reported dead lock.
> * Do you have any questions I can answer to help in the investigation?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OPENJPA-2919) Connection pool can be exhausted when connections are killed on the DB side
[
https://issues.apache.org/jira/browse/OPENJPA-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819534#comment-17819534
]
Romain Manni-Bucau commented on OPENJPA-2919:
-
Hi [~dionusos] , seems the pool is not configured, ensure to have some test
and a proper validation query - or use tomcat-jdbc instead of dbcp which
supports JDBC isValid() - plus a query timeout for the validation test. This
will guarantee the connections are dropped properly if your driver is not able
to detect it.
But long story short this is unrelated to JPA, just a misconfiguration of the
connections.
> Connection pool can be exhausted when connections are killed on the DB side
> ---
>
> Key: OPENJPA-2919
> URL: https://issues.apache.org/jira/browse/OPENJPA-2919
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.2.2
>Reporter: Dénes Bodó
>Priority: Critical
> Labels: deadlock, robustness
>
> Apache Oozie 5.2.1 uses OpenJPA 2.4.2 and commons-dbcp 1.4 and commons-pool
> 1.5.4. These are ancient versions, I know.
> h1. Description
> The issue is that when due to some network issues or "maintenance work" on
> the DB side (especially PostgreSQL) which causes the DB connection to be
> closed, it results exhausted Pool on the client side. Many threads are
> waiting at this point:
> {noformat}
> "pool-2-thread-4" #20 prio=5 os_prio=31 tid=0x7faf7903b800 nid=0x8603
> waiting on condition [0x00030f3e7000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00066aca8e70> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:1324)
> {noformat}
> According to my observation this is because the JDBC driver does not get
> closed on the client side, nor the abstract DBCP connection
> _org.apache.commons.dbcp2.PoolableConnection_ .
> h1. Repro
> (Un)Fortunately I can reproduce the issue using the latest and greatest
> commons-dbcp 2.11.0 and commons-pool 2.12.0 along with OpenJPA 3.2.2.
> I've just created a Java application to reproduce the issue:
> [https://github.com/dionusos/pool_exhausted_repro] . See README.md for
> detailed repro steps.
> h1. What we tried so far
> I got in touch with DBCP team who confirmed that in case of an error in the
> connection the client (in this case OpenJPA is the client of DBCP) should
> handle the exception like closing the connection: DBCP-595. I agree with them
> as based on the investigation I did I can also confirm that DBCP is really
> robust when the client releases the broken connection object after catching
> SQLException. Please check the 4 comments on DBCP-595 for extra details.
> h1. Ask
> OpenJPA team!
> * Could you please confirm that my findings are valid?
> * Did I do anything wrong in my repro program?
> * Oozie has retry logic implemented:
> [https://github.com/apache/oozie/blob/318fac5/core/src/main/java/org/apache/oozie/service/JPAService.java#L397L427]
> but this cannot avoid the reported dead lock.
> * Do you have any questions I can answer to help in the investigation?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OPENJPA-2898) Cannot resolve the name 'orm:versionType'
[
https://issues.apache.org/jira/browse/OPENJPA-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816699#comment-17816699
]
Romain Manni-Bucau commented on OPENJPA-2898:
-
looks good to me, just misses a test.
side note: you can do a PR, can be easier to review
> Cannot resolve the name 'orm:versionType'
> -
>
> Key: OPENJPA-2898
> URL: https://issues.apache.org/jira/browse/OPENJPA-2898
> Project: OpenJPA
> Issue Type: Bug
> Components: Enhance
>Affects Versions: 3.2.1, 3.2.2
>Reporter: Patrice DUROUX
>Priority: Major
> Attachments: openjpa.patch
>
>
> Hi,
> Switching from 3.2.0 to 3.2.1 to not face anymore issue OPENJPA-2881 and
> without any change in the source code, I am getting the following one:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.openjpa:openjpa-maven-plugin:3.2.1:enhance (enhancer) on project
> IMGTPersistence: Execution enhancer of goal
> org.apache.openjpa:openjpa-maven-plugin:3.2.1:enhance failed:
> org.xml.sax.SAXException:
> file:/home/patrice/workspace-imgt/imgt/api/IMGTPersistence/target/classes/META-INF/taxonomy_orm.xml
> [Location:Line: 6, C: 16]: org.xml.sax.SAXParseException; lineNumber: 73;
> columnNumber: 46; src-resolve: Cannot resolve the name 'orm:versionType' to
> a(n) 'type definition' component. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.openjpa:openjpa-maven-plugin:3.2.1:enhance (enhancer) on
> project IMGTPersistence: Execution enhancer of goal
> org.apache.openjpa:openjpa-maven-plugin:3.2.1:enhance failed:
> org.xml.sax.SAXException:
> file:/home/patrice/workspace-imgt/imgt/api/IMGTPersistence/target/classes/META-INF/taxonomy_orm.xml
> [Location:Line: 6, C: 16]: org.xml.sax.SAXParseException; lineNumber: 73;
> columnNumber: 46; src-resolve: Cannot resolve the name 'orm:versionType' to
> a(n) 'type definition' component.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> enhancer of goal org.apache.openjpa:openjpa-maven-plugin:3.2.1:enhance
> failed: org.xml.sax.SAXException:
> file:/home/patrice/workspace-imgt/imgt/api/IMGTPersistence/target/classes/META-INF/taxonomy_orm.xml
> [Location:Line: 6, C: 16]: org.xml.sax.SAXParseException; lineNumber: 73;
> columnNumber: 46; src-resolve: Cannot resolve the name 'orm:versionType' to
> a(n) 'type definition' component.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
>
[jira] [Commented] (OPENJPA-2918) Support for Java 21
[
https://issues.apache.org/jira/browse/OPENJPA-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792149#comment-17792149
]
Romain Manni-Bucau commented on OPENJPA-2918:
-
It is xbean-asm-shaded whuch must be upgraded, can be done in consumer poms.
> Support for Java 21
> ---
>
> Key: OPENJPA-2918
> URL: https://issues.apache.org/jira/browse/OPENJPA-2918
> Project: OpenJPA
> Issue Type: Bug
>Reporter: Benoit Tellier
>Priority: Major
>
> While trying to add Java 21 support in Apache James, the OpenJPA maven plugin
> (version 3.2.2) throw the following exception:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.openjpa:openjpa-maven-plugin:3.2.2:enhance (enhancer) on project
> james-server-data-jpa: Execution enhancer of goal
> org.apache.openjpa:openjpa-maven-plugin:3.2.2:enhance failed: Unsupported
> class file major version 65 -> [Help 1]
> {code}
> Maybe this could be as easy as updating the maven-plugin-plugin version?
> Updating it aggressively solved a similar issue wit Apache James mailet
> documentation maven plugin...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OPENJPA-2903) compatibility with MariaDB Java Client 3.0.6
[
https://issues.apache.org/jira/browse/OPENJPA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570885#comment-17570885
]
Romain Manni-Bucau commented on OPENJPA-2903:
-
[~pduroux] XML is equivalent to plain java (type and annotation are still
defined) so check should still be validated before going further. Can you share
a sample project with just openjpa+jpa api as dependency reproducing it on a
docker mariadb maybe?
> compatibility with MariaDB Java Client 3.0.6
>
>
> Key: OPENJPA-2903
> URL: https://issues.apache.org/jira/browse/OPENJPA-2903
> Project: OpenJPA
> Issue Type: Wish
>Affects Versions: 3.2.0
> Environment: Operating System: Ubuntu
> JRE: OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu1)
>Reporter: Patrice DUROUX
>Priority: Trivial
>
> Hi,
> Here is what I got at runtime upgrading the MariaDB Java Client from 2.7.6 to
> 3.0.6:
>
> {noformat}
>
> org.apache.openjpa.persistence.ArgumentException: There was an error packing
> the projection and/or aggregate results of the query into result type "class
> org.imgt.model.genedb2.CustomBeanLIGMDB". See the nested Throwable exception
> for details. FailedObject: SELECT sa.gene AS gene,sa.species AS
> species,sa.exon AS exon,sa.number AS alleleNumber,se.seqnuc AS
> fullSeq,fe2.feadeb AS posDeb,fe2.feafin AS posFin,sa.numacc AS
> numacc,fe2.phase AS phase,sa.taxon AS taxon,fe2.partial AS
> partiality,fe2.complement AS rc,sa.ordre AS exonorder FROM genedb.seqalleles
> sa,ligmdb_v12.sequences se,ligmdb_v12.features fe1,ligmdb_v12.features
> fe2,ontology.labels la1,ontology.labels la2 WHERE sa.is_ref=1 AND
> sa.numacc=se.numacc AND sa.numacc=fe1.numacc AND sa.feanum=fe1.feanum AND
> sa.labcode=fe1.labcode AND la1.label=sa.exon AND la1.labcode=la2.labcode AND
> la2.labcode=fe2.labcode AND sa.numacc=fe2.numacc AND fe1.feadeb<=fe2.feadeb
> AND fe2.feafin<=fe1.feafin AND sa.gene=? AND sa.species=? AND sa.numacc=? AND
> sa.exon=? [java.lang.String] at
> org.apache.openjpa.kernel.ResultPacker.packUserType(ResultPacker.java:299) at
> org.apache.openjpa.kernel.ResultPacker.pack(ResultPacker.java:262) at
> org.apache.openjpa.jdbc.kernel.SQLProjectionResultObjectProvider.getResultObject(SQLProjectionResultObjectProvider.java:98)
> at
> org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:38) at
> org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1314) at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:1061) at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:911) at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:842) at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:601)
> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:297) at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:314) at
> org.imgt.dao.GENEDBDAO.getLIGMDBentries(GENEDBDAO.java:590) at
> org.imgt.dao.GENEDBDAO.getLIGMDBentries(GENEDBDAO.java:616) at
> org.imgt.util.fasta.GeneFastaSeq2.getFastaSeq(GeneFastaSeq2.java:46) at
> org.imgt.toolbox.genedb.GenedbFlatFile.run(GenedbFlatFile.java:81) at
> org.imgt.tools.cmd.FFile.run(FFile.java:18) at
> picocli.CommandLine.executeUserObject(CommandLine.java:1939) at
> picocli.CommandLine.access$1300(CommandLine.java:145) at
> picocli.CommandLine$RunAll.recursivelyExecuteUserObject(CommandLine.java:2431)
> at
> picocli.CommandLine$RunAll.recursivelyExecuteUserObject(CommandLine.java:2433)
> at picocli.CommandLine$RunAll.handle(CommandLine.java:2428) at
> picocli.CommandLine$RunAll.handle(CommandLine.java:2389) at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
> at picocli.CommandLine$RunAll.execute(CommandLine.java:2391) at
> picocli.CommandLine.execute(CommandLine.java:2078) at
> org.imgt.tools.SeqTool.main(SeqTool.java:19) Caused by:
> java.lang.ClassCastException: Cannot convert object
> "org.mariadb.jdbc.MariaDbBlob@2178ae3b" of type "class
> org.mariadb.jdbc.MariaDbBlob" into an instance of "class [B". at
> org.apache.openjpa.kernel.Filters.convert(Filters.java:395) at
> org.apache.openjpa.kernel.Filters.convert(Filters.java:271) at
> org.apache.openjpa.kernel.ResultPacker.packUserType(ResultPacker.java:280)
> ... 25 more{noformat}
> Not sure on which side (OpenJPA? MariaDB Java Client?) the problem belongs to.
> Regards,
> Patrice
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OPENJPA-2903) compatibility with MariaDB Java Client 3.0.6
[
https://issues.apache.org/jira/browse/OPENJPA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau reassigned OPENJPA-2903:
---
Assignee: (was: Romain Manni-Bucau)
> compatibility with MariaDB Java Client 3.0.6
>
>
> Key: OPENJPA-2903
> URL: https://issues.apache.org/jira/browse/OPENJPA-2903
> Project: OpenJPA
> Issue Type: Wish
>Affects Versions: 3.2.0
> Environment: Operating System: Ubuntu
> JRE: OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu1)
>Reporter: Patrice DUROUX
>Priority: Trivial
>
> Hi,
> Here is what I got at runtime upgrading the MariaDB Java Client from 2.7.6 to
> 3.0.6:
>
> {noformat}
>
> org.apache.openjpa.persistence.ArgumentException: There was an error packing
> the projection and/or aggregate results of the query into result type "class
> org.imgt.model.genedb2.CustomBeanLIGMDB". See the nested Throwable exception
> for details. FailedObject: SELECT sa.gene AS gene,sa.species AS
> species,sa.exon AS exon,sa.number AS alleleNumber,se.seqnuc AS
> fullSeq,fe2.feadeb AS posDeb,fe2.feafin AS posFin,sa.numacc AS
> numacc,fe2.phase AS phase,sa.taxon AS taxon,fe2.partial AS
> partiality,fe2.complement AS rc,sa.ordre AS exonorder FROM genedb.seqalleles
> sa,ligmdb_v12.sequences se,ligmdb_v12.features fe1,ligmdb_v12.features
> fe2,ontology.labels la1,ontology.labels la2 WHERE sa.is_ref=1 AND
> sa.numacc=se.numacc AND sa.numacc=fe1.numacc AND sa.feanum=fe1.feanum AND
> sa.labcode=fe1.labcode AND la1.label=sa.exon AND la1.labcode=la2.labcode AND
> la2.labcode=fe2.labcode AND sa.numacc=fe2.numacc AND fe1.feadeb<=fe2.feadeb
> AND fe2.feafin<=fe1.feafin AND sa.gene=? AND sa.species=? AND sa.numacc=? AND
> sa.exon=? [java.lang.String] at
> org.apache.openjpa.kernel.ResultPacker.packUserType(ResultPacker.java:299) at
> org.apache.openjpa.kernel.ResultPacker.pack(ResultPacker.java:262) at
> org.apache.openjpa.jdbc.kernel.SQLProjectionResultObjectProvider.getResultObject(SQLProjectionResultObjectProvider.java:98)
> at
> org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:38) at
> org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1314) at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:1061) at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:911) at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:842) at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:601)
> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:297) at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:314) at
> org.imgt.dao.GENEDBDAO.getLIGMDBentries(GENEDBDAO.java:590) at
> org.imgt.dao.GENEDBDAO.getLIGMDBentries(GENEDBDAO.java:616) at
> org.imgt.util.fasta.GeneFastaSeq2.getFastaSeq(GeneFastaSeq2.java:46) at
> org.imgt.toolbox.genedb.GenedbFlatFile.run(GenedbFlatFile.java:81) at
> org.imgt.tools.cmd.FFile.run(FFile.java:18) at
> picocli.CommandLine.executeUserObject(CommandLine.java:1939) at
> picocli.CommandLine.access$1300(CommandLine.java:145) at
> picocli.CommandLine$RunAll.recursivelyExecuteUserObject(CommandLine.java:2431)
> at
> picocli.CommandLine$RunAll.recursivelyExecuteUserObject(CommandLine.java:2433)
> at picocli.CommandLine$RunAll.handle(CommandLine.java:2428) at
> picocli.CommandLine$RunAll.handle(CommandLine.java:2389) at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
> at picocli.CommandLine$RunAll.execute(CommandLine.java:2391) at
> picocli.CommandLine.execute(CommandLine.java:2078) at
> org.imgt.tools.SeqTool.main(SeqTool.java:19) Caused by:
> java.lang.ClassCastException: Cannot convert object
> "org.mariadb.jdbc.MariaDbBlob@2178ae3b" of type "class
> org.mariadb.jdbc.MariaDbBlob" into an instance of "class [B". at
> org.apache.openjpa.kernel.Filters.convert(Filters.java:395) at
> org.apache.openjpa.kernel.Filters.convert(Filters.java:271) at
> org.apache.openjpa.kernel.ResultPacker.packUserType(ResultPacker.java:280)
> ... 25 more{noformat}
> Not sure on which side (OpenJPA? MariaDB Java Client?) the problem belongs to.
> Regards,
> Patrice
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OPENJPA-2903) compatibility with MariaDB Java Client 3.0.6
[
https://issues.apache.org/jira/browse/OPENJPA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570873#comment-17570873
]
Romain Manni-Bucau commented on OPENJPA-2903:
-
Hi [~pduroux] ,
Can depend the mapping you did but if it is JPA compliant it means a
mariadbblob is returned instead of a byte array (in your class I assume, maybe
without @Lob).
Can need to use the dictionary to map the type properly in
[https://github.com/apache/openjpa/blob/c3da147fc922dcd56c3a62c951bebac0d870d8cd/openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ResultPacker.java#L268]
(or Filters#convert)
> compatibility with MariaDB Java Client 3.0.6
>
>
> Key: OPENJPA-2903
> URL: https://issues.apache.org/jira/browse/OPENJPA-2903
> Project: OpenJPA
> Issue Type: Wish
>Affects Versions: 3.2.0
> Environment: Operating System: Ubuntu
> JRE: OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu1)
>Reporter: Patrice DUROUX
>Assignee: Romain Manni-Bucau
>Priority: Trivial
>
> Hi,
> Here is what I got at runtime upgrading the MariaDB Java Client from 2.7.6 to
> 3.0.6:
>
> {noformat}
>
> org.apache.openjpa.persistence.ArgumentException: There was an error packing
> the projection and/or aggregate results of the query into result type "class
> org.imgt.model.genedb2.CustomBeanLIGMDB". See the nested Throwable exception
> for details. FailedObject: SELECT sa.gene AS gene,sa.species AS
> species,sa.exon AS exon,sa.number AS alleleNumber,se.seqnuc AS
> fullSeq,fe2.feadeb AS posDeb,fe2.feafin AS posFin,sa.numacc AS
> numacc,fe2.phase AS phase,sa.taxon AS taxon,fe2.partial AS
> partiality,fe2.complement AS rc,sa.ordre AS exonorder FROM genedb.seqalleles
> sa,ligmdb_v12.sequences se,ligmdb_v12.features fe1,ligmdb_v12.features
> fe2,ontology.labels la1,ontology.labels la2 WHERE sa.is_ref=1 AND
> sa.numacc=se.numacc AND sa.numacc=fe1.numacc AND sa.feanum=fe1.feanum AND
> sa.labcode=fe1.labcode AND la1.label=sa.exon AND la1.labcode=la2.labcode AND
> la2.labcode=fe2.labcode AND sa.numacc=fe2.numacc AND fe1.feadeb<=fe2.feadeb
> AND fe2.feafin<=fe1.feafin AND sa.gene=? AND sa.species=? AND sa.numacc=? AND
> sa.exon=? [java.lang.String] at
> org.apache.openjpa.kernel.ResultPacker.packUserType(ResultPacker.java:299) at
> org.apache.openjpa.kernel.ResultPacker.pack(ResultPacker.java:262) at
> org.apache.openjpa.jdbc.kernel.SQLProjectionResultObjectProvider.getResultObject(SQLProjectionResultObjectProvider.java:98)
> at
> org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:38) at
> org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1314) at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:1061) at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:911) at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:842) at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:601)
> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:297) at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:314) at
> org.imgt.dao.GENEDBDAO.getLIGMDBentries(GENEDBDAO.java:590) at
> org.imgt.dao.GENEDBDAO.getLIGMDBentries(GENEDBDAO.java:616) at
> org.imgt.util.fasta.GeneFastaSeq2.getFastaSeq(GeneFastaSeq2.java:46) at
> org.imgt.toolbox.genedb.GenedbFlatFile.run(GenedbFlatFile.java:81) at
> org.imgt.tools.cmd.FFile.run(FFile.java:18) at
> picocli.CommandLine.executeUserObject(CommandLine.java:1939) at
> picocli.CommandLine.access$1300(CommandLine.java:145) at
> picocli.CommandLine$RunAll.recursivelyExecuteUserObject(CommandLine.java:2431)
> at
> picocli.CommandLine$RunAll.recursivelyExecuteUserObject(CommandLine.java:2433)
> at picocli.CommandLine$RunAll.handle(CommandLine.java:2428) at
> picocli.CommandLine$RunAll.handle(CommandLine.java:2389) at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
> at picocli.CommandLine$RunAll.execute(CommandLine.java:2391) at
> picocli.CommandLine.execute(CommandLine.java:2078) at
> org.imgt.tools.SeqTool.main(SeqTool.java:19) Caused by:
> java.lang.ClassCastException: Cannot convert object
> "org.mariadb.jdbc.MariaDbBlob@2178ae3b" of type "class
> org.mariadb.jdbc.MariaDbBlob" into an instance of "class [B". at
> org.apache.openjpa.kernel.Filters.convert(Filters.java:395) at
> org.apache.openjpa.kernel.Filters.convert(Filters.java:271) at
> org.apache.openjpa.kernel.ResultPacker.packUserType(ResultPacker.java:280)
> ... 25 more{noformat}
> Not sure on which side (OpenJPA? MariaDB Java Client?) the problem belongs to.
> Regards,
> Patrice
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OPENJPA-2903) compatibility with MariaDB Java Client 3.0.6
[
https://issues.apache.org/jira/browse/OPENJPA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau reassigned OPENJPA-2903:
---
Assignee: Romain Manni-Bucau
> compatibility with MariaDB Java Client 3.0.6
>
>
> Key: OPENJPA-2903
> URL: https://issues.apache.org/jira/browse/OPENJPA-2903
> Project: OpenJPA
> Issue Type: Wish
>Affects Versions: 3.2.0
> Environment: Operating System: Ubuntu
> JRE: OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu1)
>Reporter: Patrice DUROUX
>Assignee: Romain Manni-Bucau
>Priority: Trivial
>
> Hi,
> Here is what I got at runtime upgrading the MariaDB Java Client from 2.7.6 to
> 3.0.6:
>
> {noformat}
>
> org.apache.openjpa.persistence.ArgumentException: There was an error packing
> the projection and/or aggregate results of the query into result type "class
> org.imgt.model.genedb2.CustomBeanLIGMDB". See the nested Throwable exception
> for details. FailedObject: SELECT sa.gene AS gene,sa.species AS
> species,sa.exon AS exon,sa.number AS alleleNumber,se.seqnuc AS
> fullSeq,fe2.feadeb AS posDeb,fe2.feafin AS posFin,sa.numacc AS
> numacc,fe2.phase AS phase,sa.taxon AS taxon,fe2.partial AS
> partiality,fe2.complement AS rc,sa.ordre AS exonorder FROM genedb.seqalleles
> sa,ligmdb_v12.sequences se,ligmdb_v12.features fe1,ligmdb_v12.features
> fe2,ontology.labels la1,ontology.labels la2 WHERE sa.is_ref=1 AND
> sa.numacc=se.numacc AND sa.numacc=fe1.numacc AND sa.feanum=fe1.feanum AND
> sa.labcode=fe1.labcode AND la1.label=sa.exon AND la1.labcode=la2.labcode AND
> la2.labcode=fe2.labcode AND sa.numacc=fe2.numacc AND fe1.feadeb<=fe2.feadeb
> AND fe2.feafin<=fe1.feafin AND sa.gene=? AND sa.species=? AND sa.numacc=? AND
> sa.exon=? [java.lang.String] at
> org.apache.openjpa.kernel.ResultPacker.packUserType(ResultPacker.java:299) at
> org.apache.openjpa.kernel.ResultPacker.pack(ResultPacker.java:262) at
> org.apache.openjpa.jdbc.kernel.SQLProjectionResultObjectProvider.getResultObject(SQLProjectionResultObjectProvider.java:98)
> at
> org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:38) at
> org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1314) at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:1061) at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:911) at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:842) at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:601)
> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:297) at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:314) at
> org.imgt.dao.GENEDBDAO.getLIGMDBentries(GENEDBDAO.java:590) at
> org.imgt.dao.GENEDBDAO.getLIGMDBentries(GENEDBDAO.java:616) at
> org.imgt.util.fasta.GeneFastaSeq2.getFastaSeq(GeneFastaSeq2.java:46) at
> org.imgt.toolbox.genedb.GenedbFlatFile.run(GenedbFlatFile.java:81) at
> org.imgt.tools.cmd.FFile.run(FFile.java:18) at
> picocli.CommandLine.executeUserObject(CommandLine.java:1939) at
> picocli.CommandLine.access$1300(CommandLine.java:145) at
> picocli.CommandLine$RunAll.recursivelyExecuteUserObject(CommandLine.java:2431)
> at
> picocli.CommandLine$RunAll.recursivelyExecuteUserObject(CommandLine.java:2433)
> at picocli.CommandLine$RunAll.handle(CommandLine.java:2428) at
> picocli.CommandLine$RunAll.handle(CommandLine.java:2389) at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
> at picocli.CommandLine$RunAll.execute(CommandLine.java:2391) at
> picocli.CommandLine.execute(CommandLine.java:2078) at
> org.imgt.tools.SeqTool.main(SeqTool.java:19) Caused by:
> java.lang.ClassCastException: Cannot convert object
> "org.mariadb.jdbc.MariaDbBlob@2178ae3b" of type "class
> org.mariadb.jdbc.MariaDbBlob" into an instance of "class [B". at
> org.apache.openjpa.kernel.Filters.convert(Filters.java:395) at
> org.apache.openjpa.kernel.Filters.convert(Filters.java:271) at
> org.apache.openjpa.kernel.ResultPacker.packUserType(ResultPacker.java:280)
> ... 25 more{noformat}
> Not sure on which side (OpenJPA? MariaDB Java Client?) the problem belongs to.
> Regards,
> Patrice
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OPENJPA-2901) Regression in CriteriaBuilder ParameterExpression behavior
[
https://issues.apache.org/jira/browse/OPENJPA-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507195#comment-17507195
]
Romain Manni-Bucau commented on OPENJPA-2901:
-
Hi [~dazeydev] , great to hear about it! There is no plan for a 3.1.x AFAIK -
no blocker too to do one but 3.2.x should be a transparent replacement.
> Regression in CriteriaBuilder ParameterExpression behavior
> --
>
> Key: OPENJPA-2901
> URL: https://issues.apache.org/jira/browse/OPENJPA-2901
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.1.2
>Reporter: Will Dazey
>Priority: Minor
>
> I was testing OpenJPA for CriteriaBuilder and I noticed a regression in
> behavior when setting ParameterExpressions
> Entity:
> ```
> @Entity
> public class SimpleEntity {
> @Id @Column(name = "KEY_CHAR")
> private String KeyString;
> @Column(name = "ITEM_STRING1")
> private String itemString1;
> @Column(name = "ITEM_STRING2")
> private String itemString2;
> @Column(name = "ITEM_STRING3")
> private String itemString3;
> @Column(name = "ITEM_STRING4")
> private String itemString4;
> @Column(name = "ITEM_INTEGER1")
> private Integer itemInteger1;
> ```
> Test:
> ```
> CriteriaBuilder cb = em.getCriteriaBuilder();
> CriteriaQuery cquery = cb.createQuery(SimpleEntity.class);
> Root root = cquery.from(SimpleEntity.class);
> cquery.select(root);
> ParameterExpression strValue1 = cb.parameter(String.class);
> ParameterExpression strValue2 = cb.parameter(String.class);
> ParameterExpression strValue3 = cb.parameter(String.class);
> ParameterExpression strValue4 = cb.parameter(String.class);
> cquery.where(root.get(SimpleEntity_.itemString1).in(strValue1, strValue2,
> strValue3, strValue4));
> query = em.createQuery(cquery);
> query.setParameter(strValue1, "HELLO");
> query.setParameter(strValue2, "ONE");
> query.setParameter(strValue3, "WORLD");
> query.setParameter(strValue4, "PEOPLE");
> ```
> 3.0.0 SQL Trace:
> ```
> openjpa.jdbc.SQL - executing prepstmnt
> 1876167186
> SELECT t0.KEY_CHAR, t0.ITEM_INTEGER1, t0.ITEM_STRING1, t0.ITEM_STRING2,
> t0.ITEM_STRING3, t0.ITEM_STRING4
> FROM SimpleEntity t0
> WHERE ((t0.ITEM_STRING1 = ? OR t0.ITEM_STRING1 = ? OR t0.ITEM_STRING1 =
> ? OR t0.ITEM_STRING1 = ?) AND t0.ITEM_STRING1 IS NOT NULL)
> [params=(String) HELLO, (String) ONE, (String) WORLD, (String) PEOPLE]
> ```
> 3.1.2 SQL Trace:
> ```
> openjpa.jdbc.SQL - executing prepstmnt
> 1987058658
> SELECT t0.KEY_CHAR, t0.ITEM_INTEGER1, t0.ITEM_STRING1, t0.ITEM_STRING2,
> t0.ITEM_STRING3, t0.ITEM_STRING4
> FROM SimpleEntity t0
> WHERE ((t0.ITEM_STRING1 = ? OR t0.ITEM_STRING1 = ? OR t0.ITEM_STRING1 =
> ? OR t0.ITEM_STRING1 = ?) AND t0.ITEM_STRING1 IS NOT NULL)
> [params=(String) HELLO, (String) HELLO, (String) HELLO, (String) HELLO]
> ```
> I have not tested against the latest 3.2.1 binary yet, so I don't know if
> this was fixed in the latest 3.2.x, but the latest 3.1.x does contain this
> issue. I will test 3.2.x next.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (OPENJPA-2900) javax.xml.bind must be relocated to jakarta namespace
[ https://issues.apache.org/jira/browse/OPENJPA-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENJPA-2900: Fix Version/s: (was: 3.2.1) > javax.xml.bind must be relocated to jakarta namespace > - > > Key: OPENJPA-2900 > URL: https://issues.apache.org/jira/browse/OPENJPA-2900 > Project: OpenJPA > Issue Type: Improvement >Reporter: Jean-Louis Monteiro >Priority: Major > > javax.xml.bind is missing in the relocate patterns of the shade artifacts. > We seem to also be quite generous with other patterns not used in OpenJPA, so > the PR also includes some clean ups. > > Adding as well jakarta exceptions because some packages were excluded from > the javax --> jakarta namespace change. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (OPENJPA-2899) openjpa-maven-plugin 3.2.1 uses log4j version 2.14.1
[ https://issues.apache.org/jira/browse/OPENJPA-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENJPA-2899: Priority: Minor (was: Critical) > openjpa-maven-plugin 3.2.1 uses log4j version 2.14.1 > > > Key: OPENJPA-2899 > URL: https://issues.apache.org/jira/browse/OPENJPA-2899 > Project: OpenJPA > Issue Type: Bug >Reporter: Rich M >Priority: Minor > > openjpa-maven-plugin version 3.2.1 contains dependency of log4j version > 2.14.1. > 2.14.1 > Since the log4j versions lower than 2.17.1 contains critical vulnerabilities, > what is the plan to move away from this version ? > Can this be overridden when declaring openjpa-maven-plugin dependency ? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (OPENJPA-2899) openjpa-maven-plugin 3.2.1 uses log4j version 2.14.1
[ https://issues.apache.org/jira/browse/OPENJPA-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENJPA-2899: Issue Type: Task (was: Bug) > openjpa-maven-plugin 3.2.1 uses log4j version 2.14.1 > > > Key: OPENJPA-2899 > URL: https://issues.apache.org/jira/browse/OPENJPA-2899 > Project: OpenJPA > Issue Type: Task >Reporter: Rich M >Priority: Minor > > openjpa-maven-plugin version 3.2.1 contains dependency of log4j version > 2.14.1. > 2.14.1 > Since the log4j versions lower than 2.17.1 contains critical vulnerabilities, > what is the plan to move away from this version ? > Can this be overridden when declaring openjpa-maven-plugin dependency ? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (OPENJPA-2899) openjpa-maven-plugin 3.2.1 uses log4j version 2.14.1
[ https://issues.apache.org/jira/browse/OPENJPA-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17496545#comment-17496545 ] Romain Manni-Bucau commented on OPENJPA-2899: - Hi [~richm123] , In terms of vulnerability this is quite low (or you would have to show me how to exploit it without willing it ;)) You can override it adding the version you want as a dependency of the plugin. That said i have no issue to move the scope to provided since this dependency is not needed. > openjpa-maven-plugin 3.2.1 uses log4j version 2.14.1 > > > Key: OPENJPA-2899 > URL: https://issues.apache.org/jira/browse/OPENJPA-2899 > Project: OpenJPA > Issue Type: Bug >Reporter: Rich M >Priority: Critical > > openjpa-maven-plugin version 3.2.1 contains dependency of log4j version > 2.14.1. > 2.14.1 > Since the log4j versions lower than 2.17.1 contains critical vulnerabilities, > what is the plan to move away from this version ? > Can this be overridden when declaring openjpa-maven-plugin dependency ? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (OPENJPA-2889) commons-pool2 bundle version defined in karaf features repository is not aligned with the actual version used by openjpa
[ https://issues.apache.org/jira/browse/OPENJPA-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2889. - Resolution: Fixed > commons-pool2 bundle version defined in karaf features repository is not > aligned with the actual version used by openjpa > > > Key: OPENJPA-2889 > URL: https://issues.apache.org/jira/browse/OPENJPA-2889 > Project: OpenJPA > Issue Type: Bug > Components: osgi >Affects Versions: 3.2.0 >Reporter: Jean-Baptiste Onofré >Priority: Major > Fix For: 3.2.1 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (OPENJPA-2891) @Geenrated annotation cannot be disabled for static metamodel
[
https://issues.apache.org/jira/browse/OPENJPA-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17451563#comment-17451563
]
Romain Manni-Bucau commented on OPENJPA-2891:
-
Thanks Benjamin, merged!
> @Geenrated annotation cannot be disabled for static metamodel
> -
>
> Key: OPENJPA-2891
> URL: https://issues.apache.org/jira/browse/OPENJPA-2891
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Marwell
>Priority: Critical
> Fix For: 3.2.1
>
>
> The {{@Generated}} annotation will be added to any generated static metamodel
> class, no matter the annotation is available.
> From Java9 upwards, this annotation is not on the classpath anymore (by
> default), leading to compile errors.
> I would suggest to add either an override parameter (similar to hibernate,
> {{-AaddGeneratedAnnotation=false}}, see
> https://docs.jboss.org/hibernate/orm/5.0/topical/html/metamodelgen/MetamodelGenerator.html
> Or
> detect whether the annotation is on the classpath.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (OPENJPA-2891) @Geenrated annotation cannot be disabled for static metamodel
[
https://issues.apache.org/jira/browse/OPENJPA-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau resolved OPENJPA-2891.
-
Fix Version/s: 3.2.1
Resolution: Fixed
> @Geenrated annotation cannot be disabled for static metamodel
> -
>
> Key: OPENJPA-2891
> URL: https://issues.apache.org/jira/browse/OPENJPA-2891
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Marwell
>Priority: Critical
> Fix For: 3.2.1
>
>
> The {{@Generated}} annotation will be added to any generated static metamodel
> class, no matter the annotation is available.
> From Java9 upwards, this annotation is not on the classpath anymore (by
> default), leading to compile errors.
> I would suggest to add either an override parameter (similar to hibernate,
> {{-AaddGeneratedAnnotation=false}}, see
> https://docs.jboss.org/hibernate/orm/5.0/topical/html/metamodelgen/MetamodelGenerator.html
> Or
> detect whether the annotation is on the classpath.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (OPENJPA-2881) runtime exception in org.apache.openjpa.lib.meta.XMLMetaDataParser.parseNewResource
[ https://issues.apache.org/jira/browse/OPENJPA-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446348#comment-17446348 ] Romain Manni-Bucau commented on OPENJPA-2881: - Yes, namespace should likely be ignored most of the time by default or rewired to make all ee ones equivalent (better). > runtime exception in > org.apache.openjpa.lib.meta.XMLMetaDataParser.parseNewResource > --- > > Key: OPENJPA-2881 > URL: https://issues.apache.org/jira/browse/OPENJPA-2881 > Project: OpenJPA > Issue Type: Improvement >Affects Versions: 3.1.2 >Reporter: Patrice DUROUX >Assignee: Maxim Solodovnik >Priority: Major > > Hi, > Similar to my previous post here: > [http://mail-archives.apache.org/mod_mbox/openjpa-users/202103.mbox/browser] > The runtime is broken due to the following: > > org.apache.openjpa.util.GeneralException: org.xml.sax.SAXException: > jar:file:[CUT]/META-INF/persistence.xml [Location:Line: 4, C: 16]: > org.xml.sax.SAXParseException; systemId: > http://www.oracle.com/splash/www/index.html; lineNumber: 1; columnNumber: 1; > Fin prématurée du fichier. > at > org.apache.openjpa.lib.meta.XMLMetaDataParser.parseNewResource(XMLMetaDataParser.java:435) > at > org.apache.openjpa.lib.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:355) > at > org.apache.openjpa.lib.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:332) > at > org.apache.openjpa.lib.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:301) > at > org.apache.openjpa.persistence.PersistenceProductDerivation$ConfigurationParser.parse(PersistenceProductDerivation.java:813) > at > org.apache.openjpa.persistence.PersistenceProductDerivation.parseResources(PersistenceProductDerivation.java:578) > at > org.apache.openjpa.persistence.PersistenceProductDerivation.load(PersistenceProductDerivation.java:530) > at > org.apache.openjpa.persistence.PersistenceProductDerivation.load(PersistenceProductDerivation.java:341) > at > org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:90) > at > org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:159) > at > org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:66) > at > javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:106) > at > javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:68) > [CUT] > Thanks, > Patrice -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (OPENJPA-2886) javax.persistence.schema-generation.database.action setting seems to be ignored when using Persistence.createEntityManagerFactory()
[
https://issues.apache.org/jira/browse/OPENJPA-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17442174#comment-17442174
]
Romain Manni-Bucau commented on OPENJPA-2886:
-
Yeah, use ServiceLoader to get an instance of PersistenceProvider then use
container factory ;)
> javax.persistence.schema-generation.database.action setting seems to be
> ignored when using Persistence.createEntityManagerFactory()
> ---
>
> Key: OPENJPA-2886
> URL: https://issues.apache.org/jira/browse/OPENJPA-2886
> Project: OpenJPA
> Issue Type: Question
> Components: jpa
>Affects Versions: 3.1.2
> Environment: TomEE 8.0.6 (and 8.0.9-SNAPSHOT), Netbeans 12.5, MS
> Windows 10
>Reporter: Makkus B.
>Priority: Major
>
> As I'm very new to OpenJPA I'm not quite sure, if this the follwing is an
> OpenJPA issue but I obeserve that:
> When creating a persistence unit via persistence.xml (Tomee 8) openJPA
> creates missing entity tables according to the
> javax.persistence.schema-generation.database.action property. However, Im
> currently testing a 'runtime' datasource configuration like this:
>
> {code:java}
> Properties props = new Properties();
> props.put("javax.persistence.jtaDataSource", "jdbc/dynamicDb");
> props.put("openjpa.ConnectionDriverName", "org.mariadb.jdbc.Driver");
> props.put("openjpa.ConnectionURL",
> "jdbc:mariadb://localhost:3306/test");
> props.put("javax.persistence.schema-generation.database.action",
> "create");
> EntityManagerFactory factory =
> Persistence.createEntityManagerFactory("test-unit3", props);
> return factory.createEntityManager();{code}
> When caling persist() on the created EntityManager I get a rollback excpetion
> due to missing database tables although
> javax.persistence.schema-generation.database.action is given as "create".
> When debugging I can see, that the
> javax.persistence.schema-generation.database.action property value is 0.
> Two questions:
> a) It what I am doing a legal way to create an entity manager at all?
> b) Why are no tables created in this case ( but are when using the
> persitence.xml)?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (OPENJPA-2886) javax.persistence.schema-generation.database.action setting seems to be ignored when using Persistence.createEntityManagerFactory()
[
https://issues.apache.org/jira/browse/OPENJPA-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440419#comment-17440419
]
Romain Manni-Bucau commented on OPENJPA-2886:
-
Hi [~Makkus] , have to admit I didn't spot in the spec if it is legal or not,
only saw persistence.xml references, do you have some other ref? In any case,
we can support it but I think it is not yet coded so you can do a PR to add
this support if needed.
tip: using Persistence container api you can specify it programmatically ;)
> javax.persistence.schema-generation.database.action setting seems to be
> ignored when using Persistence.createEntityManagerFactory()
> ---
>
> Key: OPENJPA-2886
> URL: https://issues.apache.org/jira/browse/OPENJPA-2886
> Project: OpenJPA
> Issue Type: Question
> Components: jpa
>Affects Versions: 3.1.2
> Environment: TomEE 8.0.6 (and 8.0.9-SNAPSHOT), Netbeans 12.5, MS
> Windows 10
>Reporter: Makkus B.
>Priority: Major
>
> As I'm very new to OpenJPA I'm not quite sure, if this the follwing is an
> OpenJPA issue but I obeserve that:
> When creating a persistence unit via persistence.xml (Tomee 8) openJPA
> creates missing entity tables according to the
> javax.persistence.schema-generation.database.action property. However, Im
> currently testing a 'runtime' datasource configuration like this:
>
> {code:java}
> Properties props = new Properties();
> props.put("javax.persistence.jtaDataSource", "jdbc/dynamicDb");
> props.put("openjpa.ConnectionDriverName", "org.mariadb.jdbc.Driver");
> props.put("openjpa.ConnectionURL",
> "jdbc:mariadb://localhost:3306/test");
> props.put("javax.persistence.schema-generation.database.action",
> "create");
> EntityManagerFactory factory =
> Persistence.createEntityManagerFactory("test-unit3", props);
> return factory.createEntityManager();{code}
> When caling persist() on the created EntityManager I get a rollback excpetion
> due to missing database tables although
> javax.persistence.schema-generation.database.action is given as "create".
> When debugging I can see, that the
> javax.persistence.schema-generation.database.action property value is 0.
> Two questions:
> a) It what I am doing a legal way to create an entity manager at all?
> b) Why are no tables created in this case ( but are when using the
> persitence.xml)?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (OPENJPA-2885) Make openjpa-junit5 support jakarta namespace
[ https://issues.apache.org/jira/browse/OPENJPA-2885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2885. - Resolution: Fixed > Make openjpa-junit5 support jakarta namespace > - > > Key: OPENJPA-2885 > URL: https://issues.apache.org/jira/browse/OPENJPA-2885 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.2.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2885) Make openjpa-junit5 support jakarta namespace
Romain Manni-Bucau created OPENJPA-2885: --- Summary: Make openjpa-junit5 support jakarta namespace Key: OPENJPA-2885 URL: https://issues.apache.org/jira/browse/OPENJPA-2885 Project: OpenJPA Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.2.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2884) javax.annotation.processing shouldn't be relocated in jakarta shade
[ https://issues.apache.org/jira/browse/OPENJPA-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2884. - Resolution: Fixed > javax.annotation.processing shouldn't be relocated in jakarta shade > --- > > Key: OPENJPA-2884 > URL: https://issues.apache.org/jira/browse/OPENJPA-2884 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.2.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2884) javax.annotation.processing shouldn't be relocated in jakarta shade
Romain Manni-Bucau created OPENJPA-2884: --- Summary: javax.annotation.processing shouldn't be relocated in jakarta shade Key: OPENJPA-2884 URL: https://issues.apache.org/jira/browse/OPENJPA-2884 Project: OpenJPA Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.2.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2882) Exception passing javax.persistence.* String values to createEntityManager(Map)
[
https://issues.apache.org/jira/browse/OPENJPA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau resolved OPENJPA-2882.
-
Resolution: Fixed
Thanks a lot [~dazeydev] for the PR, applied on master.
> Exception passing javax.persistence.* String values to
> createEntityManager(Map)
> ---
>
> Key: OPENJPA-2882
> URL: https://issues.apache.org/jira/browse/OPENJPA-2882
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions: 2.2.3
>Reporter: Will Dazey
>Priority: Minor
> Fix For: 3.2.1
>
>
> Exception:
> {code:java}
> java.lang.IllegalArgumentException: argument type mismatch
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.apache.openjpa.enhance.Reflection.set(Reflection.java:777)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.setKernelProperty(EntityManagerImpl.java:1936)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.setProperty(EntityManagerImpl.java:1911)
> at
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:258)
> at
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:58)
> Caused by: java.lang.IllegalArgumentException: Error while setting value
> 34567 of class java.lang.String by setter method public
> org.apache.openjpa.persistence.jdbc.JDBCFetchPlan
> org.apache.openjpa.persistence.jdbc.JDBCFetchPlanImpl.setLockTimeout(int) of
> instance org.apache.openjpa.persistence.jdbc.JDBCFetchPlanImpl@28d133b9 by
> reflection.
> at
> org.apache.openjpa.enhance.Reflection.wrapReflectionException(Reflection.java:347)
> at org.apache.openjpa.enhance.Reflection.set(Reflection.java:779)
> {code}
> Fairly easy to reproduce:
> Test:
> {code:java}
> Map properties = new HashMap();
> properties.put("javax.persistence.lock.timeout", "34567");
> EntityManager em = emf.createEntityManager(properties);
> {code}
> Whats happening:
> `org.apache.openjpa.enhance.Reflection.findSetter(org.apache.openjpa.persistence.jdbc.JDBCFetchPlanImpl,
> "LockTimeout")` is returning a setter
> ```
> public org.apache.openjpa.persistence.jdbc.JDBCFetchPlan
> org.apache.openjpa.persistence.jdbc.JDBCFetchPlanImpl.setLockTimeout(int)
> ```
> However,
> `org.apache.openjpa.persistence.EntityManagerImpl.convertUserValue("javax.persistence.lock.timeout",
> "34567", int)` is failing to accurately convert the value from String ->
> int. You might think "oh, well then just pass in (int) 34567 and not (String)
> 34567". However, this isnt always possible. The actual usecase that exposed
> this issue is using deployment descriptors to pass the persistence context
> property:
> {code:java}
>
>
> javax.persistence.lock.timeout
> 34567
>
>
> {code}
> also, this reflection exception doesnt occur if the same property is passed
> to createEntityManagerFactory(Map)! Inconsistent behavior and a runtime
> reflection exception that shouldn't occur.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OPENJPA-2882) Exception passing javax.persistence.* String values to createEntityManager(Map)
[
https://issues.apache.org/jira/browse/OPENJPA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated OPENJPA-2882:
Fix Version/s: 3.2.1
> Exception passing javax.persistence.* String values to
> createEntityManager(Map)
> ---
>
> Key: OPENJPA-2882
> URL: https://issues.apache.org/jira/browse/OPENJPA-2882
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions: 2.2.3
>Reporter: Will Dazey
>Priority: Minor
> Fix For: 3.2.1
>
>
> Exception:
> {code:java}
> java.lang.IllegalArgumentException: argument type mismatch
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.apache.openjpa.enhance.Reflection.set(Reflection.java:777)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.setKernelProperty(EntityManagerImpl.java:1936)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.setProperty(EntityManagerImpl.java:1911)
> at
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:258)
> at
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:58)
> Caused by: java.lang.IllegalArgumentException: Error while setting value
> 34567 of class java.lang.String by setter method public
> org.apache.openjpa.persistence.jdbc.JDBCFetchPlan
> org.apache.openjpa.persistence.jdbc.JDBCFetchPlanImpl.setLockTimeout(int) of
> instance org.apache.openjpa.persistence.jdbc.JDBCFetchPlanImpl@28d133b9 by
> reflection.
> at
> org.apache.openjpa.enhance.Reflection.wrapReflectionException(Reflection.java:347)
> at org.apache.openjpa.enhance.Reflection.set(Reflection.java:779)
> {code}
> Fairly easy to reproduce:
> Test:
> {code:java}
> Map properties = new HashMap();
> properties.put("javax.persistence.lock.timeout", "34567");
> EntityManager em = emf.createEntityManager(properties);
> {code}
> Whats happening:
> `org.apache.openjpa.enhance.Reflection.findSetter(org.apache.openjpa.persistence.jdbc.JDBCFetchPlanImpl,
> "LockTimeout")` is returning a setter
> ```
> public org.apache.openjpa.persistence.jdbc.JDBCFetchPlan
> org.apache.openjpa.persistence.jdbc.JDBCFetchPlanImpl.setLockTimeout(int)
> ```
> However,
> `org.apache.openjpa.persistence.EntityManagerImpl.convertUserValue("javax.persistence.lock.timeout",
> "34567", int)` is failing to accurately convert the value from String ->
> int. You might think "oh, well then just pass in (int) 34567 and not (String)
> 34567". However, this isnt always possible. The actual usecase that exposed
> this issue is using deployment descriptors to pass the persistence context
> property:
> {code:java}
>
>
> javax.persistence.lock.timeout
> 34567
>
>
> {code}
> also, this reflection exception doesnt occur if the same property is passed
> to createEntityManagerFactory(Map)! Inconsistent behavior and a runtime
> reflection exception that shouldn't occur.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2879) Regression in Column.isCompatible
[
https://issues.apache.org/jira/browse/OPENJPA-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17391545#comment-17391545
]
Romain Manni-Bucau commented on OPENJPA-2879:
-
Guess the default shouldn't be a return false/true but a return type ==
getType(), can you try this "fix"?
> Regression in Column.isCompatible
> -
>
> Key: OPENJPA-2879
> URL: https://issues.apache.org/jira/browse/OPENJPA-2879
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2, 3.2.0
>Reporter: Gregory JEVARDAT
>Priority: Major
>
> Bug started to appear when I switched to 3.2.0 and I also spotted it in 3.1.2.
> Metadada resolution started to fail, with all my XML types columns :(
> Debugging pointed me to the merge of columns metadata phase where a call to
> isCompatible now returns false instead of true.
> Looking at the code the add of the case Types.SQLXML at line 788 is causing
> the isCompatible to return false for any of my XML columns. Indeed,
> previously the SQLXML columns where not catched in this case and were relying
> on the default case simply testing equality of the columns.
> I'am wondering in general why the test of the 2 types equality is not done
> before.
> As a quick fix I just added a case testing if the SQLXML is equals to itself
> like for instance
> {code:java}
> case Types.SQLXML: // All XML Types
> case 2007: // Oracle-defined opaque type code for XMLType treated the same
> way
> switch (type) {
> case Types.CHAR:
> case Types.LONGVARCHAR:
> case Types.VARCHAR:
> case Types.CLOB:
> case Types.BLOB:
> case Types.SQLXML:
> return true;
> default:
> return false;
> }
> {code}
>
> Maybe a proper fix is simply to revert the catch of Types.SQLXML, but I'am
> not sure I understand all the hiddent details and assumptions here ... I
> think it is strange than test equality is not tested right at the top of the
> method...
> This bug is quite blocking in my case openjpa fails metadata initialisation
> Cheers
> Gregory
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2878) org.apache.openjpa.persistence.ArgumentException: The persistence provider is attempting to use properties in the persistenc
[
https://issues.apache.org/jira/browse/OPENJPA-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17385679#comment-17385679
]
Romain Manni-Bucau commented on OPENJPA-2878:
-
Sounds so
>
> org.apache.openjpa.persistence.ArgumentException: The persistence provider is
> attempting to use properties in the persistence.xml file to resolve the data
> source ...
> ---
>
> Key: OPENJPA-2878
> URL: https://issues.apache.org/jira/browse/OPENJPA-2878
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.2
>Reporter: Johan Parker
>Priority: Major
>
>
> {code:java}
>
> org.apache.openjpa.persistence.ArgumentException: The persistence provider is
> attempting to use properties in the persistence.xml file to resolve the data
> source. A Java Database Connectivity (JDBC) driver or data source class name
> must be specified in the openjpa.ConnectionDriverName or
> javax.persistence.jdbc.driver property. The following properties are
> available in the configuration:
> "org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl@393fa2d".
>
> org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:70)
>
> org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.createConnectionFactory(JDBCConfigurationImpl.java:925)
>
> org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDBDictionaryInstance(JDBCConfigurationImpl.java:649)
>
> org.apache.openjpa.jdbc.meta.MappingRepository.endConfiguration(MappingRepository.java:1540)
>
> org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:531)
>
> org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:456)
>
> org.apache.openjpa.lib.conf.PluginValue.instantiate(PluginValue.java:123)
>
> org.apache.openjpa.conf.MetaDataRepositoryValue.instantiate(MetaDataRepositoryValue.java:68)
> org.apache.openjpa.lib.conf.ObjectValue.instantiate(ObjectValue.java:84)
>
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.newMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:1113)
>
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.getMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:1102)
>
> org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly(AbstractBrokerFactory.java:657)
>
> org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:207)
>
> org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:166)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.doCreateEM(EntityManagerFactoryImpl.java:282)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:201)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:188)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:178)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:64)
> GPMWS.getJPA(GPMWS.java:26)
> {code}
> using Tomee 8.0.6; openjpa3.1.2; Eclipse for java ee 2020 r12
>
> here is the GPMWS.java
>
> {code:java}
> @Path("/")
> public class GPMWS {
>
> @GET
> @Path("/getJPA")
> @Produces(MediaType.APPLICATION_JSON)
> public List getJPA() {
> EntityManager entityManager =
> JPAboot.getEntityManagerFactory().createEntityManager();
> TypedQuery query = entityManager.createNamedQuery("getJPA", JPA.class);
> List results = query.getResultList();
> return results;
> }
> {code}
> here is JPAboot.java
>
>
> {code:java}
> public class JPAboot {
> private static final String PERSISTENCE_UNIT_NAME = "JPAPER";
> private static EntityManagerFactory factory;
> public static EntityManagerFactory getEntityManagerFactory() {
> if (factory == null) {
> factory =
> Persistence.createEntityManagerFactory(PERSISTENCE_UNIT_NAME);
> }
> return factory;
> }
> public static void shutdown() {
> if (factory != null) {
> factory.close();
> }
> }
> }{code}
>
> here JPA.java
>
> {code:java}
> @Entity
> @Table(name = "JPAs")
> @NamedQuery(name="getJPA", query="SELECT j FROM JPAs j")
> public class JPA {
> @Id
> @Column(name = "id")
> private int id;
> @Column(name = "desc")
> private String desc;
> public JPA() { }
> public JPA(int id, String desc) {
> super();
> this.id = id;
> this.desc = desc;
> }
> public String getid() { return this.id; }
>
[jira] [Commented] (OPENJPA-2878) org.apache.openjpa.persistence.ArgumentException: The persistence provider is attempting to use properties in the persistenc
[
https://issues.apache.org/jira/browse/OPENJPA-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17385627#comment-17385627
]
Romain Manni-Bucau commented on OPENJPA-2878:
-
Tomee autosets a lot of things in units, so a tomee bug ;)
>
> org.apache.openjpa.persistence.ArgumentException: The persistence provider is
> attempting to use properties in the persistence.xml file to resolve the data
> source ...
> ---
>
> Key: OPENJPA-2878
> URL: https://issues.apache.org/jira/browse/OPENJPA-2878
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.2
>Reporter: Johan Parker
>Priority: Major
>
>
> {code:java}
>
> org.apache.openjpa.persistence.ArgumentException: The persistence provider is
> attempting to use properties in the persistence.xml file to resolve the data
> source. A Java Database Connectivity (JDBC) driver or data source class name
> must be specified in the openjpa.ConnectionDriverName or
> javax.persistence.jdbc.driver property. The following properties are
> available in the configuration:
> "org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl@393fa2d".
>
> org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:70)
>
> org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.createConnectionFactory(JDBCConfigurationImpl.java:925)
>
> org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDBDictionaryInstance(JDBCConfigurationImpl.java:649)
>
> org.apache.openjpa.jdbc.meta.MappingRepository.endConfiguration(MappingRepository.java:1540)
>
> org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:531)
>
> org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:456)
>
> org.apache.openjpa.lib.conf.PluginValue.instantiate(PluginValue.java:123)
>
> org.apache.openjpa.conf.MetaDataRepositoryValue.instantiate(MetaDataRepositoryValue.java:68)
> org.apache.openjpa.lib.conf.ObjectValue.instantiate(ObjectValue.java:84)
>
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.newMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:1113)
>
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.getMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:1102)
>
> org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly(AbstractBrokerFactory.java:657)
>
> org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:207)
>
> org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:166)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.doCreateEM(EntityManagerFactoryImpl.java:282)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:201)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:188)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:178)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:64)
> GPMWS.getJPA(GPMWS.java:26)
> {code}
> using Tomee 8.0.6; openjpa3.1.2; Eclipse for java ee 2020 r12
>
> here is the GPMWS.java
>
> {code:java}
> @Path("/")
> public class GPMWS {
>
> @GET
> @Path("/getJPA")
> @Produces(MediaType.APPLICATION_JSON)
> public List getJPA() {
> EntityManager entityManager =
> JPAboot.getEntityManagerFactory().createEntityManager();
> TypedQuery query = entityManager.createNamedQuery("getJPA", JPA.class);
> List results = query.getResultList();
> return results;
> }
> {code}
> here is JPAboot.java
>
>
> {code:java}
> public class JPAboot {
> private static final String PERSISTENCE_UNIT_NAME = "JPAPER";
> private static EntityManagerFactory factory;
> public static EntityManagerFactory getEntityManagerFactory() {
> if (factory == null) {
> factory =
> Persistence.createEntityManagerFactory(PERSISTENCE_UNIT_NAME);
> }
> return factory;
> }
> public static void shutdown() {
> if (factory != null) {
> factory.close();
> }
> }
> }{code}
>
> here JPA.java
>
> {code:java}
> @Entity
> @Table(name = "JPAs")
> @NamedQuery(name="getJPA", query="SELECT j FROM JPAs j")
> public class JPA {
> @Id
> @Column(name = "id")
> private int id;
> @Column(name = "desc")
> private String desc;
> public JPA() { }
> public JPA(int id, String desc) {
> super();
> this.id = id;
> this.desc = desc;
>
[jira] [Commented] (OPENJPA-2878) org.apache.openjpa.persistence.ArgumentException: The persistence provider is attempting to use properties in the persistenc
[
https://issues.apache.org/jira/browse/OPENJPA-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17385540#comment-17385540
]
Romain Manni-Bucau commented on OPENJPA-2878:
-
Hi,
Did you try setting openjpa.ConnectionDriverName to ensure it works?
Did you try in standalone without tomee (which tends to force a datasource by
default)?
>
> org.apache.openjpa.persistence.ArgumentException: The persistence provider is
> attempting to use properties in the persistence.xml file to resolve the data
> source ...
> ---
>
> Key: OPENJPA-2878
> URL: https://issues.apache.org/jira/browse/OPENJPA-2878
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.2
>Reporter: Johan Parker
>Priority: Major
>
>
> {code:java}
>
> org.apache.openjpa.persistence.ArgumentException: The persistence provider is
> attempting to use properties in the persistence.xml file to resolve the data
> source. A Java Database Connectivity (JDBC) driver or data source class name
> must be specified in the openjpa.ConnectionDriverName or
> javax.persistence.jdbc.driver property. The following properties are
> available in the configuration:
> "org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl@393fa2d".
>
> org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:70)
>
> org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.createConnectionFactory(JDBCConfigurationImpl.java:925)
>
> org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDBDictionaryInstance(JDBCConfigurationImpl.java:649)
>
> org.apache.openjpa.jdbc.meta.MappingRepository.endConfiguration(MappingRepository.java:1540)
>
> org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:531)
>
> org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:456)
>
> org.apache.openjpa.lib.conf.PluginValue.instantiate(PluginValue.java:123)
>
> org.apache.openjpa.conf.MetaDataRepositoryValue.instantiate(MetaDataRepositoryValue.java:68)
> org.apache.openjpa.lib.conf.ObjectValue.instantiate(ObjectValue.java:84)
>
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.newMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:1113)
>
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.getMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:1102)
>
> org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly(AbstractBrokerFactory.java:657)
>
> org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:207)
>
> org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:166)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.doCreateEM(EntityManagerFactoryImpl.java:282)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:201)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:188)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:178)
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:64)
> GPMWS.getJPA(GPMWS.java:26)
> {code}
> using Tomee 8.0.6; openjpa3.1.2; Eclipse for java ee 2020 r12
>
> here is the GPMWS.java
>
> {code:java}
> @Path("/")
> public class GPMWS {
>
> @GET
> @Path("/getJPA")
> @Produces(MediaType.APPLICATION_JSON)
> public List getJPA() {
> EntityManager entityManager =
> JPAboot.getEntityManagerFactory().createEntityManager();
> TypedQuery query = entityManager.createNamedQuery("getJPA", JPA.class);
> List results = query.getResultList();
> return results;
> }
> {code}
> here is JPAboot.java
>
>
> {code:java}
> public class JPAboot {
> private static final String PERSISTENCE_UNIT_NAME = "JPAPER";
> private static EntityManagerFactory factory;
> public static EntityManagerFactory getEntityManagerFactory() {
> if (factory == null) {
> factory =
> Persistence.createEntityManagerFactory(PERSISTENCE_UNIT_NAME);
> }
> return factory;
> }
> public static void shutdown() {
> if (factory != null) {
> factory.close();
> }
> }
> }{code}
>
> here JPA.java
>
> {code:java}
> @Entity
> @Table(name = "JPAs")
> @NamedQuery(name="getJPA", query="SELECT j FROM JPAs j")
> public class JPA {
> @Id
> @Column(name = "id")
> private int id;
> @Column(name = "desc")
> private String desc;
>
[jira] [Commented] (OPENJPA-2876) running 'refresh' schema action creates wrong SQL output
[
https://issues.apache.org/jira/browse/OPENJPA-2876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361218#comment-17361218
]
Romain Manni-Bucau commented on OPENJPA-2876:
-
[~struberg] guess it is the `if (_writer == null)` tests which should get
removed since it is handled in the impl and shouldn't be an issue until new
code expected a writer which is a bug.
> running 'refresh' schema action creates wrong SQL output
>
>
> Key: OPENJPA-2876
> URL: https://issues.apache.org/jira/browse/OPENJPA-2876
> Project: OpenJPA
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.2.1
>
>
> Seems we trashed the SQL refresh feature along the way to JPA-2.0.
> I have a sample with an Entity 'Customer' with just an ID. Then I add a
> column {{OTHER_NAME}} and generate the result with {{sqlAction=refresh}}
> In OpenJPA-2.4.3 we get the following output:
> {noformat}
> ALTER TABLE CUSTOMER ADD COLUMN OTHER_NAME VARCHAR(255);
> {noformat}
> In OpenJPA-3.0.0 onwards we get this:
> {noformat}
> ALTER TABLE CUSTOMER ADD COLUMN OTHER_NAME VARCHAR(255);
> CREATE TABLE CUSTOMER (ID BIGINT NOT NULL, active VARCHAR(1), OTHER_NAME
> VARCHAR(255), specialCustomer VARCHAR(1) NOT NULL, PRIMARY KEY (ID));
> CREATE TABLE OPENJPA_SEQUENCE_TABLE (ID TINYINT NOT NULL, SEQUENCE_VALUE
> BIGINT, PRIMARY KEY (ID));
> CREATE TABLE PUBLIC.CUSTOMER (ID BIGINT, ACTIVE VARCHAR(1), NAME
> VARCHAR(255), SPECIALCUSTOMER VARCHAR(1));
> {noformat}
> It seems like we do not only run the MappingAction 'refresh' but also a
> 'build' plus we do it also without Schema and with the current Schema
> (PUBLIC).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2875) JPA Provider must filter out other JPA Providers
[ https://issues.apache.org/jira/browse/OPENJPA-2875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2875. - Fix Version/s: 3.2.1 Resolution: Fixed PR merged, thanks JL! > JPA Provider must filter out other JPA Providers > > > Key: OPENJPA-2875 > URL: https://issues.apache.org/jira/browse/OPENJPA-2875 > Project: OpenJPA > Issue Type: Improvement >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 3.2.1 > > > Currently OpenJPA JPA Provider does not check what is the provider being > used. So when using multiple providers, OpenJPA attempts to do things and > fails badly. > > It should only attempt to do something when OpenJPA JPA provider is specified > or when no provider is specified. If EclipseLink or Hibernate for instance is > used, OpenJPA should not do anything, so the service loader can move on and > switch to the next provider. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2872) provide Jakarta EE artifacts
[ https://issues.apache.org/jira/browse/OPENJPA-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17341324#comment-17341324 ] Romain Manni-Bucau commented on OPENJPA-2872: - Already done in OPENJPA-2815? > provide Jakarta EE artifacts > > > Key: OPENJPA-2872 > URL: https://issues.apache.org/jira/browse/OPENJPA-2872 > Project: OpenJPA > Issue Type: New Feature > Components: build / infrastructure >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.2.0 > > > With 3.2.0 we should also add JakartaEE artifacts. We can simply add a > shading to provide those via an attached artifact with classifier 'jakarta'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2869) Specification-Version still in v2
Romain Manni-Bucau created OPENJPA-2869: --- Summary: Specification-Version still in v2 Key: OPENJPA-2869 URL: https://issues.apache.org/jira/browse/OPENJPA-2869 Project: OpenJPA Issue Type: Task Affects Versions: 3.1.2 Reporter: Romain Manni-Bucau 2.0 is still used in our poms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2865) [Oracle] use native java.time JDBC features
[
https://issues.apache.org/jira/browse/OPENJPA-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324485#comment-17324485
]
Romain Manni-Bucau commented on OPENJPA-2865:
-
While represented value is correct it is fine, no need to store the original
offset or timezone IMHO.
> [Oracle] use native java.time JDBC features
> ---
>
> Key: OPENJPA-2865
> URL: https://issues.apache.org/jira/browse/OPENJPA-2865
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> For the supported java.time types like {{LocalDate}}, LocalDateTime,
> LocalTime, OffsetTime and OffsetDateTime we should make use of native JDBC
> driver features to avoid internal conversions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2852) Maven Plugin should be marked thread safe
Romain Manni-Bucau created OPENJPA-2852: --- Summary: Maven Plugin should be marked thread safe Key: OPENJPA-2852 URL: https://issues.apache.org/jira/browse/OPENJPA-2852 Project: OpenJPA Issue Type: Improvement Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2852) Maven Plugin should be marked thread safe
[ https://issues.apache.org/jira/browse/OPENJPA-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2852. - Resolution: Fixed > Maven Plugin should be marked thread safe > - > > Key: OPENJPA-2852 > URL: https://issues.apache.org/jira/browse/OPENJPA-2852 > Project: OpenJPA > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2847) CriteriaUpdate/CriteriaDelete are not implemented
[ https://issues.apache.org/jira/browse/OPENJPA-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256369#comment-17256369 ] Romain Manni-Bucau commented on OPENJPA-2847: - Hi [~pveselov], can be a working point but "targetting" was used instead of "supports" because some parts are not implemented. This criteria builder part looks not that complicated because it is mainly the same as the select part and most impl already exists. Do you want to give a try to implement it? > CriteriaUpdate/CriteriaDelete are not implemented > - > > Key: OPENJPA-2847 > URL: https://issues.apache.org/jira/browse/OPENJPA-2847 > Project: OpenJPA > Issue Type: Bug > Components: criteria >Affects Versions: 3.1.2 >Reporter: Pawel Veselov >Priority: Major > > I was rather excited when I saw the statement on > http://openjpa.apache.org/ that 3.x releases "target" the 2.2 JPA > Spec, but are *compatible* with specs 2.1 and below specs, sort of > reading it as 3.x supporting 2.2 spec. > My excitement was crushed with a rather heavy boulder once I saw that > the criteria builder simply throws an unsupported operation exception > in methods to create criteria update/delete objects. > I'm filing this as a bug because of this wording, IMHO, if that is just a > missing feature, implementing 2.2 spec can't be claimed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2845) JPA intermittently giving null resultset even DB has value
[ https://issues.apache.org/jira/browse/OPENJPA-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17250977#comment-17250977 ] Romain Manni-Bucau commented on OPENJPA-2845: - Without a reproducer it will be hard or even almost impossible but some caching - either actual cache or reuse of some JPA component instances - can make the resultset partially bypassed in some particular configurations. Without more information it is the main cause I can think about. > JPA intermittently giving null resultset even DB has value > -- > > Key: OPENJPA-2845 > URL: https://issues.apache.org/jira/browse/OPENJPA-2845 > Project: OpenJPA > Issue Type: Bug >Reporter: Deepesh >Priority: Critical > > Data is getting fetched from Oracle DB but while mapping it back to JPA > object, it gets null. This can be seen through Dynatrace that SQL returns row > result but JPA resultset is getting null. > Query is quite simple and just fetching the record based on primary key. > Although another field is being passed in where clause with primary key but > it returns single row. > Also, same jpa query provides results (same input) several times before. > We enabled jpa logs and see query runs fine on DB. > Is there any thresold due to which JPA not working as expected? Any > suggestions to handle this ? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2845) JPA intermittently giving null resultset even DB has value
[ https://issues.apache.org/jira/browse/OPENJPA-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17250922#comment-17250922 ] Romain Manni-Bucau commented on OPENJPA-2845: - Hi [~Mundra], any way you share your setup or reproduce it in a sample app you can share? It can come from a lot of factors like the configuration, some caching setup etc... > JPA intermittently giving null resultset even DB has value > -- > > Key: OPENJPA-2845 > URL: https://issues.apache.org/jira/browse/OPENJPA-2845 > Project: OpenJPA > Issue Type: Bug >Reporter: Deepesh >Priority: Critical > > Data is getting fetched from Oracle DB but while mapping it back to JPA > object, it gets null. This can be seen through Dynatrace that SQL returns row > result but JPA resultset is getting null. > Query is quite simple and just fetching the record based on primary key. > Although another field is being passed in where clause with primary key but > it returns single row. > Also, same jpa query provides results (same input) several times before. > We enabled jpa logs and see query runs fine on DB. > Is there any thresold due to which JPA not working as expected? Any > suggestions to handle this ? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2842) openjpa.Log=log4j should automatically switch between log4j-1.x and 2.x
[ https://issues.apache.org/jira/browse/OPENJPA-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241340#comment-17241340 ] Romain Manni-Bucau commented on OPENJPA-2842: - [~struberg] ok let's take it simply: # people are using log4j for v1 and v2 -> so we must keep the most backward compatible so v1 # tomee: it uses it only when log4j1 logger is configured (which comfort point 1) and it is not the default (which stays JUL). # as mentionned [https://github.com/struberg/openjpa/commit/21123ac51cb4f62c17df8eff0df476116f3f3f75] does not work, tomee is another example (it is common to have both there, same in most project bringing spark clients or so, this is why there is no way a "guess" algorithm works, you will just pick randomly a logger and likely break the infrastructure people put in place to get logs) So let's make it working for everything, create a log4j2 implementation (add an "auto" if you think it makes sense, I think it can) and we are done and deterministic. We will only break people using log4j2 in 3.1.0, 3.1.1 and 3.1.2 which is very few compared to the opposite which is a lot since it had be inherited for years (whereas log4j2 is rarely used directly but more through slf4j these days). Think it is the less breaking option of the 3. > openjpa.Log=log4j should automatically switch between log4j-1.x and 2.x > --- > > Key: OPENJPA-2842 > URL: https://issues.apache.org/jira/browse/OPENJPA-2842 > Project: OpenJPA > Issue Type: Bug > Components: logging >Affects Versions: 3.1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.1.3 > > > Somewhen in 2018 we added support for log4j2. Sadly we killed log4j-1.x > support (which is still widely in use). > > We should automatically detect which version of log4j is available and then > use that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2842) openjpa.Log=log4j should automatically switch between log4j-1.x and 2.x
[ https://issues.apache.org/jira/browse/OPENJPA-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241325#comment-17241325 ] Romain Manni-Bucau commented on OPENJPA-2842: - [~struberg] let's make it simple, OPENJPA-2752 just intent to upgrade libs and moving from log4j1 to log4j2 is not a lib upgrade so it is a bug and we revert it. We add a log4j2 impl (+ option) and we're done. We just document it clearly in 3.1.3 annoucement and flag it as a bug. TomEE does not set openajp.Log to log4j - if so it is a bug, it must respect user config or use tomee logging - which is not log4j by default. The "use 2 if there and 1 is not" is as broken as the opposite since it is finally random as mentionned. People not having upgraded from < 3.1.0 - and some will upgrade from there - will be broken, so let's not do that step which will require a revert anyway after and just do it as it should have been straight. If we really want a "guess" algo we must use an "auto" flag IMHO. > openjpa.Log=log4j should automatically switch between log4j-1.x and 2.x > --- > > Key: OPENJPA-2842 > URL: https://issues.apache.org/jira/browse/OPENJPA-2842 > Project: OpenJPA > Issue Type: Bug > Components: logging >Affects Versions: 3.1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.1.3 > > > Somewhen in 2018 we added support for log4j2. Sadly we killed log4j-1.x > support (which is still widely in use). > > We should automatically detect which version of log4j is available and then > use that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2842) openjpa.Log=log4j should automatically switch between log4j-1.x and 2.x
[ https://issues.apache.org/jira/browse/OPENJPA-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240978#comment-17240978 ] Romain Manni-Bucau commented on OPENJPA-2842: - It is probably wiser to use "log4j2" for log4j2 impl, any guess will likely be random and a bug since both are still often together due to 3rd parties. > openjpa.Log=log4j should automatically switch between log4j-1.x and 2.x > --- > > Key: OPENJPA-2842 > URL: https://issues.apache.org/jira/browse/OPENJPA-2842 > Project: OpenJPA > Issue Type: Bug > Components: logging >Affects Versions: 3.1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.1.3 > > > Somewhen in 2018 we added support for log4j2. Sadly we killed log4j-1.x > support (which is still widely in use). > > We should automatically detect which version of log4j is available and then > use that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2841) Broken superfluous joins with subqueries
[
https://issues.apache.org/jira/browse/OPENJPA-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17238862#comment-17238862
]
Romain Manni-Bucau commented on OPENJPA-2841:
-
Hi [~mormegil],
Did you check out why in openjpa code?
A quick look seems to show that
org.apache.openjpa.jdbc.sql.SelectImpl#getTableAlias forces "create=true" which
means to create an alias for missing joins.
A trivial fix is to match generated variables with joins (key type = Key vs
String for the failling call) in
org.apache.openjpa.jdbc.sql.SelectImpl#findAlias but it would trigger other
issues.
The root cause is that the join for this last part of the query is missing so a
new alias is created to fulfill the query translation.
Do you want to have a look and try to propose a patch to match the variable
more accurately when there are multiple nested queries (not fully sure this is
supported in JPA spec but we can enhance our support)?
> Broken superfluous joins with subqueries
>
>
> Key: OPENJPA-2841
> URL: https://issues.apache.org/jira/browse/OPENJPA-2841
> Project: OpenJPA
> Issue Type: Bug
> Components: query, sql
>Affects Versions: 2.4.2, 3.1.2
>Reporter: Petr Kadlec
>Priority: Major
>
> OpenJPA generates wrong SQL for a query with nested subqueries, causing the
> result to be wrong. My attempts to rewrite the query helped to get the
> correct results, even though the generated alternate queries seem not to be
> perfect. (There might a way to write them better.)
> The following query:
> {{select u from User u where u.email=:firstEmail and u<>:firstUser and exists
> (select o1 from Order o1 where o1.user=u and exists(select o2 from Order o2
> where o2.user=:firstUser and o1.productCode=o2.productCode))}}
> generates the following SQL:
> {{SELECT t0.id, t0.email, t0.name FROM users t0 WHERE (t0.email = ? AND t0.id
> <> ? AND EXISTS (SELECT t1.id FROM orders t1, orders t3 WHERE (t1.user_id =
> t0.id AND EXISTS (SELECT t2.id FROM orders t2 WHERE (t2.user_id = ? AND
> t3.product_code = t2.product_code)}}
> Notice the superfluous join to “orders t3” which causes the whole query
> result to be wrong.
> When the query is modified to replace the second nested subquery with a join
> to
> {{select u from User u where u.email=:firstEmail and u<>:firstUser and exists
> (select o1 from Order o1, Order o2 where o1.user=u and o2.user=:firstUser and
> o1.productCode=o2.productCode)}}
> the generated SQL is:
> {{SELECT t0.id, t0.email, t0.name FROM users t0 WHERE (t0.email = ? AND t0.id
> <> ? AND EXISTS (SELECT t3.id FROM users t1 CROSS JOIN orders t2, orders t3
> WHERE (t3.user_id = t0.id AND t2.user_id = ? AND t3.product_code =
> t2.product_code)))}}
> which contains a strange construction of doing a cross join to „users t1“
> (which is completely unused later). Still, this seems to return the correct
> result, at least. (In my short testing; to be honest, I do not understand
> what exactly is this construction doing, and if its semantics is better,
> equal, or worse than not doing the cross join.) However, the unnecessary join
> does seem to affect performance.
> Finally, when I rewrote the query from the other side, to:
> {{select o from Order o join o.user u where u.email=:firstEmail and
> u<>:firstUser and o.productCode in (select o1.productCode from Order o1 where
> o1.user=:firstUser)}}
> The resulting SQL is:
> {{SELECT t0.id, t0.product_code, t3.id, t3.email, t3.name FROM orders t0
> INNER JOIN users t1 ON t0.user_id = t1.id LEFT OUTER JOIN users t3 ON
> t0.user_id = t3.id WHERE (t1.email = ? AND t0.user_id <> ? AND
> t0.product_code IN (SELECT t2.product_code FROM orders t2 WHERE (t2.user_id =
> ?)))}}
> Which generates correct results, even though it _still_ contains a
> superfluous outer join to „users t3“ (used only in the result projection)
> which is identical to the previous inner join, which again affects
> performance.
> A complete reproducible project is available [at my
> Github|https://github.com/mormegil-cz/openjpa-bug-repro].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2840) Enable a light SPI for asm support in kernel module
[ https://issues.apache.org/jira/browse/OPENJPA-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2840. - Resolution: Fixed > Enable a light SPI for asm support in kernel module > --- > > Key: OPENJPA-2840 > URL: https://issues.apache.org/jira/browse/OPENJPA-2840 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.3 > > > Goal is to be able to switch ASM version more easily than today. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2840) Enable a light SPI for asm support in kernel module
Romain Manni-Bucau created OPENJPA-2840: --- Summary: Enable a light SPI for asm support in kernel module Key: OPENJPA-2840 URL: https://issues.apache.org/jira/browse/OPENJPA-2840 Project: OpenJPA Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.3 Goal is to be able to switch ASM version more easily than today. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2838) Add a JUL LogFactory
[ https://issues.apache.org/jira/browse/OPENJPA-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2838. - Resolution: Fixed > Add a JUL LogFactory > > > Key: OPENJPA-2838 > URL: https://issues.apache.org/jira/browse/OPENJPA-2838 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2838) Add a JUL LogFactory
Romain Manni-Bucau created OPENJPA-2838: --- Summary: Add a JUL LogFactory Key: OPENJPA-2838 URL: https://issues.apache.org/jira/browse/OPENJPA-2838 Project: OpenJPA Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2834) Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
[
https://issues.apache.org/jira/browse/OPENJPA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208613#comment-17208613
]
Romain Manni-Bucau commented on OPENJPA-2834:
-
[~vishalduke] openjpa-all is there
[https://repository.apache.org/content/repositories/snapshots/org/apache/openjpa/openjpa-all/3.1.3-SNAPSHOT/]
(but it is rarely used in practise since javax.* and serp are generally
provided by other jars).
> Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
> ---
>
> Key: OPENJPA-2834
> URL: https://issues.apache.org/jira/browse/OPENJPA-2834
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.1
> Environment: Linux OS
> Oracle DB
>Reporter: Vishal
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 3.1.3
>
> Attachments: OneDrive_2020-09-18.zip,
> image-2020-10-06-13-34-07-912.png, jpa.log, redHatRecommendation.txt
>
>
> Hi Team
> We are facing Performance issue with OpenJPA-3.1.1 when we deploy our
> application in EAP 7.3 Server but similar issue is not replicated with
> Wildfly-10.1.0 server with same version.
> Below is reply from RED-HAT Team memeber we have received
> {color:#ff8b00}With the scope of WFLY-7075 (see [1]) the
> 'TransactionScopedEntityManager' implementation got updated to throw an error
> if a jta transaction already has an UNSYNCHRONIZED persistence context and a
> SYNCHRONIZED persistence context is requested. For this the implementation is
> using the 'EntityManagerFactory', see: ~~~ private static void
> testForMixedSynchronizationTypes(EntityManagerFactory emf, EntityManager
> entityManagerFromJTA, String scopedPuName, final SynchronizationType
> targetSynchronizationType, Map targetProperties) \{ boolean
> skipMixedSyncTypeChecking =
> Configuration.skipMixedSynchronizationTypeCheck(emf, targetProperties); //
> extension to allow skipping of check based on properties of target entity
> manager boolean allowJoinedUnsyncPersistenceContext =
> Configuration.allowJoinedUnsyncPersistenceContext(emf, targetProperties); //
> extension to allow joined unsync persistence context to be treated as sync
> persistence context ... } ~~~ Printing the stack in
> 'EntityManagerFactoryImpl.' shows: 11698 ragedesign INFO [default task-1]
> openjpa.Runtime -
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.getProperties(EntityManagerFactoryImpl.java:125)
> 11698 ragedesign INFO [default task-1] openjpa.Runtime -
> org.jboss.as.jpa.config.Configuration.skipMixedSynchronizationTypeCheck(Configuration.java:345)
> So, the code above calls 'EntityManagerFactoryImpl.getProperties(...)' from
> OpenJPA, see: ~~~ @Override public Map getProperties() \{
> Map props = _factory.getProperties(); // convert to user
> readable values props.putAll(createEntityManager().getProperties()); return
> props; } ~~~ As you can see this code is creating a new 'EntityManager'
> (createEntityManager()) on every invocation just to get the Properties. As
> mentioned in the beginning to resolve the issue for JBoss EAP 7.3 and Open
> JPA, you would need to fix this in Open JPA {color}
> {color:#172b4d}They have also shared link for Jira of JBOSS
> [https://issues.redhat.com/browse/WFLY-7075]{color}
>
> I am attaching Project and logs for reference.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2834) Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
[
https://issues.apache.org/jira/browse/OPENJPA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208062#comment-17208062
]
Romain Manni-Bucau commented on OPENJPA-2834:
-
Hi [~vishalduke],
I just redeployed the latest snapshot for you on
[https://repository.apache.org/content/repositories/snapshots/org/apache/openjpa/openjpa/3.1.3-SNAPSHOT/]
(ensure to take the higher last digit number, should be something like
openjpa-3.1.3-20201005.123820-9.jar currently). We started to discuss a release
some time ago but there were no urgence but we don't have any blocker AFAIK so
can be just a matter of relaunching the discussion on the dev list.
Romain
> Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
> ---
>
> Key: OPENJPA-2834
> URL: https://issues.apache.org/jira/browse/OPENJPA-2834
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.1
> Environment: Linux OS
> Oracle DB
>Reporter: Vishal
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 3.1.3
>
> Attachments: OneDrive_2020-09-18.zip, jpa.log,
> redHatRecommendation.txt
>
>
> Hi Team
> We are facing Performance issue with OpenJPA-3.1.1 when we deploy our
> application in EAP 7.3 Server but similar issue is not replicated with
> Wildfly-10.1.0 server with same version.
> Below is reply from RED-HAT Team memeber we have received
> {color:#ff8b00}With the scope of WFLY-7075 (see [1]) the
> 'TransactionScopedEntityManager' implementation got updated to throw an error
> if a jta transaction already has an UNSYNCHRONIZED persistence context and a
> SYNCHRONIZED persistence context is requested. For this the implementation is
> using the 'EntityManagerFactory', see: ~~~ private static void
> testForMixedSynchronizationTypes(EntityManagerFactory emf, EntityManager
> entityManagerFromJTA, String scopedPuName, final SynchronizationType
> targetSynchronizationType, Map targetProperties) \{ boolean
> skipMixedSyncTypeChecking =
> Configuration.skipMixedSynchronizationTypeCheck(emf, targetProperties); //
> extension to allow skipping of check based on properties of target entity
> manager boolean allowJoinedUnsyncPersistenceContext =
> Configuration.allowJoinedUnsyncPersistenceContext(emf, targetProperties); //
> extension to allow joined unsync persistence context to be treated as sync
> persistence context ... } ~~~ Printing the stack in
> 'EntityManagerFactoryImpl.' shows: 11698 ragedesign INFO [default task-1]
> openjpa.Runtime -
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.getProperties(EntityManagerFactoryImpl.java:125)
> 11698 ragedesign INFO [default task-1] openjpa.Runtime -
> org.jboss.as.jpa.config.Configuration.skipMixedSynchronizationTypeCheck(Configuration.java:345)
> So, the code above calls 'EntityManagerFactoryImpl.getProperties(...)' from
> OpenJPA, see: ~~~ @Override public Map getProperties() \{
> Map props = _factory.getProperties(); // convert to user
> readable values props.putAll(createEntityManager().getProperties()); return
> props; } ~~~ As you can see this code is creating a new 'EntityManager'
> (createEntityManager()) on every invocation just to get the Properties. As
> mentioned in the beginning to resolve the issue for JBoss EAP 7.3 and Open
> JPA, you would need to fix this in Open JPA {color}
> {color:#172b4d}They have also shared link for Jira of JBOSS
> [https://issues.redhat.com/browse/WFLY-7075]{color}
>
> I am attaching Project and logs for reference.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2834) Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
[
https://issues.apache.org/jira/browse/OPENJPA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205347#comment-17205347
]
Romain Manni-Bucau commented on OPENJPA-2834:
-
[~vishalduke] ok, get it. Current master skips synchronizeMappings which is the
main slowness of getting an entity manager if enabled + EMF properties are
cached once obtained so you should only see some startup overhead but not at
runtime.
> Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
> ---
>
> Key: OPENJPA-2834
> URL: https://issues.apache.org/jira/browse/OPENJPA-2834
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.1
> Environment: Linux OS
> Oracle DB
>Reporter: Vishal
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 3.1.3
>
> Attachments: OneDrive_2020-09-18.zip, jpa.log,
> redHatRecommendation.txt
>
>
> Hi Team
> We are facing Performance issue with OpenJPA-3.1.1 when we deploy our
> application in EAP 7.3 Server but similar issue is not replicated with
> Wildfly-10.1.0 server with same version.
> Below is reply from RED-HAT Team memeber we have received
> {color:#ff8b00}With the scope of WFLY-7075 (see [1]) the
> 'TransactionScopedEntityManager' implementation got updated to throw an error
> if a jta transaction already has an UNSYNCHRONIZED persistence context and a
> SYNCHRONIZED persistence context is requested. For this the implementation is
> using the 'EntityManagerFactory', see: ~~~ private static void
> testForMixedSynchronizationTypes(EntityManagerFactory emf, EntityManager
> entityManagerFromJTA, String scopedPuName, final SynchronizationType
> targetSynchronizationType, Map targetProperties) \{ boolean
> skipMixedSyncTypeChecking =
> Configuration.skipMixedSynchronizationTypeCheck(emf, targetProperties); //
> extension to allow skipping of check based on properties of target entity
> manager boolean allowJoinedUnsyncPersistenceContext =
> Configuration.allowJoinedUnsyncPersistenceContext(emf, targetProperties); //
> extension to allow joined unsync persistence context to be treated as sync
> persistence context ... } ~~~ Printing the stack in
> 'EntityManagerFactoryImpl.' shows: 11698 ragedesign INFO [default task-1]
> openjpa.Runtime -
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.getProperties(EntityManagerFactoryImpl.java:125)
> 11698 ragedesign INFO [default task-1] openjpa.Runtime -
> org.jboss.as.jpa.config.Configuration.skipMixedSynchronizationTypeCheck(Configuration.java:345)
> So, the code above calls 'EntityManagerFactoryImpl.getProperties(...)' from
> OpenJPA, see: ~~~ @Override public Map getProperties() \{
> Map props = _factory.getProperties(); // convert to user
> readable values props.putAll(createEntityManager().getProperties()); return
> props; } ~~~ As you can see this code is creating a new 'EntityManager'
> (createEntityManager()) on every invocation just to get the Properties. As
> mentioned in the beginning to resolve the issue for JBoss EAP 7.3 and Open
> JPA, you would need to fix this in Open JPA {color}
> {color:#172b4d}They have also shared link for Jira of JBOSS
> [https://issues.redhat.com/browse/WFLY-7075]{color}
>
> I am attaching Project and logs for reference.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2834) Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
[
https://issues.apache.org/jira/browse/OPENJPA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205313#comment-17205313
]
Romain Manni-Bucau commented on OPENJPA-2834:
-
[~vishalduke] you mean you create the DB with JPA in your case? Is it a "test"
case and not a prod one? (it is unlikely it happens in prod so I'm a bit
surprised)
> Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
> ---
>
> Key: OPENJPA-2834
> URL: https://issues.apache.org/jira/browse/OPENJPA-2834
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.1
> Environment: Linux OS
> Oracle DB
>Reporter: Vishal
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 3.1.3
>
> Attachments: OneDrive_2020-09-18.zip, redHatRecommendation.txt
>
>
> Hi Team
> We are facing Performance issue with OpenJPA-3.1.1 when we deploy our
> application in EAP 7.3 Server but similar issue is not replicated with
> Wildfly-10.1.0 server with same version.
> Below is reply from RED-HAT Team memeber we have received
> {color:#ff8b00}With the scope of WFLY-7075 (see [1]) the
> 'TransactionScopedEntityManager' implementation got updated to throw an error
> if a jta transaction already has an UNSYNCHRONIZED persistence context and a
> SYNCHRONIZED persistence context is requested. For this the implementation is
> using the 'EntityManagerFactory', see: ~~~ private static void
> testForMixedSynchronizationTypes(EntityManagerFactory emf, EntityManager
> entityManagerFromJTA, String scopedPuName, final SynchronizationType
> targetSynchronizationType, Map targetProperties) \{ boolean
> skipMixedSyncTypeChecking =
> Configuration.skipMixedSynchronizationTypeCheck(emf, targetProperties); //
> extension to allow skipping of check based on properties of target entity
> manager boolean allowJoinedUnsyncPersistenceContext =
> Configuration.allowJoinedUnsyncPersistenceContext(emf, targetProperties); //
> extension to allow joined unsync persistence context to be treated as sync
> persistence context ... } ~~~ Printing the stack in
> 'EntityManagerFactoryImpl.' shows: 11698 ragedesign INFO [default task-1]
> openjpa.Runtime -
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.getProperties(EntityManagerFactoryImpl.java:125)
> 11698 ragedesign INFO [default task-1] openjpa.Runtime -
> org.jboss.as.jpa.config.Configuration.skipMixedSynchronizationTypeCheck(Configuration.java:345)
> So, the code above calls 'EntityManagerFactoryImpl.getProperties(...)' from
> OpenJPA, see: ~~~ @Override public Map getProperties() \{
> Map props = _factory.getProperties(); // convert to user
> readable values props.putAll(createEntityManager().getProperties()); return
> props; } ~~~ As you can see this code is creating a new 'EntityManager'
> (createEntityManager()) on every invocation just to get the Properties. As
> mentioned in the beginning to resolve the issue for JBoss EAP 7.3 and Open
> JPA, you would need to fix this in Open JPA {color}
> {color:#172b4d}They have also shared link for Jira of JBOSS
> [https://issues.redhat.com/browse/WFLY-7075]{color}
>
> I am attaching Project and logs for reference.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2834) Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
[
https://issues.apache.org/jira/browse/OPENJPA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204962#comment-17204962
]
Romain Manni-Bucau commented on OPENJPA-2834:
-
[~vishalduke] just clone the project and run "mvn clean install -DskipTests
-Dinvoker.skip=true", should be a few minutes long.
> Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
> ---
>
> Key: OPENJPA-2834
> URL: https://issues.apache.org/jira/browse/OPENJPA-2834
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.1
> Environment: Linux OS
> Oracle DB
>Reporter: Vishal
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 3.1.3
>
> Attachments: OneDrive_2020-09-18.zip
>
>
> Hi Team
> We are facing Performance issue with OpenJPA-3.1.1 when we deploy our
> application in EAP 7.3 Server but similar issue is not replicated with
> Wildfly-10.1.0 server with same version.
> Below is reply from RED-HAT Team memeber we have received
> {color:#ff8b00}With the scope of WFLY-7075 (see [1]) the
> 'TransactionScopedEntityManager' implementation got updated to throw an error
> if a jta transaction already has an UNSYNCHRONIZED persistence context and a
> SYNCHRONIZED persistence context is requested. For this the implementation is
> using the 'EntityManagerFactory', see: ~~~ private static void
> testForMixedSynchronizationTypes(EntityManagerFactory emf, EntityManager
> entityManagerFromJTA, String scopedPuName, final SynchronizationType
> targetSynchronizationType, Map targetProperties) \{ boolean
> skipMixedSyncTypeChecking =
> Configuration.skipMixedSynchronizationTypeCheck(emf, targetProperties); //
> extension to allow skipping of check based on properties of target entity
> manager boolean allowJoinedUnsyncPersistenceContext =
> Configuration.allowJoinedUnsyncPersistenceContext(emf, targetProperties); //
> extension to allow joined unsync persistence context to be treated as sync
> persistence context ... } ~~~ Printing the stack in
> 'EntityManagerFactoryImpl.' shows: 11698 ragedesign INFO [default task-1]
> openjpa.Runtime -
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.getProperties(EntityManagerFactoryImpl.java:125)
> 11698 ragedesign INFO [default task-1] openjpa.Runtime -
> org.jboss.as.jpa.config.Configuration.skipMixedSynchronizationTypeCheck(Configuration.java:345)
> So, the code above calls 'EntityManagerFactoryImpl.getProperties(...)' from
> OpenJPA, see: ~~~ @Override public Map getProperties() \{
> Map props = _factory.getProperties(); // convert to user
> readable values props.putAll(createEntityManager().getProperties()); return
> props; } ~~~ As you can see this code is creating a new 'EntityManager'
> (createEntityManager()) on every invocation just to get the Properties. As
> mentioned in the beginning to resolve the issue for JBoss EAP 7.3 and Open
> JPA, you would need to fix this in Open JPA {color}
> {color:#172b4d}They have also shared link for Jira of JBOSS
> [https://issues.redhat.com/browse/WFLY-7075]{color}
>
> I am attaching Project and logs for reference.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2834) Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
[
https://issues.apache.org/jira/browse/OPENJPA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204657#comment-17204657
]
Romain Manni-Bucau commented on OPENJPA-2834:
-
Hi [~vishalduke], you can build it from [https://github.com/apache/openjpa]
> Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
> ---
>
> Key: OPENJPA-2834
> URL: https://issues.apache.org/jira/browse/OPENJPA-2834
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.1
> Environment: Linux OS
> Oracle DB
>Reporter: Vishal
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 3.1.3
>
> Attachments: OneDrive_2020-09-18.zip
>
>
> Hi Team
> We are facing Performance issue with OpenJPA-3.1.1 when we deploy our
> application in EAP 7.3 Server but similar issue is not replicated with
> Wildfly-10.1.0 server with same version.
> Below is reply from RED-HAT Team memeber we have received
> {color:#ff8b00}With the scope of WFLY-7075 (see [1]) the
> 'TransactionScopedEntityManager' implementation got updated to throw an error
> if a jta transaction already has an UNSYNCHRONIZED persistence context and a
> SYNCHRONIZED persistence context is requested. For this the implementation is
> using the 'EntityManagerFactory', see: ~~~ private static void
> testForMixedSynchronizationTypes(EntityManagerFactory emf, EntityManager
> entityManagerFromJTA, String scopedPuName, final SynchronizationType
> targetSynchronizationType, Map targetProperties) \{ boolean
> skipMixedSyncTypeChecking =
> Configuration.skipMixedSynchronizationTypeCheck(emf, targetProperties); //
> extension to allow skipping of check based on properties of target entity
> manager boolean allowJoinedUnsyncPersistenceContext =
> Configuration.allowJoinedUnsyncPersistenceContext(emf, targetProperties); //
> extension to allow joined unsync persistence context to be treated as sync
> persistence context ... } ~~~ Printing the stack in
> 'EntityManagerFactoryImpl.' shows: 11698 ragedesign INFO [default task-1]
> openjpa.Runtime -
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.getProperties(EntityManagerFactoryImpl.java:125)
> 11698 ragedesign INFO [default task-1] openjpa.Runtime -
> org.jboss.as.jpa.config.Configuration.skipMixedSynchronizationTypeCheck(Configuration.java:345)
> So, the code above calls 'EntityManagerFactoryImpl.getProperties(...)' from
> OpenJPA, see: ~~~ @Override public Map getProperties() \{
> Map props = _factory.getProperties(); // convert to user
> readable values props.putAll(createEntityManager().getProperties()); return
> props; } ~~~ As you can see this code is creating a new 'EntityManager'
> (createEntityManager()) on every invocation just to get the Properties. As
> mentioned in the beginning to resolve the issue for JBoss EAP 7.3 and Open
> JPA, you would need to fix this in Open JPA {color}
> {color:#172b4d}They have also shared link for Jira of JBOSS
> [https://issues.redhat.com/browse/WFLY-7075]{color}
>
> I am attaching Project and logs for reference.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2832) DROP COLUMN does not use delimiters and always add double quotes
[ https://issues.apache.org/jira/browse/OPENJPA-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2832. - Fix Version/s: 3.1.3 Resolution: Fixed > DROP COLUMN does not use delimiters and always add double quotes > > > Key: OPENJPA-2832 > URL: https://issues.apache.org/jira/browse/OPENJPA-2832 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Reporter: Enrico Olivelli >Priority: Blocker > Fix For: 3.1.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2820) Track when a DBIdentifier is already delimited in order to save memory allocations and cpu
[ https://issues.apache.org/jira/browse/OPENJPA-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2820. - Fix Version/s: 3.1.3 Resolution: Fixed > Track when a DBIdentifier is already delimited in order to save memory > allocations and cpu > -- > > Key: OPENJPA-2820 > URL: https://issues.apache.org/jira/browse/OPENJPA-2820 > Project: OpenJPA > Issue Type: Improvement > Components: performance >Affects Versions: 3.1.3 >Reporter: Enrico Olivelli >Priority: Major > Fix For: 3.1.3 > > > During the development of [https://github.com/apache/openjpa/pull/69/files] > [~rmannibucau] suggested to keep track of the fact that a DBIdentifier > contains a name that has been already delimited, this way operations like > "removeDelimiters" can be no-op. > > This flag can be set during the creation of a DBIdentifier by the > DBDictionary, basically when the DBIdentifier forces delimitAll=true > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2834) Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
[
https://issues.apache.org/jira/browse/OPENJPA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau resolved OPENJPA-2834.
-
Assignee: Romain Manni-Bucau
Resolution: Fixed
> Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
> ---
>
> Key: OPENJPA-2834
> URL: https://issues.apache.org/jira/browse/OPENJPA-2834
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.1
> Environment: Linux OS
> Oracle DB
>Reporter: Vishal
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 3.1.3
>
> Attachments: OneDrive_2020-09-18.zip
>
>
> Hi Team
> We are facing Performance issue with OpenJPA-3.1.1 when we deploy our
> application in EAP 7.3 Server but similar issue is not replicated with
> Wildfly-10.1.0 server with same version.
> Below is reply from RED-HAT Team memeber we have received
> Link : https://access.redhat.com/support/cases/#/case/02725637
> {color:#ff8b00}With the scope of WFLY-7075 (see [1]) the
> 'TransactionScopedEntityManager' implementation got updated to throw an error
> if a jta transaction already has an UNSYNCHRONIZED persistence context and a
> SYNCHRONIZED persistence context is requested. For this the implementation is
> using the 'EntityManagerFactory', see: ~~~ private static void
> testForMixedSynchronizationTypes(EntityManagerFactory emf, EntityManager
> entityManagerFromJTA, String scopedPuName, final SynchronizationType
> targetSynchronizationType, Map targetProperties) \{ boolean
> skipMixedSyncTypeChecking =
> Configuration.skipMixedSynchronizationTypeCheck(emf, targetProperties); //
> extension to allow skipping of check based on properties of target entity
> manager boolean allowJoinedUnsyncPersistenceContext =
> Configuration.allowJoinedUnsyncPersistenceContext(emf, targetProperties); //
> extension to allow joined unsync persistence context to be treated as sync
> persistence context ... } ~~~ Printing the stack in
> 'EntityManagerFactoryImpl.' shows: 11698 ragedesign INFO [default task-1]
> openjpa.Runtime -
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.getProperties(EntityManagerFactoryImpl.java:125)
> 11698 ragedesign INFO [default task-1] openjpa.Runtime -
> org.jboss.as.jpa.config.Configuration.skipMixedSynchronizationTypeCheck(Configuration.java:345)
> So, the code above calls 'EntityManagerFactoryImpl.getProperties(...)' from
> OpenJPA, see: ~~~ @Override public Map getProperties() \{
> Map props = _factory.getProperties(); // convert to user
> readable values props.putAll(createEntityManager().getProperties()); return
> props; } ~~~ As you can see this code is creating a new 'EntityManager'
> (createEntityManager()) on every invocation just to get the Properties. As
> mentioned in the beginning to resolve the issue for JBoss EAP 7.3 and Open
> JPA, you would need to fix this in Open JPA {color}
> {color:#172b4d}They have also shared link for Jira of JBOSS
> [https://issues.redhat.com/browse/WFLY-7075]
> {color}
>
> I am attaching Project and logs for reference.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OPENJPA-2834) Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
[
https://issues.apache.org/jira/browse/OPENJPA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated OPENJPA-2834:
Summary: Performance issue while deploying in Wildfly EAP with
OpenJPA-3.1.1 (was: Performance issue while deploying in EAP with
OpenJPA-3.1.1)
> Performance issue while deploying in Wildfly EAP with OpenJPA-3.1.1
> ---
>
> Key: OPENJPA-2834
> URL: https://issues.apache.org/jira/browse/OPENJPA-2834
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.1
> Environment: Linux OS
> Oracle DB
>Reporter: Vishal
>Priority: Major
> Fix For: 3.1.3
>
> Attachments: OneDrive_2020-09-18.zip
>
>
> Hi Team
> We are facing Performance issue with OpenJPA-3.1.1 when we deploy our
> application in EAP 7.3 Server but similar issue is not replicated with
> Wildfly-10.1.0 server with same version.
> Below is reply from RED-HAT Team memeber we have received
> Link : https://access.redhat.com/support/cases/#/case/02725637
> {color:#ff8b00}With the scope of WFLY-7075 (see [1]) the
> 'TransactionScopedEntityManager' implementation got updated to throw an error
> if a jta transaction already has an UNSYNCHRONIZED persistence context and a
> SYNCHRONIZED persistence context is requested. For this the implementation is
> using the 'EntityManagerFactory', see: ~~~ private static void
> testForMixedSynchronizationTypes(EntityManagerFactory emf, EntityManager
> entityManagerFromJTA, String scopedPuName, final SynchronizationType
> targetSynchronizationType, Map targetProperties) \{ boolean
> skipMixedSyncTypeChecking =
> Configuration.skipMixedSynchronizationTypeCheck(emf, targetProperties); //
> extension to allow skipping of check based on properties of target entity
> manager boolean allowJoinedUnsyncPersistenceContext =
> Configuration.allowJoinedUnsyncPersistenceContext(emf, targetProperties); //
> extension to allow joined unsync persistence context to be treated as sync
> persistence context ... } ~~~ Printing the stack in
> 'EntityManagerFactoryImpl.' shows: 11698 ragedesign INFO [default task-1]
> openjpa.Runtime -
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.getProperties(EntityManagerFactoryImpl.java:125)
> 11698 ragedesign INFO [default task-1] openjpa.Runtime -
> org.jboss.as.jpa.config.Configuration.skipMixedSynchronizationTypeCheck(Configuration.java:345)
> So, the code above calls 'EntityManagerFactoryImpl.getProperties(...)' from
> OpenJPA, see: ~~~ @Override public Map getProperties() \{
> Map props = _factory.getProperties(); // convert to user
> readable values props.putAll(createEntityManager().getProperties()); return
> props; } ~~~ As you can see this code is creating a new 'EntityManager'
> (createEntityManager()) on every invocation just to get the Properties. As
> mentioned in the beginning to resolve the issue for JBoss EAP 7.3 and Open
> JPA, you would need to fix this in Open JPA {color}
> {color:#172b4d}They have also shared link for Jira of JBOSS
> [https://issues.redhat.com/browse/WFLY-7075]
> {color}
>
> I am attaching Project and logs for reference.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OPENJPA-2834) Performance issue while deploying in EAP with OpenJPA-3.1.1
[
https://issues.apache.org/jira/browse/OPENJPA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated OPENJPA-2834:
Fix Version/s: 3.1.3
> Performance issue while deploying in EAP with OpenJPA-3.1.1
> ---
>
> Key: OPENJPA-2834
> URL: https://issues.apache.org/jira/browse/OPENJPA-2834
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.1
> Environment: Linux OS
> Oracle DB
>Reporter: Vishal
>Priority: Major
> Fix For: 3.1.3
>
> Attachments: OneDrive_2020-09-18.zip
>
>
> Hi Team
> We are facing Performance issue with OpenJPA-3.1.1 when we deploy our
> application in EAP 7.3 Server but similar issue is not replicated with
> Wildfly-10.1.0 server with same version.
> Below is reply from RED-HAT Team memeber we have received
> Link : https://access.redhat.com/support/cases/#/case/02725637
> {color:#ff8b00}With the scope of WFLY-7075 (see [1]) the
> 'TransactionScopedEntityManager' implementation got updated to throw an error
> if a jta transaction already has an UNSYNCHRONIZED persistence context and a
> SYNCHRONIZED persistence context is requested. For this the implementation is
> using the 'EntityManagerFactory', see: ~~~ private static void
> testForMixedSynchronizationTypes(EntityManagerFactory emf, EntityManager
> entityManagerFromJTA, String scopedPuName, final SynchronizationType
> targetSynchronizationType, Map targetProperties) \{ boolean
> skipMixedSyncTypeChecking =
> Configuration.skipMixedSynchronizationTypeCheck(emf, targetProperties); //
> extension to allow skipping of check based on properties of target entity
> manager boolean allowJoinedUnsyncPersistenceContext =
> Configuration.allowJoinedUnsyncPersistenceContext(emf, targetProperties); //
> extension to allow joined unsync persistence context to be treated as sync
> persistence context ... } ~~~ Printing the stack in
> 'EntityManagerFactoryImpl.' shows: 11698 ragedesign INFO [default task-1]
> openjpa.Runtime -
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.getProperties(EntityManagerFactoryImpl.java:125)
> 11698 ragedesign INFO [default task-1] openjpa.Runtime -
> org.jboss.as.jpa.config.Configuration.skipMixedSynchronizationTypeCheck(Configuration.java:345)
> So, the code above calls 'EntityManagerFactoryImpl.getProperties(...)' from
> OpenJPA, see: ~~~ @Override public Map getProperties() \{
> Map props = _factory.getProperties(); // convert to user
> readable values props.putAll(createEntityManager().getProperties()); return
> props; } ~~~ As you can see this code is creating a new 'EntityManager'
> (createEntityManager()) on every invocation just to get the Properties. As
> mentioned in the beginning to resolve the issue for JBoss EAP 7.3 and Open
> JPA, you would need to fix this in Open JPA {color}
> {color:#172b4d}They have also shared link for Jira of JBOSS
> [https://issues.redhat.com/browse/WFLY-7075]
> {color}
>
> I am attaching Project and logs for reference.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2834) Performance issue while deploying in EAP with OpenJPA-3.1.1
[
https://issues.apache.org/jira/browse/OPENJPA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204618#comment-17204618
]
Romain Manni-Bucau commented on OPENJPA-2834:
-
Hi [~vishalduke], will male it hurtless but wildfly should check it once per
entity manager factory too, they don't have to assume anything about the
implementation so guess they still have some fix to do on their side anyway.
BTW we can't read the link you shared (no permission it seems).
> Performance issue while deploying in EAP with OpenJPA-3.1.1
> ---
>
> Key: OPENJPA-2834
> URL: https://issues.apache.org/jira/browse/OPENJPA-2834
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.1
> Environment: Linux OS
> Oracle DB
>Reporter: Vishal
>Priority: Major
> Attachments: OneDrive_2020-09-18.zip
>
>
> Hi Team
> We are facing Performance issue with OpenJPA-3.1.1 when we deploy our
> application in EAP 7.3 Server but similar issue is not replicated with
> Wildfly-10.1.0 server with same version.
> Below is reply from RED-HAT Team memeber we have received
> Link : https://access.redhat.com/support/cases/#/case/02725637
> {color:#ff8b00}With the scope of WFLY-7075 (see [1]) the
> 'TransactionScopedEntityManager' implementation got updated to throw an error
> if a jta transaction already has an UNSYNCHRONIZED persistence context and a
> SYNCHRONIZED persistence context is requested. For this the implementation is
> using the 'EntityManagerFactory', see: ~~~ private static void
> testForMixedSynchronizationTypes(EntityManagerFactory emf, EntityManager
> entityManagerFromJTA, String scopedPuName, final SynchronizationType
> targetSynchronizationType, Map targetProperties) \{ boolean
> skipMixedSyncTypeChecking =
> Configuration.skipMixedSynchronizationTypeCheck(emf, targetProperties); //
> extension to allow skipping of check based on properties of target entity
> manager boolean allowJoinedUnsyncPersistenceContext =
> Configuration.allowJoinedUnsyncPersistenceContext(emf, targetProperties); //
> extension to allow joined unsync persistence context to be treated as sync
> persistence context ... } ~~~ Printing the stack in
> 'EntityManagerFactoryImpl.' shows: 11698 ragedesign INFO [default task-1]
> openjpa.Runtime -
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.getProperties(EntityManagerFactoryImpl.java:125)
> 11698 ragedesign INFO [default task-1] openjpa.Runtime -
> org.jboss.as.jpa.config.Configuration.skipMixedSynchronizationTypeCheck(Configuration.java:345)
> So, the code above calls 'EntityManagerFactoryImpl.getProperties(...)' from
> OpenJPA, see: ~~~ @Override public Map getProperties() \{
> Map props = _factory.getProperties(); // convert to user
> readable values props.putAll(createEntityManager().getProperties()); return
> props; } ~~~ As you can see this code is creating a new 'EntityManager'
> (createEntityManager()) on every invocation just to get the Properties. As
> mentioned in the beginning to resolve the issue for JBoss EAP 7.3 and Open
> JPA, you would need to fix this in Open JPA {color}
> {color:#172b4d}They have also shared link for Jira of JBOSS
> [https://issues.redhat.com/browse/WFLY-7075]
> {color}
>
> I am attaching Project and logs for reference.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2833) Upgrade to ASM 9
Romain Manni-Bucau created OPENJPA-2833: --- Summary: Upgrade to ASM 9 Key: OPENJPA-2833 URL: https://issues.apache.org/jira/browse/OPENJPA-2833 Project: OpenJPA Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2833) Upgrade to ASM 9
[ https://issues.apache.org/jira/browse/OPENJPA-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2833. - Resolution: Fixed > Upgrade to ASM 9 > > > Key: OPENJPA-2833 > URL: https://issues.apache.org/jira/browse/OPENJPA-2833 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2831) Import commons-collections4 classes instead of the dependency in openjpa-lib
[ https://issues.apache.org/jira/browse/OPENJPA-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2831. - Resolution: Fixed > Import commons-collections4 classes instead of the dependency in openjpa-lib > > > Key: OPENJPA-2831 > URL: https://issues.apache.org/jira/browse/OPENJPA-2831 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.3 > > > First step of cleaning up our [collections4] usage. > This iteration will drop the dependency, then we can clean up the code to > reduce its scope to our limited usage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2831) Import commons-collections4 classes instead of the dependency in openjpa-lib
Romain Manni-Bucau created OPENJPA-2831: --- Summary: Import commons-collections4 classes instead of the dependency in openjpa-lib Key: OPENJPA-2831 URL: https://issues.apache.org/jira/browse/OPENJPA-2831 Project: OpenJPA Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.3 First step of cleaning up our [collections4] usage. This iteration will drop the dependency, then we can clean up the code to reduce its scope to our limited usage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2830) javax.persistence.sql-load-script-source does not support ";" in strings
[ https://issues.apache.org/jira/browse/OPENJPA-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2830. - Resolution: Fixed > javax.persistence.sql-load-script-source does not support ";" in strings > > > Key: OPENJPA-2830 > URL: https://issues.apache.org/jira/browse/OPENJPA-2830 > Project: OpenJPA > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.3 > > > Currently any content after ";" is dropped, we should just drop an ending sql > statement with ";" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2830) javax.persistence.sql-load-script-source does not support ";" in strings
Romain Manni-Bucau created OPENJPA-2830: --- Summary: javax.persistence.sql-load-script-source does not support ";" in strings Key: OPENJPA-2830 URL: https://issues.apache.org/jira/browse/OPENJPA-2830 Project: OpenJPA Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.3 Currently any content after ";" is dropped, we should just drop an ending sql statement with ";" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2829) javax script execution does not ignore empty lines
Romain Manni-Bucau created OPENJPA-2829: --- Summary: javax script execution does not ignore empty lines Key: OPENJPA-2829 URL: https://issues.apache.org/jira/browse/OPENJPA-2829 Project: OpenJPA Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2829) javax script execution does not ignore empty lines
[ https://issues.apache.org/jira/browse/OPENJPA-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2829. - Resolution: Fixed > javax script execution does not ignore empty lines > -- > > Key: OPENJPA-2829 > URL: https://issues.apache.org/jira/browse/OPENJPA-2829 > Project: OpenJPA > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2825) JPQL does not support well join on collection tables
Romain Manni-Bucau created OPENJPA-2825:
---
Summary: JPQL does not support well join on collection tables
Key: OPENJPA-2825
URL: https://issues.apache.org/jira/browse/OPENJPA-2825
Project: OpenJPA
Issue Type: Bug
Affects Versions: 3.1.2
Reporter: Romain Manni-Bucau
Valid JPQL ex:
{code:java}
select distinct e from MyEntity e join e.collectionTable c where c in
:potentialValues {code}
Note: using criteriabuilder the query is well executed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2824) When @OpenJPASupport (junit5 extension) is used, ensure to not do auto enhancement more than once
[ https://issues.apache.org/jira/browse/OPENJPA-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2824. - Resolution: Fixed > When @OpenJPASupport (junit5 extension) is used, ensure to not do auto > enhancement more than once > - > > Key: OPENJPA-2824 > URL: https://issues.apache.org/jira/browse/OPENJPA-2824 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2824) When @OpenJPASupport (junit5 extension) is used, ensure to not do auto enhancement more than once
Romain Manni-Bucau created OPENJPA-2824: --- Summary: When @OpenJPASupport (junit5 extension) is used, ensure to not do auto enhancement more than once Key: OPENJPA-2824 URL: https://issues.apache.org/jira/browse/OPENJPA-2824 Project: OpenJPA Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2819) Add simple GitHub Actions validation for Pull Requests
[ https://issues.apache.org/jira/browse/OPENJPA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2819. - Resolution: Fixed Thanks a lot Enrico, merged! > Add simple GitHub Actions validation for Pull Requests > -- > > Key: OPENJPA-2819 > URL: https://issues.apache.org/jira/browse/OPENJPA-2819 > Project: OpenJPA > Issue Type: Task > Components: build / infrastructure >Affects Versions: 3.1.1 >Reporter: Enrico Olivelli >Priority: Minor > Fix For: 3.1.3 > > > As discussed on the ML having a validation of Pull Requests will ease the > life of contributors and committers. > This task will introduce a simple "mvn install" on JDK8 on Linux on GitHub > actions -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (OPENJPA-2817) OpenJPA enhancer needs improved reentrancy
[ https://issues.apache.org/jira/browse/OPENJPA-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau reopened OPENJPA-2817: - reopening for 3.1.3 which likely needs to drop _transforming as well - once we have the actual cause of this issue (current analyzis suspects an OpenLiberty classloading bug but we didn't get something concrete yet). > OpenJPA enhancer needs improved reentrancy > -- > > Key: OPENJPA-2817 > URL: https://issues.apache.org/jira/browse/OPENJPA-2817 > Project: OpenJPA > Issue Type: Bug > Components: Enhance >Affects Versions: 2.2.2, 2.3.0, 2.4.3, 3.1.1 >Reporter: Jody Grassel >Assignee: Jody Grassel >Priority: Major > Fix For: 2.2.3 > > > OpenJPA's class transformer was designed in a time when ClassLoader access > was synchronized. Because it was assumed that if the ClassLoader caused > another class to load while it was already enhancing a class, causing another > triggering of the class transformer, it was assumed that that could only > happen if OpenJPA was bundled as part of the application (loaded by the app > classloader in an EE environment), and was safe to assume that this reentrant > invocation would not be a request to enhance a persistent type, and thus > return null (no enhancement needed). > With Java 7+, ClassLoader locking has been changed > ([https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html]). > Now, because the same ClassLoader (and thus same transformer), can be invoked > concurrently by different threads, this assumption was no longer valid. > OpenJPA needs to be updated to be mindful of reentrancy on a thread scope, > instead of just simply reacting to reentrancy whenever it happens. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OPENJPA-2817) OpenJPA enhancer needs improved reentrancy
[ https://issues.apache.org/jira/browse/OPENJPA-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17156940#comment-17156940 ] Romain Manni-Bucau edited comment on OPENJPA-2817 at 7/13/20, 7:54 PM: --- reopening for 3.1.3 which likely needs to drop _transforming as well - once we have the actual cause of this issue (current analyzis suspects an OpenLiberty classloading bug but we didn't get something concrete yet). But in any case the boolean of master but drop or be reworked. was (Author: romain.manni-bucau): reopening for 3.1.3 which likely needs to drop _transforming as well - once we have the actual cause of this issue (current analyzis suspects an OpenLiberty classloading bug but we didn't get something concrete yet). > OpenJPA enhancer needs improved reentrancy > -- > > Key: OPENJPA-2817 > URL: https://issues.apache.org/jira/browse/OPENJPA-2817 > Project: OpenJPA > Issue Type: Bug > Components: Enhance >Affects Versions: 2.2.2, 2.3.0, 2.4.3, 3.1.1 >Reporter: Jody Grassel >Assignee: Jody Grassel >Priority: Major > Fix For: 2.2.3 > > > OpenJPA's class transformer was designed in a time when ClassLoader access > was synchronized. Because it was assumed that if the ClassLoader caused > another class to load while it was already enhancing a class, causing another > triggering of the class transformer, it was assumed that that could only > happen if OpenJPA was bundled as part of the application (loaded by the app > classloader in an EE environment), and was safe to assume that this reentrant > invocation would not be a request to enhance a persistent type, and thus > return null (no enhancement needed). > With Java 7+, ClassLoader locking has been changed > ([https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html]). > Now, because the same ClassLoader (and thus same transformer), can be invoked > concurrently by different threads, this assumption was no longer valid. > OpenJPA needs to be updated to be mindful of reentrancy on a thread scope, > instead of just simply reacting to reentrancy whenever it happens. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2816) Add HerdDB DBDictionary
[ https://issues.apache.org/jira/browse/OPENJPA-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2816. - Resolution: Fixed Merged, thanks a lot Enrico! > Add HerdDB DBDictionary > --- > > Key: OPENJPA-2816 > URL: https://issues.apache.org/jira/browse/OPENJPA-2816 > Project: OpenJPA > Issue Type: New Feature > Components: third-party >Reporter: Enrico Olivelli >Priority: Major > Fix For: 3.1.3 > > > I would like to contribute to OpenJPA a DBDictionary for HerdDB database > [https://github.com/diennea/herddb > ]HerdDB is an embedded database designed to run in production with builtin > replication. > It is based on Apache Calcite, Apache BookKeeper and Apache ZooKeeper > Basically it is this file: > [https://github.com/diennea/herddb/blob/master/herddb-thirdparty/openjpa/src/main/java/herddb/openjpa/DBDictionary.java] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OPENJPA-2816) Add HerdDB DBDictionary
[ https://issues.apache.org/jira/browse/OPENJPA-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENJPA-2816: Fix Version/s: 3.1.3 > Add HerdDB DBDictionary > --- > > Key: OPENJPA-2816 > URL: https://issues.apache.org/jira/browse/OPENJPA-2816 > Project: OpenJPA > Issue Type: New Feature > Components: third-party >Reporter: Enrico Olivelli >Priority: Major > Fix For: 3.1.3 > > > I would like to contribute to OpenJPA a DBDictionary for HerdDB database > [https://github.com/diennea/herddb > ]HerdDB is an embedded database designed to run in production with builtin > replication. > It is based on Apache Calcite, Apache BookKeeper and Apache ZooKeeper > Basically it is this file: > [https://github.com/diennea/herddb/blob/master/herddb-thirdparty/openjpa/src/main/java/herddb/openjpa/DBDictionary.java] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OPENJPA-2778) Error on Oracle LOB handling
[
https://issues.apache.org/jira/browse/OPENJPA-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130468#comment-17130468
]
Romain Manni-Bucau edited comment on OPENJPA-2778 at 6/10/20, 10:00 AM:
Hi,
Oracle created docker images with its database, any hope you reproduce it in a
docker-compose you can share with us (using openjpa 3.1.1)?
Romain
was (Author: romain.manni-bucau):
Hi,
Oracle create docker images with its database, any hope you reproduce it in a
docker-compose you can share with us (using openjpa 3.1.1)?
Romain
> Error on Oracle LOB handling
>
>
> Key: OPENJPA-2778
> URL: https://issues.apache.org/jira/browse/OPENJPA-2778
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, jpa
>Affects Versions: 2.1.0, 2.2.0, 2.4.0, 2.4.3, 3.0.0
>Reporter: Juri Berlanda
>Assignee: Mark Struberg
>Priority: Major
> Attachments: openjpa-2778.log, test.log
>
>
> I get the following error
> {{ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB
> column}}
> on one of our queries.
> The Entity I am trying to write is relatively complicated (includes @Embedded
> and inheritance), but for legal reasons I am not allowed to disclose the code.
> What seems to happen is, that the not all CLOB columns are updated at the end
> of the update statement.
> From logs I see:
> {{databaseProductName: Oracle}}
> {{databaseProductVersion: Oracle Database 12c Enterprise Edition Release
> 12.1.0.2.0 - 64bit Production}}
> {{Using dictionary class "org.apache.openjpa.jdbc.sql.OracleDictionary"
> (Oracle Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit
> Production}}
> I reproduced the bug using all of Oracle driver 12.1.0.2, 12.2.0.1 and 18.3.
> Unfortunately I cannot downgrade further then version 2.4.0, since our
> codebase uses Java8 features.
> Hibernate does not show the described behavior, neither does the same code on
> PostgreSQL.
> I am happy to help debug and fix the issue, but I'd need some guidance (i.e.
> where to look).
> EDIT: It turns out this issue is very easily reproducible. I created a
> minimal project doing so at [https://github.com/j-be/test-openjpa-2778]. No
> inheritance or @Embedded involved.
> EDIT: Using the test project I can trace it back as far as OpenJPA 2.1.0.
> 2.0.1 does not seem to be affected, I get a bunch of enhancement exceptions,
> so not sure whether that is a valid testcase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2778) Error on Oracle LOB handling
[
https://issues.apache.org/jira/browse/OPENJPA-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130468#comment-17130468
]
Romain Manni-Bucau commented on OPENJPA-2778:
-
Hi,
Oracle create docker images with its database, any hope you reproduce it in a
docker-compose you can share with us (using openjpa 3.1.1)?
Romain
> Error on Oracle LOB handling
>
>
> Key: OPENJPA-2778
> URL: https://issues.apache.org/jira/browse/OPENJPA-2778
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, jpa
>Affects Versions: 2.1.0, 2.2.0, 2.4.0, 2.4.3, 3.0.0
>Reporter: Juri Berlanda
>Assignee: Mark Struberg
>Priority: Major
> Attachments: openjpa-2778.log, test.log
>
>
> I get the following error
> {{ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB
> column}}
> on one of our queries.
> The Entity I am trying to write is relatively complicated (includes @Embedded
> and inheritance), but for legal reasons I am not allowed to disclose the code.
> What seems to happen is, that the not all CLOB columns are updated at the end
> of the update statement.
> From logs I see:
> {{databaseProductName: Oracle}}
> {{databaseProductVersion: Oracle Database 12c Enterprise Edition Release
> 12.1.0.2.0 - 64bit Production}}
> {{Using dictionary class "org.apache.openjpa.jdbc.sql.OracleDictionary"
> (Oracle Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit
> Production}}
> I reproduced the bug using all of Oracle driver 12.1.0.2, 12.2.0.1 and 18.3.
> Unfortunately I cannot downgrade further then version 2.4.0, since our
> codebase uses Java8 features.
> Hibernate does not show the described behavior, neither does the same code on
> PostgreSQL.
> I am happy to help debug and fix the issue, but I'd need some guidance (i.e.
> where to look).
> EDIT: It turns out this issue is very easily reproducible. I created a
> minimal project doing so at [https://github.com/j-be/test-openjpa-2778]. No
> inheritance or @Embedded involved.
> EDIT: Using the test project I can trace it back as far as OpenJPA 2.1.0.
> 2.0.1 does not seem to be affected, I get a bunch of enhancement exceptions,
> so not sure whether that is a valid testcase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2815) Basic jakarta bundle
Romain Manni-Bucau created OPENJPA-2815: --- Summary: Basic jakarta bundle Key: OPENJPA-2815 URL: https://issues.apache.org/jira/browse/OPENJPA-2815 Project: OpenJPA Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.2 Enables to use jakarta package instead of javax one -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2815) Basic jakarta bundle
[ https://issues.apache.org/jira/browse/OPENJPA-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2815. - Resolution: Fixed > Basic jakarta bundle > > > Key: OPENJPA-2815 > URL: https://issues.apache.org/jira/browse/OPENJPA-2815 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.2 > > > Enables to use jakarta package instead of javax one -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2814) Memory Leak in ForeignKey class
[ https://issues.apache.org/jira/browse/OPENJPA-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17100798#comment-17100798 ] Romain Manni-Bucau commented on OPENJPA-2814: - I suspect we can drop [https://www.seasar.org|https://www.seasar.org/maven/maven2/org/apache/xbean/xbean-asm8-shaded/4.17/xbean-asm8-shaded-4.17.jar] repo from the pom cause the dependency is on central. > Memory Leak in ForeignKey class > --- > > Key: OPENJPA-2814 > URL: https://issues.apache.org/jira/browse/OPENJPA-2814 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 3.0.0 >Reporter: Gregory JEVARDAT >Priority: Major > > I analyzed and solved a memory leak in the ForeignKey class. > > Context is that I run a batch application running as a service and reading > billions of entities. > I realised that ForeignKey classes were accumulating in the heap after each > query reading these entities and were never garbaged leading after few > hundreds of millions of read and hours of processing to full heap. > After profiling and debugging the leak is coming from the > ForeignKey.join(Column local,Column toPOK) method, more precisely in the line > 574 were > local.addConstraint(this) is performed. > Here the ForeignKeys are added to a Set in the Column class. > Issue is that the ForeignKey has no equals and hashcode implemented resulting > in what it seems to me logically equivalent ForeignKeys added and > accumulating indefinitely in the map of Columns. Indeed, for whatever reason > a new ForeignKey class is created each time (which also sounds weird) at > RelationFieldStrategy.createTranslatingForeignKey method > Solution: after implementing equals and hashcode in ForeignKey and Constraint > class, the application works smoothly and the memory leak is gone. Maybe it > should be done for DBIdentifier also ? > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2814) Memory Leak in ForeignKey class
[ https://issues.apache.org/jira/browse/OPENJPA-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17100480#comment-17100480 ] Romain Manni-Bucau commented on OPENJPA-2814: - Hi [~gregjdf], sounds right, do you want to create a PR to fix it? > Memory Leak in ForeignKey class > --- > > Key: OPENJPA-2814 > URL: https://issues.apache.org/jira/browse/OPENJPA-2814 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 3.0.0 >Reporter: Gregory JEVARDAT >Priority: Major > > I analyzed and solved a memory leak in the ForeignKey class. > > Context is that I run a batch application running as a service and reading > billions of entities. > I realised that ForeignKey classes were accumulating in the heap after each > query reading these entities and were never garbaged leading after few > hundreds of millions of read and hours of processing to full heap. > After profiling and debugging the leak is coming from the > ForeignKey.join(Column local,Column toPOK) method, more precisely in the line > 574 were > local.addConstraint(this) is performed. > Here the ForeignKeys are added to a Set in the Column class. > Issue is that the ForeignKey has no equals and hashcode implemented resulting > in what it seems to me logically equivalent ForeignKeys added and > accumulating indefinitely in the map of Columns. Indeed, for whatever reason > a new ForeignKey class is created each time (which also sounds weird) at > RelationFieldStrategy.createTranslatingForeignKey method > Solution: after implementing equals and hashcode in ForeignKey and Constraint > class, the application works smoothly and the memory leak is gone. Maybe it > should be done for DBIdentifier also ? > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2812) Enable to force snake_case for column names
[
https://issues.apache.org/jira/browse/OPENJPA-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau resolved OPENJPA-2812.
-
Resolution: Fixed
> Enable to force snake_case for column names
> ---
>
> Key: OPENJPA-2812
> URL: https://issues.apache.org/jira/browse/OPENJPA-2812
> Project: OpenJPA
> Issue Type: Task
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 3.1.2
>
>
> Usage would be to configure the db dictionary in the unit properties
> (adjusting your dictionary):
> {code:java}
> openjpa.jdbc.DBDictionary=derby(javaToDbColumnNameProcessing=snake_case)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2813) Implement basic support of PersistenceProvidergenerateSchema
[ https://issues.apache.org/jira/browse/OPENJPA-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2813. - Resolution: Fixed > Implement basic support of PersistenceProvidergenerateSchema > > > Key: OPENJPA-2813 > URL: https://issues.apache.org/jira/browse/OPENJPA-2813 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2812) Enable to force snake_case for column names
Romain Manni-Bucau created OPENJPA-2812:
---
Summary: Enable to force snake_case for column names
Key: OPENJPA-2812
URL: https://issues.apache.org/jira/browse/OPENJPA-2812
Project: OpenJPA
Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
Fix For: 3.1.2
Usage would be to configure the db dictionary in the unit properties (adjusting
your dictionary):
{code:java}
openjpa.jdbc.DBDictionary=derby(javaToDbColumnNameProcessing=snake_case)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2813) Implement basic support of PersistenceProvidergenerateSchema
Romain Manni-Bucau created OPENJPA-2813: --- Summary: Implement basic support of PersistenceProvidergenerateSchema Key: OPENJPA-2813 URL: https://issues.apache.org/jira/browse/OPENJPA-2813 Project: OpenJPA Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2811) Upgrade to ASM 8
[ https://issues.apache.org/jira/browse/OPENJPA-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2811. - Resolution: Fixed > Upgrade to ASM 8 > > > Key: OPENJPA-2811 > URL: https://issues.apache.org/jira/browse/OPENJPA-2811 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2811) Upgrade to ASM 8
Romain Manni-Bucau created OPENJPA-2811: --- Summary: Upgrade to ASM 8 Key: OPENJPA-2811 URL: https://issues.apache.org/jira/browse/OPENJPA-2811 Project: OpenJPA Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2809) Add openjpa-junit5 helper to enhance entities at test run
[ https://issues.apache.org/jira/browse/OPENJPA-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2809. - Resolution: Fixed > Add openjpa-junit5 helper to enhance entities at test run > - > > Key: OPENJPA-2809 > URL: https://issues.apache.org/jira/browse/OPENJPA-2809 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OPENJPA-2809) Add openjpa-junit5 helper to enhance entities at test run
[ https://issues.apache.org/jira/browse/OPENJPA-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENJPA-2809: Fix Version/s: (was: 3.1.1) 3.1.2 > Add openjpa-junit5 helper to enhance entities at test run > - > > Key: OPENJPA-2809 > URL: https://issues.apache.org/jira/browse/OPENJPA-2809 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2809) Add openjpa-junit5 helper to enhance entities at test run
Romain Manni-Bucau created OPENJPA-2809: --- Summary: Add openjpa-junit5 helper to enhance entities at test run Key: OPENJPA-2809 URL: https://issues.apache.org/jira/browse/OPENJPA-2809 Project: OpenJPA Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2798) OpenJPA need to be more Java11 friendly
[ https://issues.apache.org/jira/browse/OPENJPA-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048327#comment-17048327 ] Romain Manni-Bucau commented on OPENJPA-2798: - Well, we dont deliver it so not that critical both ways (whatever api we depend on, it is likely not the one apps will run with), however this issue is about ensuring we have automatic module *for openjpa* and a standard module name for geronimo (as another issue likely). That said it is low priority since nobody uses jpms for real world projects, osgi metadata stays way more important than jpms from what I can see. That said i join Mark for our assembly, the legal work hasnt been done so we should keep geronimo jar there at minimum - being said having the same everywhere is indeed better but no fight here for me since it does not affect consumers. > OpenJPA need to be more Java11 friendly > --- > > Key: OPENJPA-2798 > URL: https://issues.apache.org/jira/browse/OPENJPA-2798 > Project: OpenJPA > Issue Type: Improvement > Components: third-party >Affects Versions: 3.1.0 >Reporter: Maxim Solodovnik >Assignee: Maxim Solodovnik >Priority: Major > Fix For: 3.1.1 > > Time Spent: 10m > Remaining Estimate: 0h > > In case one will add OpenJPA as a dependency to Java11 modularized project > the following issue will arise: > openjpa depends on "Apache Geronimo JPA Spec 2.2" > geronimo jpa doesn't have automatic module name and automatically being > resolved as > geronimo.jpa.2.2.spec > Which is invalid java identifier :((( > I believe OpenJPA should be more Java11 friendly -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2803) DBCP2 should be optional in OSGi
[ https://issues.apache.org/jira/browse/OPENJPA-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2803. - Resolution: Fixed > DBCP2 should be optional in OSGi > > > Key: OPENJPA-2803 > URL: https://issues.apache.org/jira/browse/OPENJPA-2803 > Project: OpenJPA > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2803) DBCP2 should be optional in OSGi
Romain Manni-Bucau created OPENJPA-2803: --- Summary: DBCP2 should be optional in OSGi Key: OPENJPA-2803 URL: https://issues.apache.org/jira/browse/OPENJPA-2803 Project: OpenJPA Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.1.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2800) StateManager field in enhanced entities are not "synthetic"
[
https://issues.apache.org/jira/browse/OPENJPA-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17015719#comment-17015719
]
Romain Manni-Bucau commented on OPENJPA-2800:
-
Hmm, think we always use pc as prefix or something like that
> StateManager field in enhanced entities are not "synthetic"
> ---
>
> Key: OPENJPA-2800
> URL: https://issues.apache.org/jira/browse/OPENJPA-2800
> Project: OpenJPA
> Issue Type: Bug
> Components: Enhance
>Affects Versions: 2.4.3
>Reporter: Alexander Falb
>Priority: Minor
> Attachments: image-2020-01-15-08-12-02-066.png
>
>
> I'm using reflection to do various things on an entity-class during my unit
> tests. Because my tests are not interested in any of OpenJPAs internals, I'm
> trying to skip any field generated during enhancement. Basically I skip every
> field with where
> [Field#isSynthetic|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Field.html#isSynthetic--]]
> is true. The pcStateManager however does not have the flag ACC_SYNTHETIC set:
> {code:java}
> $ javap -verbose MyEntity.class
> [...]
> protected transient org.apache.openjpa.enhance.StateManager pcStateManager;
> descriptor: Lorg/apache/openjpa/enhance/StateManager;
> flags: ACC_PROTECTED, ACC_TRANSIENT
> [...]
> {code}
> According to the [JVM
> Specs|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.8]
> {quote}[...]A class member that does not appear in the source code must be
> marked using a Synthetic attribute, or else it must have its ACC_SYNTHETIC
> flag set.[...]
> {quote}
> Is this flag intentionally not set?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OPENJPA-2800) StateManager field in enhanced entities are not "synthetic"
[
https://issues.apache.org/jira/browse/OPENJPA-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17015690#comment-17015690
]
Romain Manni-Bucau edited comment on OPENJPA-2800 at 1/15/20 7:24 AM:
--
Hi Alexander
Why not using the name/pattern? This is what is used in general.
We can set it synthetic but it should be configurable and off by default IMHO +
it does not fix your issue for all existing code.
was (Author: romain.manni-bucau):
Hi Alexander
Why not using the name/pattern? This is what is used in general.
> StateManager field in enhanced entities are not "synthetic"
> ---
>
> Key: OPENJPA-2800
> URL: https://issues.apache.org/jira/browse/OPENJPA-2800
> Project: OpenJPA
> Issue Type: Bug
> Components: Enhance
>Affects Versions: 2.4.3
>Reporter: Alexander Falb
>Priority: Minor
> Attachments: image-2020-01-15-08-12-02-066.png
>
>
> I'm using reflection to do various things on an entity-class during my unit
> tests. Because my tests are not interested in any of OpenJPAs internals, I'm
> trying to skip any field generated during enhancement. Basically I skip every
> field with where
> [Field#isSynthetic|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Field.html#isSynthetic--]]
> is true. The pcStateManager however does not have the flag ACC_SYNTHETIC set:
> {code:java}
> $ javap -verbose MyEntity.class
> [...]
> protected transient org.apache.openjpa.enhance.StateManager pcStateManager;
> descriptor: Lorg/apache/openjpa/enhance/StateManager;
> flags: ACC_PROTECTED, ACC_TRANSIENT
> [...]
> {code}
> According to the [JVM
> Specs|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.8]
> {quote}[...]A class member that does not appear in the source code must be
> marked using a Synthetic attribute, or else it must have its ACC_SYNTHETIC
> flag set.[...]
> {quote}
> Is this flag intentionally not set?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2800) StateManager field in enhanced entities are not "synthetic"
[
https://issues.apache.org/jira/browse/OPENJPA-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17015690#comment-17015690
]
Romain Manni-Bucau commented on OPENJPA-2800:
-
Hi Alexander
Why not using the name/pattern? This is what is used in general.
> StateManager field in enhanced entities are not "synthetic"
> ---
>
> Key: OPENJPA-2800
> URL: https://issues.apache.org/jira/browse/OPENJPA-2800
> Project: OpenJPA
> Issue Type: Bug
> Components: Enhance
>Affects Versions: 2.4.3
>Reporter: Alexander Falb
>Priority: Minor
> Attachments: image-2020-01-15-08-12-02-066.png
>
>
> I'm using reflection to do various things on an entity-class during my unit
> tests. Because my tests are not interested in any of OpenJPAs internals, I'm
> trying to skip any field generated during enhancement. Basically I skip every
> field with where
> [Field#isSynthetic|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Field.html#isSynthetic--]]
> is true. The pcStateManager however does not have the flag ACC_SYNTHETIC set:
> {code:java}
> $ javap -verbose MyEntity.class
> [...]
> protected transient org.apache.openjpa.enhance.StateManager pcStateManager;
> descriptor: Lorg/apache/openjpa/enhance/StateManager;
> flags: ACC_PROTECTED, ACC_TRANSIENT
> [...]
> {code}
> According to the [JVM
> Specs|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.8]
> {quote}[...]A class member that does not appear in the source code must be
> marked using a Synthetic attribute, or else it must have its ACC_SYNTHETIC
> flag set.[...]
> {quote}
> Is this flag intentionally not set?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-673) Entity using Generated Value for primary key and a Version field and no DetachedStae fails to merge
[ https://issues.apache.org/jira/browse/OPENJPA-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955234#comment-16955234 ] Romain Manni-Bucau commented on OPENJPA-673: Sounds ok since the already persisted instance should have been throw away after the tx. Did you try to find it in the other tx to update/merge it? > Entity using Generated Value for primary key and a Version field and no > DetachedStae fails to merge > > > Key: OPENJPA-673 > URL: https://issues.apache.org/jira/browse/OPENJPA-673 > Project: OpenJPA > Issue Type: Bug >Reporter: Pinaki Poddar >Priority: Major > > Entities using GeneratedValue for primary key, a version field an dno > detached state fails to merge. > The issue lies with identifying :"what makes a new instance?" > It is not obvious why VersionAttachStrategy does not use version field to > detect newness. Instead it depends on detached state which is obviously null > for instances not using a Detached State. > Can someone shade some light on why VersionAttachStrategy ignores version > field to detect newness? > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2743) AttributeConverter fails to enhance
[ https://issues.apache.org/jira/browse/OPENJPA-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved OPENJPA-2743. - Resolution: Fixed Assignee: Romain Manni-Bucau Fix Version/s: 3.1.1 Should be fixed on master if you want to give another try. At least metamodel creation does not fail anymore cause of converters. > AttributeConverter fails to enhance > --- > > Key: OPENJPA-2743 > URL: https://issues.apache.org/jira/browse/OPENJPA-2743 > Project: OpenJPA > Issue Type: Bug > Components: Enhance >Affects Versions: 2.4.2 > Environment: Windows 10, Eclipse Oxygen, HSQLDB (memory), JAVA 8, > JUint test. >Reporter: Robert Shofner >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.1.1 > > Attachments: AttributeConvertFail.txt > > > Attempting to use AttributeConverter fails with : > Type "class com.scsi.util.jpa.converter.ExampleConverter" > does not have persistence metadata. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OPENJPA-2743) AttributeConverter fails to enhance
[ https://issues.apache.org/jira/browse/OPENJPA-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895067#comment-16895067 ] Romain Manni-Bucau commented on OPENJPA-2743: - Hi [~jinahya], AttributeConverters are not yet supported in OpenJPA. That said the error shouldn't happen too, how did you encounter it? Did you enhance your entities at build time? > AttributeConverter fails to enhance > --- > > Key: OPENJPA-2743 > URL: https://issues.apache.org/jira/browse/OPENJPA-2743 > Project: OpenJPA > Issue Type: Bug > Components: Enhance >Affects Versions: 2.4.2 > Environment: Windows 10, Eclipse Oxygen, HSQLDB (memory), JAVA 8, > JUint test. >Reporter: Robert Shofner >Priority: Major > Attachments: AttributeConvertFail.txt > > > Attempting to use AttributeConverter fails with : > Type "class com.scsi.util.jpa.converter.ExampleConverter" > does not have persistence metadata. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
