[jira] [Assigned] (OPENJPA-2343) Version field of related entity returns null when explicitly projected in SELECT clause
[
https://issues.apache.org/jira/browse/OPENJPA-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Curtis reassigned OPENJPA-2343:
Assignee: Rick Curtis
Version field of related entity returns null when explicitly projected in
SELECT clause
---
Key: OPENJPA-2343
URL: https://issues.apache.org/jira/browse/OPENJPA-2343
Project: OpenJPA
Issue Type: Bug
Components: query
Affects Versions: 2.2.1
Reporter: howard kelsey
Assignee: Rick Curtis
Attachments: OPENJPA-2343-2.2.1.x.patch
With these entities:
@Entity
public class Foo {
private int id;
private int version;
@Id
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public void setVersion(int version) {
this.version = version;
}
@Version
public int getVersion() {
return this.version;
}
}
@Entity
public class Bar{
private int id;
private Foo foo;
@Id
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public void setFoo(Foo foo) {
this.foo = foo;
}
@ManyToOne
public Foo getFoo() {
return foo;
}
}
Insert a record for each associating foo with bar.
Foo foo = new Foo();
em.getTransaction().begin();
em.persist(foo);
Bar bar = new Bar();
bar.setFoo(foo);
em.persist(bar);
em.getTransaction().commit();
em.close();
queries
select bar.id as id, foo as foo from Bar bar join bar.foo foo
The version field is available via foo.getVersion()
select bar.id as id, foo.version as version from Bar bar join bar.foo foo
version is always null.
By enabling the jdbc debug I can see that the actual SQL being run is correct
but the value is just not hydrated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENJPA-2343) Version field returns null when explicity projected from a JOIN in SELECT clause
[
https://issues.apache.org/jira/browse/OPENJPA-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Curtis updated OPENJPA-2343:
-
Summary: Version field returns null when explicity projected from a JOIN in
SELECT clause (was: Version field of related entity returns null when
explicitly projected in SELECT clause)
Version field returns null when explicity projected from a JOIN in SELECT
clause
Key: OPENJPA-2343
URL: https://issues.apache.org/jira/browse/OPENJPA-2343
Project: OpenJPA
Issue Type: Bug
Components: query
Affects Versions: 2.2.1
Reporter: howard kelsey
Assignee: Rick Curtis
Attachments: OPENJPA-2343-2.2.1.x.patch
With these entities:
@Entity
public class Foo {
private int id;
private int version;
@Id
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public void setVersion(int version) {
this.version = version;
}
@Version
public int getVersion() {
return this.version;
}
}
@Entity
public class Bar{
private int id;
private Foo foo;
@Id
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public void setFoo(Foo foo) {
this.foo = foo;
}
@ManyToOne
public Foo getFoo() {
return foo;
}
}
Insert a record for each associating foo with bar.
Foo foo = new Foo();
em.getTransaction().begin();
em.persist(foo);
Bar bar = new Bar();
bar.setFoo(foo);
em.persist(bar);
em.getTransaction().commit();
em.close();
queries
select bar.id as id, foo as foo from Bar bar join bar.foo foo
The version field is available via foo.getVersion()
select bar.id as id, foo.version as version from Bar bar join bar.foo foo
version is always null.
By enabling the jdbc debug I can see that the actual SQL being run is correct
but the value is just not hydrated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENJPA-2343) Version field returns null when explicity projected from a JOIN in SELECT clause
[
https://issues.apache.org/jira/browse/OPENJPA-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Curtis updated OPENJPA-2343:
-
Affects Version/s: 2.3.0
Fix Version/s: 2.3.0
Version field returns null when explicity projected from a JOIN in SELECT
clause
Key: OPENJPA-2343
URL: https://issues.apache.org/jira/browse/OPENJPA-2343
Project: OpenJPA
Issue Type: Bug
Components: query
Affects Versions: 2.3.0, 2.2.1
Reporter: howard kelsey
Assignee: Rick Curtis
Fix For: 2.3.0
Attachments: OPENJPA-2343-2.2.1.x.patch
With these entities:
@Entity
public class Foo {
private int id;
private int version;
@Id
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public void setVersion(int version) {
this.version = version;
}
@Version
public int getVersion() {
return this.version;
}
}
@Entity
public class Bar{
private int id;
private Foo foo;
@Id
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public void setFoo(Foo foo) {
this.foo = foo;
}
@ManyToOne
public Foo getFoo() {
return foo;
}
}
Insert a record for each associating foo with bar.
Foo foo = new Foo();
em.getTransaction().begin();
em.persist(foo);
Bar bar = new Bar();
bar.setFoo(foo);
em.persist(bar);
em.getTransaction().commit();
em.close();
queries
select bar.id as id, foo as foo from Bar bar join bar.foo foo
The version field is available via foo.getVersion()
select bar.id as id, foo.version as version from Bar bar join bar.foo foo
version is always null.
By enabling the jdbc debug I can see that the actual SQL being run is correct
but the value is just not hydrated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENJPA-2351) Subclasses writeExternal method trys to access a super class' private field.
[
https://issues.apache.org/jira/browse/OPENJPA-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Albert Lee updated OPENJPA-2351:
Patch Info: Patch Available
Affects Version/s: 2.3.0
Assignee: Albert Lee (was: Heath Thomann)
Subclasses writeExternal method trys to access a super class' private field.
Key: OPENJPA-2351
URL: https://issues.apache.org/jira/browse/OPENJPA-2351
Project: OpenJPA
Issue Type: Bug
Components: Enhance
Affects Versions: 2.0.3, 2.1.2, 2.3.0, 2.2.2, 2.2.1.1
Reporter: Heath Thomann
Assignee: Albert Lee
Attachments: ExternalizableIssue.zip, OPENJPA-2351.20x.patch
HI! I have a test (see attachment ExternalizableIssues.zip) which
demonstrates the following issue:
java.lang.IllegalAccessError: tried to access field hat.test.SuperEntity.id
from class hat.test.SimpleEntity
at hat.test.SimpleEntity.writeExternal(SimpleEntity.java)
at
java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at hat.test.TestMain.roundtrip(TestMain.java:28)
at hat.test.TestMain.main(TestMain.java:16)
As I'll explain, the generated classes seem to be incorrect when a
DetachState is used:
properties
property name=openjpa.DetachState
value=fetch-groups(DetachedStateField=true)/
/properties
In this case, OpenJPA enhancer would generate the classes as Externalizable,
rather than Serializable, and it is the implementation of a writeExternal
method which causes a problem. NOTE: when running the test and playing around
with DetachState setting, make sure to use a runtime enhancer/javaagent and
not to pre-enhance as the entities need to be re-enhanced as the value of
DetachState changes or is removed.
If one decompiles the enhnaced version (see
'SimpleEntity_Enhnaced_Externalizable.java.txt' in the provided zip) of
SimpleEntity with 'openjpa.DetachState' set, we get a writeExternal method
like the following where the private field in the parent class is accessed
(i.e. 'this.superText'):
public void writeExternal(ObjectOutput paramObjectOutput)
throws IOException
{
pcWriteUnmanaged(paramObjectOutput);
if (this.pcStateManager != null)
{
if (!this.pcStateManager.writeDetached(paramObjectOutput));
}
else
{
paramObjectOutput.writeObject(pcGetDetachedState());
paramObjectOutput.writeObject(null);
}
paramObjectOutput.writeInt(this.id);
paramObjectOutput.writeObject(this.superText);
paramObjectOutput.writeObject(this.text);
}
For comparison purposes only, if we look at the enhanced version (see
'SimpleEntity_Enhnaced_Serializable.java.txt' in the provided zip) of
SimpleEntity with 'openjpa.DetachState' NOT set, we see the following
writeObject method:
private void writeObject(ObjectOutputStream paramObjectOutputStream)
throws IOException
{
boolean bool = pcSerializing();
paramObjectOutputStream.defaultWriteObject();
if (bool)
pcSetDetachedState(null);
}
Seems like generated code should detect the private field and call the get
method?
The provided test (ExternalizableIssues.zip), is a simple Java Eclipse
project. You can import this zip and run the test class. Simply point to an
OpenJPA jar (I'm using an OpenJPA 2.0.x jar) and use an enhancer at runtime.
Thanks,
Heath
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OPENJPA-2359) Output warning of ClassCastException when multiple entities share the same db table but with inconsistency field definitions
Albert Lee created OPENJPA-2359: --- Summary: Output warning of ClassCastException when multiple entities share the same db table but with inconsistency field definitions Key: OPENJPA-2359 URL: https://issues.apache.org/jira/browse/OPENJPA-2359 Project: OpenJPA Issue Type: Improvement Components: jpa Affects Versions: 2.2.1, 2.1.1, 2.0.1, 2.3.0, 2.2.1.1 Reporter: Albert Lee Priority: Minor A ClassCastException similar to the following is thrown when multiple entities share the same db table but with inconsistency field definitions. openjpa-2.0.2-SNAPSHOT-r422266:1392660 nonfatal general error org.apache.openjpa.persistence.PersistenceException: java.lang.String incompatible with java.util.Date FailedObject: 1 [org.apache.openjpa.util.StringId] [java.lang.String] at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:989) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:883) at org.apache.openjpa.kernel.DelegatingBroker.find(DelegatingBroker.java:223) at org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:477) at org.apache.openjpa.persistence.query.TestPMRDateString.testSimple(TestPMRDateString.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:516) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:503) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:479) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:179) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: java.lang.ClassCastException: java.lang.String incompatible with java.util.Date at org.apache.openjpa.kernel.SingleFieldManager.proxy(SingleFieldManager.java:107) at org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2607) at org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:2707) at org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:882) at org.apache.openjpa.kernel.StateManagerImpl.store(StateManagerImpl.java:878) at org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy.load(HandlerFieldStrategy.java:199) at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:928) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1112) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1056) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:427) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:322) at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:112) at org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57) at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:1008) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:966) ... 26 more See the attached test case's entities field definitions: @Temporal(TemporalType.DATE) @Column(name = EFF_FROM_DT) private Date effFromDt; // @Temporal(TemporalType.DATE) @Column(name =
[jira] [Updated] (OPENJPA-2359) Output warning of ClassCastException when multiple entities share the same db table but with inconsistency field definitions
[ https://issues.apache.org/jira/browse/OPENJPA-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated OPENJPA-2359: Attachment: OPENJPA-2359.20x.testcase.patch Output warning of ClassCastException when multiple entities share the same db table but with inconsistency field definitions Key: OPENJPA-2359 URL: https://issues.apache.org/jira/browse/OPENJPA-2359 Project: OpenJPA Issue Type: Improvement Components: jpa Affects Versions: 2.0.1, 2.1.1, 2.3.0, 2.2.1, 2.2.1.1 Reporter: Albert Lee Priority: Minor Attachments: OPENJPA-2359.20x.testcase.patch A ClassCastException similar to the following is thrown when multiple entities share the same db table but with inconsistency field definitions. openjpa-2.0.2-SNAPSHOT-r422266:1392660 nonfatal general error org.apache.openjpa.persistence.PersistenceException: java.lang.String incompatible with java.util.Date FailedObject: 1 [org.apache.openjpa.util.StringId] [java.lang.String] at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:989) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:883) at org.apache.openjpa.kernel.DelegatingBroker.find(DelegatingBroker.java:223) at org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:477) at org.apache.openjpa.persistence.query.TestPMRDateString.testSimple(TestPMRDateString.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:516) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:503) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:479) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:179) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: java.lang.ClassCastException: java.lang.String incompatible with java.util.Date at org.apache.openjpa.kernel.SingleFieldManager.proxy(SingleFieldManager.java:107) at org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2607) at org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:2707) at org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:882) at org.apache.openjpa.kernel.StateManagerImpl.store(StateManagerImpl.java:878) at org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy.load(HandlerFieldStrategy.java:199) at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:928) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1112) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1056) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:427) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:322) at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:112) at org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57) at
[jira] [Updated] (OPENJPA-2359) Output warning of ClassCastException when multiple entities share the same db table but with inconsistency field definitions
[ https://issues.apache.org/jira/browse/OPENJPA-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated OPENJPA-2359: Patch Info: Patch Available Output warning of ClassCastException when multiple entities share the same db table but with inconsistency field definitions Key: OPENJPA-2359 URL: https://issues.apache.org/jira/browse/OPENJPA-2359 Project: OpenJPA Issue Type: Improvement Components: jpa Affects Versions: 2.0.1, 2.1.1, 2.3.0, 2.2.1, 2.2.1.1 Reporter: Albert Lee Priority: Minor Attachments: OPENJPA-2359.20x.testcase.patch A ClassCastException similar to the following is thrown when multiple entities share the same db table but with inconsistency field definitions. openjpa-2.0.2-SNAPSHOT-r422266:1392660 nonfatal general error org.apache.openjpa.persistence.PersistenceException: java.lang.String incompatible with java.util.Date FailedObject: 1 [org.apache.openjpa.util.StringId] [java.lang.String] at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:989) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:883) at org.apache.openjpa.kernel.DelegatingBroker.find(DelegatingBroker.java:223) at org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:477) at org.apache.openjpa.persistence.query.TestPMRDateString.testSimple(TestPMRDateString.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:516) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:503) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:479) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:179) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: java.lang.ClassCastException: java.lang.String incompatible with java.util.Date at org.apache.openjpa.kernel.SingleFieldManager.proxy(SingleFieldManager.java:107) at org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2607) at org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:2707) at org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:882) at org.apache.openjpa.kernel.StateManagerImpl.store(StateManagerImpl.java:878) at org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy.load(HandlerFieldStrategy.java:199) at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:928) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1112) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1056) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:427) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:322) at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:112) at org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57) at
[jira] [Resolved] (OPENJPA-1741) Unecessary class load attempts when parsing JPQL
[ https://issues.apache.org/jira/browse/OPENJPA-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Curtis resolved OPENJPA-1741. -- Resolution: Won't Fix Unecessary class load attempts when parsing JPQL Key: OPENJPA-1741 URL: https://issues.apache.org/jira/browse/OPENJPA-1741 Project: OpenJPA Issue Type: Bug Components: query Affects Versions: 1.2.2, 2.0.0 Reporter: David Minor Assignee: Rick Curtis Attachments: cache-class-load-attempts.patch, only-load-uppercase-java-lang.patch, skip-known-variables.patch When parsing JPQL, JPQLExpressionBuilder.getPathOrConstant() tries to determine if a token is a java class or enum by doing a class load (via QueryImpl.classForName()). The same token will be tried as often as it appears in the query. It might be better to 1) cache the results 2) avoid the lookup if the token is a known variable name -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OPENJPA-1741) Unecessary class load attempts when parsing JPQL
[ https://issues.apache.org/jira/browse/OPENJPA-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615327#comment-13615327 ] Rick Curtis commented on OPENJPA-1741: -- Closing this JIRA as I don't expect that we're ever going to make this change. Unecessary class load attempts when parsing JPQL Key: OPENJPA-1741 URL: https://issues.apache.org/jira/browse/OPENJPA-1741 Project: OpenJPA Issue Type: Bug Components: query Affects Versions: 1.2.2, 2.0.0 Reporter: David Minor Assignee: Rick Curtis Attachments: cache-class-load-attempts.patch, only-load-uppercase-java-lang.patch, skip-known-variables.patch When parsing JPQL, JPQLExpressionBuilder.getPathOrConstant() tries to determine if a token is a java class or enum by doing a class load (via QueryImpl.classForName()). The same token will be tried as often as it appears in the query. It might be better to 1) cache the results 2) avoid the lookup if the token is a known variable name -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENJPA-2057) Rethinking ClassLoading architecture
[ https://issues.apache.org/jira/browse/OPENJPA-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Curtis updated OPENJPA-2057: - Assignee: Pinaki Poddar (was: Rick Curtis) Rethinking ClassLoading architecture - Key: OPENJPA-2057 URL: https://issues.apache.org/jira/browse/OPENJPA-2057 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assignee: Pinaki Poddar This issue proposes an overhaul of the classloading architecture. Background: -- OpenJPA runtime needs to load classes and resources at various time points in its life cycle and employs various classloading strategies at different parts of its code base. These are few broad categories of classes/resources OpenJPA needs to load 1. Resources: user-specified resources such as persistence.xml or orm.xml 2. Persistent Domain classes 3. Native Plug-ins: Implementation of interfaces e.g. UpdateManager that are supplied by OpenJPA and packaged in its own distribution 4. User Plug-ins: Implementation of interfaces e.g. MappingStrategy or ValueHandlers that the user has supplied via configuration and packaged in deployed units 5. Temporary classloader for java agent or weaving code loading domain classes to enhance them prior to their use To load these different artifacts by their name, OpenJPA at different places employ available classloaders such as i) the current thread's context class loader ii) the clasloader that loaded OpenJPA native classes/interfaces iii) the classloader that loaded a deployed application which can vary based on the container (Spring, OSGi, JEE) environment iv) system classloader The problem is the decision about which classloader is appropriate in a given context is quite scattered. This weakness appears in numerous places where a method is supplied with a ClassLoader and if the supplied loader is null, the method chooses a classloader (often the context classloader) or a class has its own classforname() method that tries a series of classloaders etc. This is a perennial problem and manifested in several reported bugs whose resolutions often introduced further localized logic to account for the point defects, thereby accentuating the same trends that I believe is the root cause of the problem itself. Proposed solution/design: - Unify classloading decision in a singular abstraction. Allow that abstraction to cope with classloading regimes of different containers (Spring, OSGi, JEE etc). The natural candidate for unifying classloading is existing Configuration object. This object is a per persistence unit singleton and available throughout the runtime. However, certain class/resource loading must take place even before a Configuration instance is instantiated. For example, to locate and load the persistence.xml itself. Also note that the persistence.xml or orm.xml may contain fully-qualified names of persistent domain classes or plug-in names (both native and custom/user variety) and they can occur either by their fully-qualified class name or registered alias. The specialized parsers often has to load the class given their parsed string names or aliases. The bootstrap sequence of OpenJPA runtime is to construct a specific ConfigurationProvider and a series of specialized parsers to parse meta-data of various sorts (annotations, mapping xml, persistence.xml). These ConfigurationProviders are responsibilities of ProductDerivation -- the core mechanics that contributes their individual aspects to build up a Configuration. Given this existing well-designed bootstrap strategy, here is a proposal 1. Let each ProductDerivation make their decision on how they will load whatever they need to load using whatever classloader they may need. For example, a OSGi ProductDerivation will use a bundle classloader to load its relevant resources. This phase occurs *before* a persistence unit (i.e. EntityManagerFactory) is constructed. 2. Once the ProductDerivations have finished their loading using their own ConfigurationProvider, they transfer the accumulated information to a Configuration instance which essentially becomes the holder of entire runtime information for an EntityManagerFactory. During this transfer phase, let the ProductDerivations set the classloader as well into the Configuration instance. 3. Once the Configuration instance has the classloader, this classloader is used throughout the codebase. But what kind of classloader is used by the Configuration that will suit complex needs of class/resource loading? OpenJPA already has a powerful abstraction called MultiClassLoader which can employ an ordered
[jira] [Commented] (OPENJPA-2057) Rethinking ClassLoading architecture
[ https://issues.apache.org/jira/browse/OPENJPA-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615330#comment-13615330 ] Rick Curtis commented on OPENJPA-2057: -- Assigning back to Pinaki hopefully we can get to this piece of work in the near future. Rethinking ClassLoading architecture - Key: OPENJPA-2057 URL: https://issues.apache.org/jira/browse/OPENJPA-2057 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assignee: Pinaki Poddar This issue proposes an overhaul of the classloading architecture. Background: -- OpenJPA runtime needs to load classes and resources at various time points in its life cycle and employs various classloading strategies at different parts of its code base. These are few broad categories of classes/resources OpenJPA needs to load 1. Resources: user-specified resources such as persistence.xml or orm.xml 2. Persistent Domain classes 3. Native Plug-ins: Implementation of interfaces e.g. UpdateManager that are supplied by OpenJPA and packaged in its own distribution 4. User Plug-ins: Implementation of interfaces e.g. MappingStrategy or ValueHandlers that the user has supplied via configuration and packaged in deployed units 5. Temporary classloader for java agent or weaving code loading domain classes to enhance them prior to their use To load these different artifacts by their name, OpenJPA at different places employ available classloaders such as i) the current thread's context class loader ii) the clasloader that loaded OpenJPA native classes/interfaces iii) the classloader that loaded a deployed application which can vary based on the container (Spring, OSGi, JEE) environment iv) system classloader The problem is the decision about which classloader is appropriate in a given context is quite scattered. This weakness appears in numerous places where a method is supplied with a ClassLoader and if the supplied loader is null, the method chooses a classloader (often the context classloader) or a class has its own classforname() method that tries a series of classloaders etc. This is a perennial problem and manifested in several reported bugs whose resolutions often introduced further localized logic to account for the point defects, thereby accentuating the same trends that I believe is the root cause of the problem itself. Proposed solution/design: - Unify classloading decision in a singular abstraction. Allow that abstraction to cope with classloading regimes of different containers (Spring, OSGi, JEE etc). The natural candidate for unifying classloading is existing Configuration object. This object is a per persistence unit singleton and available throughout the runtime. However, certain class/resource loading must take place even before a Configuration instance is instantiated. For example, to locate and load the persistence.xml itself. Also note that the persistence.xml or orm.xml may contain fully-qualified names of persistent domain classes or plug-in names (both native and custom/user variety) and they can occur either by their fully-qualified class name or registered alias. The specialized parsers often has to load the class given their parsed string names or aliases. The bootstrap sequence of OpenJPA runtime is to construct a specific ConfigurationProvider and a series of specialized parsers to parse meta-data of various sorts (annotations, mapping xml, persistence.xml). These ConfigurationProviders are responsibilities of ProductDerivation -- the core mechanics that contributes their individual aspects to build up a Configuration. Given this existing well-designed bootstrap strategy, here is a proposal 1. Let each ProductDerivation make their decision on how they will load whatever they need to load using whatever classloader they may need. For example, a OSGi ProductDerivation will use a bundle classloader to load its relevant resources. This phase occurs *before* a persistence unit (i.e. EntityManagerFactory) is constructed. 2. Once the ProductDerivations have finished their loading using their own ConfigurationProvider, they transfer the accumulated information to a Configuration instance which essentially becomes the holder of entire runtime information for an EntityManagerFactory. During this transfer phase, let the ProductDerivations set the classloader as well into the Configuration instance. 3. Once the Configuration instance has the classloader, this classloader is used throughout the codebase. But what kind of classloader is used by the Configuration that will suit complex needs of
[jira] [Commented] (OPENJPA-2356) Use new Offset/Limit/ROWNUM features in DB2 family of databases for range queries
[ https://issues.apache.org/jira/browse/OPENJPA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615423#comment-13615423 ] Rick Curtis commented on OPENJPA-2356: -- Pinaki -- Can I have you update the affects/fix versions? Thanks! Use new Offset/Limit/ROWNUM features in DB2 family of databases for range queries - Key: OPENJPA-2356 URL: https://issues.apache.org/jira/browse/OPENJPA-2356 Project: OpenJPA Issue Type: Improvement Reporter: Pinaki Poddar Assignee: Pinaki Poddar JPA queries that use setFirstResult() and/or setMaxResult() translate to some form of Offset and Limit syntax in database SQL query. Recently DB2 and Derby has added ROWNUM and FETCH offset respectively. OpenJPA should use these facilities when appropriate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OPENJPA-2342) Consider modifying PCEnhancer.run to use serp.bytecode.BCClass.getDeclaredInterfaceNames instead of getDeclaredInterfaceTypes.
[ https://issues.apache.org/jira/browse/OPENJPA-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615560#comment-13615560 ] ASF subversion and git services commented on OPENJPA-2342: -- Commit 1461751 from kwsutter [ https://svn.apache.org/r1461751 ] OPENJPA-2342. Changed to use the getDeclaredInterfaceNames instead of getDeclaredInterfaceTypes. All testing is looking good and should alleviate the problem of the classloading. Consider modifying PCEnhancer.run to use serp.bytecode.BCClass.getDeclaredInterfaceNames instead of getDeclaredInterfaceTypes. -- Key: OPENJPA-2342 URL: https://issues.apache.org/jira/browse/OPENJPA-2342 Project: OpenJPA Issue Type: Improvement Components: Enhance Affects Versions: 2.2.2 Reporter: John Ross Attachments: openjpa-2342.patch Caused by: openjpa-2.2.2-SNAPSHOT-r422266:1446295 nonfatal general error org.apache.openjpa.util.GeneralException: An error occurred while enhancing itemjpa.ItemJPA. Exception message: java.lang.ClassNotFoundException: org.apache.aries.proxy.weaving.WovenProxy at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:578) at org.apache.openjpa.enhance.PCClassFileTransformer.transform0(PCClassFileTransformer.java:153) at org.apache.openjpa.enhance.PCClassFileTransformer.transform(PCClassFileTransformer.java:126) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.transform(PersistenceProviderImpl.java:290) at org.apache.aries.jpa.container.weaving.impl.WrappingTransformer.transform(WrappingTransformer.java:80) at org.apache.aries.jpa.container.weaving.impl.JPAWeavingHook.weave(JPAWeavingHook.java:71) ... 48 more Caused by: java.lang.IllegalArgumentException: java.lang.ClassNotFoundException: org.apache.aries.proxy.weaving.WovenProxy at serp.util.Strings.toClass(Strings.java:164) at serp.util.Strings.toClass(Strings.java:108) at serp.bytecode.BCClass.getDeclaredInterfaceTypes(BCClass.java:740) at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:537) ... 53 more This issue occurs when the Apache Aries Proxy weaving hook gets called before the Apache Aries JPA weaving hook. Proxy weaves the class with the WovenProxy interface and adds the necessary dynamic package imports. JPA then gets called and uses PCEnhancer which, in turn, calls BCClass.getDeclaredInterfaceTypes, which ultimately calls Class.forName using the woven interface's name. The class loader is from the bundle whose class is being woven. Per the OSGi spec, dynamic imports do not take effect until after the entire weaving process is complete. Consequently, the bundle's class loader does not yet have visibility to the class. One solution to this, at least in the Aries case, is to order the weaving hook calls using the osgi service ranking property. However, all weaving hook services with potential conflicts may not be under the control of the same entity. Basically, PCEnhancer.run is using the information from BCClass to determine whether or not the class has already been woven. It's only interested in knowing if the PersistenceCapable interface is there. It seems that BCClass.getDeclaredInterfaceNames avoids the Class.forName call and could be used instead, particularly considering that only the class names are compared. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENJPA-2342) Consider modifying PCEnhancer.run to use serp.bytecode.BCClass.getDeclaredInterfaceNames instead of getDeclaredInterfaceTypes.
[ https://issues.apache.org/jira/browse/OPENJPA-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Sutter updated OPENJPA-2342: -- Fix Version/s: 2.3.0 Assignee: Kevin Sutter Consider modifying PCEnhancer.run to use serp.bytecode.BCClass.getDeclaredInterfaceNames instead of getDeclaredInterfaceTypes. -- Key: OPENJPA-2342 URL: https://issues.apache.org/jira/browse/OPENJPA-2342 Project: OpenJPA Issue Type: Improvement Components: Enhance Affects Versions: 2.2.2 Reporter: John Ross Assignee: Kevin Sutter Fix For: 2.3.0 Attachments: openjpa-2342.patch Caused by: openjpa-2.2.2-SNAPSHOT-r422266:1446295 nonfatal general error org.apache.openjpa.util.GeneralException: An error occurred while enhancing itemjpa.ItemJPA. Exception message: java.lang.ClassNotFoundException: org.apache.aries.proxy.weaving.WovenProxy at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:578) at org.apache.openjpa.enhance.PCClassFileTransformer.transform0(PCClassFileTransformer.java:153) at org.apache.openjpa.enhance.PCClassFileTransformer.transform(PCClassFileTransformer.java:126) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.transform(PersistenceProviderImpl.java:290) at org.apache.aries.jpa.container.weaving.impl.WrappingTransformer.transform(WrappingTransformer.java:80) at org.apache.aries.jpa.container.weaving.impl.JPAWeavingHook.weave(JPAWeavingHook.java:71) ... 48 more Caused by: java.lang.IllegalArgumentException: java.lang.ClassNotFoundException: org.apache.aries.proxy.weaving.WovenProxy at serp.util.Strings.toClass(Strings.java:164) at serp.util.Strings.toClass(Strings.java:108) at serp.bytecode.BCClass.getDeclaredInterfaceTypes(BCClass.java:740) at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:537) ... 53 more This issue occurs when the Apache Aries Proxy weaving hook gets called before the Apache Aries JPA weaving hook. Proxy weaves the class with the WovenProxy interface and adds the necessary dynamic package imports. JPA then gets called and uses PCEnhancer which, in turn, calls BCClass.getDeclaredInterfaceTypes, which ultimately calls Class.forName using the woven interface's name. The class loader is from the bundle whose class is being woven. Per the OSGi spec, dynamic imports do not take effect until after the entire weaving process is complete. Consequently, the bundle's class loader does not yet have visibility to the class. One solution to this, at least in the Aries case, is to order the weaving hook calls using the osgi service ranking property. However, all weaving hook services with potential conflicts may not be under the control of the same entity. Basically, PCEnhancer.run is using the information from BCClass to determine whether or not the class has already been woven. It's only interested in knowing if the PersistenceCapable interface is there. It seems that BCClass.getDeclaredInterfaceNames avoids the Class.forName call and could be used instead, particularly considering that only the class names are compared. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OPENJPA-1979) Regression for non-standard joins with constant column values
[ https://issues.apache.org/jira/browse/OPENJPA-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615681#comment-13615681 ] ASF subversion and git services commented on OPENJPA-1979: -- Commit 1461833 from [~ppod...@apache.org] [ https://svn.apache.org/r1461833 ] OPENJPA-1979: reference column name starting with single-quote *not* delimited as they have special semantics for non-standard constant join Regression for non-standard joins with constant column values -- Key: OPENJPA-1979 URL: https://issues.apache.org/jira/browse/OPENJPA-1979 Project: OpenJPA Issue Type: Bug Components: jdbc, kernel Affects Versions: 2.0.0-M1, 2.0.0 Reporter: Pinaki Poddar Attachments: OPENJPA-1979.patch.1.txt, Test-1979.zip The non-standard join can use constant column values by enclosing them in single-quote character. This behavior is regressed. The likely cause of this regression is new delimiting support for schema elements introduced in JPA 2.0. The constant column value used to be detected during schema definition based on the assumption of the name being enclosed in single-quote. Due to introduction of delimiting capability, the constant value is now enclosed in double-quote followed by a single-quote. The visible effect is failure to define schema for non-standard join with constant values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
