Java 8 support
Yesterday Java 8 was officially released. When I try to compile and run my tests and application that use OpenJPA 2.3.0 with Java 8 I get errors (see below) when I try to enhance the entities or use the java agent. Are there plans to support Java 8 in the near future? I did find the following issue which was unfortunately last updated almost half a year ago: https://issues.apache.org/jira/browse/OPENJPA-2386 Regards, Henno Vermeulen Java agent: 431 olgaPersistenceUnit WARN [main] openjpa.Enhance - An exception was thrown while attempting to perform class file transformation on nl/hm/olga/core/entity/AbstractEntity:java.lang.IllegalArgumentException at org.apache.xbean.asm4.ClassReader.init(Unknown Source) at org.apache.xbean.asm4.ClassReader.init(Unknown Source) at org.apache.xbean.asm4.ClassReader.init(Unknown Source) at org.apache.openjpa.enhance.AsmAdaptor.toJava7ByteArray(AsmAdaptor.java:93) at org.apache.openjpa.enhance.AsmAdaptor.toByteArray(AsmAdaptor.java:78) at org.apache.openjpa.enhance.PCClassFileTransformer.transform0(PCClassFileTransformer.java:156) at org.apache.openjpa.enhance.PCClassFileTransformer.transform(PCClassFileTransformer.java:126) at sun.instrument.TransformerManager.transform(TransformerManager.java:188) at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:428) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:760) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:455) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:367) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:360) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:760) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:455) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:367) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:360) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at nl.hm.oblomow.application.server.OblomowServerStarter.main(OblomowServerStarter.java:32) Enhancer (through Maven plugin) Caused by: java.lang.ArrayIndexOutOfBoundsException: 8 at serp.bytecode.lowlevel.ConstantPoolTable.readByte(ConstantPoolTable.java:81) at serp.bytecode.lowlevel.ConstantPoolTable.readUnsignedShort(ConstantPoolTable.java:88) at serp.bytecode.lowlevel.ConstantPoolTable.init(ConstantPoolTable.java:22) at serp.bytecode.lowlevel.ConstantPoolTable.init(ConstantPoolTable.java:30) at org.apache.openjpa.lib.meta.ClassArgParser.getFromClass(ClassArgParser.java:324) at org.apache.openjpa.lib.meta.ClassArgParser.getFromClassFile(ClassArgParser.java:308) at org.apache.openjpa.lib.meta.ClassArgParser.parseTypeNames(ClassArgParser.java:217) ... 30 more
Re: Java 8 support
Hi Henno, The JIRA you referenced is still the one for tracking the work... Because of the changes to the class file format with Java 8, we will need a new ASM in order to build and enhance Entities with Java 8. Some of the infrastructure work was put in place to support a new version of ASM, but we haven't moved to it yet. We now have a dependency on the xbean shaded version of ASM from the Geronimo project. And, I just noticed this morning that they are looking to upgrade their version in support of Java 8. Once that work is complete, then hopefully it will be relatively easy to change the OpenJPA enhancement process to take advantage of the new ASM. The other open switch is the Serp utility with Java 8. We're not sure if the class file format change for Java 8 is going to directly affect Serp or not. We're hoping that the ASM upgrade will alleviate necessary changes to Serp. Not sure of your availability and skills, but any assistance with this activity would be appreciated. I see that ASM 5.0.1 was recently released in support of Java 8 [1]. So, skipping the xbean shading for now, if someone wants to re-package OpenJPA with ASM 5.0.1, we could start to see how big of an effort this will be. Do not attempt to build OpenJPA with Java 8. Stick with Java 7 for building. At this point, we are only interested in allowing applications to be built with Java 8. Good luck! Thanks, Kevin [1] http://forge.ow2.org/projects/asm/ On Wed, Mar 26, 2014 at 9:59 AM, Henno Vermeulen he...@huizemolenaar.nlwrote: Yesterday Java 8 was officially released. When I try to compile and run my tests and application that use OpenJPA 2.3.0 with Java 8 I get errors (see below) when I try to enhance the entities or use the java agent. Are there plans to support Java 8 in the near future? I did find the following issue which was unfortunately last updated almost half a year ago: https://issues.apache.org/jira/browse/OPENJPA-2386 Regards, Henno Vermeulen Java agent: 431 olgaPersistenceUnit WARN [main] openjpa.Enhance - An exception was thrown while attempting to perform class file transformation on nl/hm/olga/core/entity/AbstractEntity:java.lang.IllegalArgumentException at org.apache.xbean.asm4.ClassReader.init(Unknown Source) at org.apache.xbean.asm4.ClassReader.init(Unknown Source) at org.apache.xbean.asm4.ClassReader.init(Unknown Source) at org.apache.openjpa.enhance.AsmAdaptor.toJava7ByteArray(AsmAdaptor.java:93) at org.apache.openjpa.enhance.AsmAdaptor.toByteArray(AsmAdaptor.java:78) at org.apache.openjpa.enhance.PCClassFileTransformer.transform0(PCClassFileTransformer.java:156) at org.apache.openjpa.enhance.PCClassFileTransformer.transform(PCClassFileTransformer.java:126) at sun.instrument.TransformerManager.transform(TransformerManager.java:188) at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:428) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:760) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:455) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:367) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:360) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:760) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:455) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:367) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:360) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at
Re: Confusing conflicts between OpenJPA and Postgresql
Do you have the property openjpa.jdbc.TransactionIsolation specified in
your persistence.xml? It *looks* like we'll only try to set the
transactionIsolation level if that property is not left to the default.
Thanks,
Rick
On Mon, Mar 24, 2014 at 10:56 AM, Vito testfor...@163.com wrote:
Hi all,
I'm recently doing some research with Apache ODE engine. I use Postgresql
as its external database, openjpa as its ORM solution and bitronix as its
transaction manager. The ODE workflow engine starts without any problem.
But when I deploy process definition files into the engine, the exception
came out. I paste the error content at the end of this email.
I looked through the source code of
org.apache.openjpa.lib.jdbc.DecoratingDataSource, and found that openjpa is
almost definitely to meant to invoke the function of reseting transaction
isolation level, which would be catched by Postgresql and return with an
exception.
Does that mean openjpa works poorly with Postgresql? Or who can tell me
how to solve this problem.
The error content is below:
17:32:05,155 ERROR [ProcessStoreImpl] Error persisting deployment record
for {http://sample.bpel.org/bpel/sample}longFlow-1; process will not be
available after restart!
openjpa-1.2.1-r752877:753278 nonfatal general error
org.apache.openjpa.persistence.PersistenceException: Cannot change
transaction isolation level in the middle of a transaction
at
org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4232)
at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4197)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:88)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connect(JDBCStoreManager.java:930)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.getConnection(JDBCStoreManager.java:230)
at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:371)
at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:339)
at
org.apache.openjpa.jdbc.sql.LogicalUnion$UnionSelect.execute(LogicalUnion.java:420)
at
org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:230)
at
org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:220)
at
org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:206)
at
org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.open(SelectResultObjectProvider.java:94)
at
org.apache.openjpa.lib.rop.WindowResultList.init(WindowResultList.java:57)
at
org.apache.openjpa.jdbc.kernel.JDBCFetchConfigurationImpl.newResultList(JDBCFetchConfigurationImpl.java:235)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1228)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:990)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:775)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:771)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:517)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:255)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:294)
at
org.apache.ode.store.jpa.ConfStoreConnectionJpa.setVersion(ConfStoreConnectionJpa.java:76)
at
org.apache.ode.store.ProcessStoreImpl$2.call(ProcessStoreImpl.java:294)
at
org.apache.ode.store.ProcessStoreImpl$2.call(ProcessStoreImpl.java:264)
at
org.apache.ode.store.ProcessStoreImpl$Callable.call(ProcessStoreImpl.java:793)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.postgresql.util.PSQLException: Cannot change transaction
isolation level in the middle of a transaction
at
org.postgresql.jdbc2.AbstractJdbc2Connection.setTransactionIsolation(AbstractJdbc2Connection.java:944)
at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
bitronix.tm.resource.jdbc.BaseProxyHandlerClass.invoke(BaseProxyHandlerClass.java:64)
at $Proxy5.setTransactionIsolation(Unknown Source)
at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
Re: Unecessary database update?
Alain -
I looked at your unit test and the reason that an extra update is being
sent to the database is because you're updating your Entity in the
@PreUpdate method. If you didn't update that field, no update would be
issued. That being said, I think we're getting down to the real problem.
I don't think @PreUpdate should be called in this instance because even
though Parent is dirty, it doesn't result in a DB update and as such,
@PreUpdate shouldn't be invoked. I thought we had a feature to control this
behavior, but I'm struggling to find it right now.
I'll attach my unit test for future reference.
Thanks,
Rick
On Tue, Mar 25, 2014 at 9:22 AM, Alain Brazeau abraz...@rogers.com wrote:
Hi Rick,
As requested, here is a test I wrote in the 'openjpa-persistence-jdbc'
project:
package org.apache.openjpa.persistence.jdbc.update;
import java.util.Date;
import javax.persistence.EntityManager;
import org.apache.openjpa.persistence.test.SingleEMFTestCase;
public class TestCascadePersist extends SingleEMFTestCase {
public void setUp() throws Exception {
super.setUp(CLEAR_TABLES, Parent.class, Child.class);
}
public void testAddChildShouldNotUpdateParent() {
EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
Parent parent = new Parent();
parent.setName(parent);
em.persist(parent);
em.getTransaction().commit();
long parentId = parent.getId();
Date expectedLastModifiedDate = parent.getLastModifiedDate();
em.getTransaction().begin();
parent = em.find(Parent.class, parentId);
parent.newChild(child);
em.getTransaction().commit();
Date actualModifiedDate = parent.getLastModifiedDate();
assertEquals(The last modified date should not change.,
expectedLastModifiedDate.getTime(),
actualModifiedDate.getTime());
}
}
In order for the test to work, the following instance variable and methods
have to be added to the
existing org.apache.openjpa.persistence.jdbc.update.Parent class:
private Date lastModifiedDate;
public Date getLastModifiedDate() {
return lastModifiedDate;
}
@PrePersist
@PreUpdate
public void onUpdate() {
this.lastModifiedDate = new Date();
}
Thanks!
Alain
--
View this message in context:
http://openjpa.208410.n2.nabble.com/Unecessary-database-update-tp7586121p7586153.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
--
*Rick Curtis*
Re: OpenJPA retrieving one column a seperate select
Can you put together a small unit test that recreates the issue? That will
help us understand what is going on.
Thanks,
Rick
On Tue, Mar 25, 2014 at 1:51 PM, mxvs mxvs...@gmail.com wrote:
Hello, I've been using OpenJPA 2.1.2 (JPA 2.0) to retrieve data from a
table
called LOGISCHRAPPORT which has about 28 columns. In some cases OpenJPA
decides to issue seperate select statements for one of the columns for no
particular reason, leading to a dramatic decrease in query performance.
Initially everything goes fine and all my columns are retrieved in a
performant, single SELECT statement by JPA.
As soon as I add a relationship to another entity called RAPTAALMETADATA
@OneToMany(fetch=FetchType.EAGER, cascade = CascadeType.ALL)
@JoinColumns({
@JoinColumn(name = RAPPORTNR, referencedColumnName =
RAPPORTNR),
@JoinColumn(name = RAPPORTTYPE, referencedColumnName =
RAPPORTTYPE) })
private ListRaptaalmetadata raptaalmetadata;
---
Queried using Criteria API as follows:
---
JoinLogischRapport, Raptaalmetadata metadata = reportRoot.join(
raptaalmetadata);
JPA no longer includes one of my original columns called REPORT_COMMENTS
instead it is issuing separate select statements to retrieve the
REPORT_COMMENTS column for each instance of LOGISCHRAPPORT. All other
columns (including the ones coming from RAPTAALMETADATA are retrieved
properly as part of the intial SELECT.
REPORT_COMMENTS is of the HUGEBLOB type in Oracle and I've mapped in in my
Entity as follows:
@Lob
@Basic
@Column(name = REPORT_COMMENTS)
private byte[] reportComments;
I now get tons of these:
SELECT t0.REPORT_COMMENTS
FROM dwhsd001.LogischRapport t0
WHERE t0.rapportnr = ? AND t0.rapporttype = ?
[params=(long) 1473, (String) RAP]
Additionally: as soon as I remove the fetch=FetchType.EAGER attribute from
the @OneToMany annotation described above I start seeing the exact same
behavior for the relationship as I've been getting for the REPORT_COMMENTS
column. This means I'm also getting separate SELECT statements for
retrieving the entity relationship on top of the seperate selects for the
column thereby further degrading performance.
In other words I'm then also getting tons of these:
SELECT t0.isotaalcode, t0.rapportnr, t0.rapporttype,
t0.FUNCDESC_MODIFIED_BY, t0.FUNCDESC_MODIFIED_DATE,
t0.FUNCTIONAL_DESCRIPTION, t0.omschrijving, t0.titel
FROM dwhsd001.Raptaalmetadata t0
WHERE t0.rapportnr = ? AND t0.rapporttype = ?
Its not a LAZY loading problem as I've specifically tested that case. I
don't see any other reason why OpenJPA decides to retrieve this one column
using separate statements.
Can anyone point out why I might be seeing this behavior and how I can
avoid
it?
--
View this message in context:
http://openjpa.208410.n2.nabble.com/OpenJPA-retrieving-one-column-a-seperate-select-tp7586156.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
--
*Rick Curtis*
