RE: [jira] Commented: (OPENJPA-245) Attach NEW and auto-increment identity
* If neither of the above cases apply, OpenJPA will check to see if an instance with the same primary key values exists in the database. If so, the object is considered detached. Otherwise, it is considered new. I could get OpenJPA to behave in this way (i.e. without a version or detachment) only when the entity class was annotated with @DetachedState(enabled=false) Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Aleksandar Likic [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 30, 2007 8:21 AM To: open-jpa-dev@incubator.apache.org Subject: RE: [jira] Commented: (OPENJPA-245) Attach NEW and auto-increment identity I think you are right, the new instance is probably created by new() followed by field-by-field copy of the state. But this is how any XML de-serialization works (in this case it is done by Weblogic web service implementation). This use case must be supported, and according to the documentation it should have been. I made my code working by introducing version id. This is something I had planned to do anyways, so for me it's not a big deal. However, I worked on projects where we had to deal with legacy DB schema that didn't allow us to have version id - and we didn't have a luxury to change the schema to support it. Regards, Aleksandar Likic Pinaki Poddar wrote: Hello Aleksandar, This use case is so common, I am surprised that nobody had encountered this problem before. OpenJPA documentation tells me it should be possible. If to be merged instance is a clone created by serialization+deserialization -- then OpenJPA detects the update even without any version field and does the right thing. I think your issue raised the use case where to be merged instance is a 'copy' of another persistent object created by Java new() followed by field-by-field copy of the state. This makes OpenJPA to decide the instance as a new instance rather than a detached instance. However, others may suggest ways to do what your use case requires. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Aleksandar Likic [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 29, 2007 2:08 PM To: open-jpa-dev@incubator.apache.org Subject: Re: [jira] Commented: (OPENJPA-245) Attach NEW and auto-increment identity From the documentation, I don't see that merge() requires a version field for it to function the way I want. The use case is simple - a web service that updates an existing record in database which doesn't have associated version id. This use case is so common, I am surprised that nobody had encountered this problem before. OpenJPA documentation tells me it should be possible. Here is copy/paste from OpenJPA documentation. Pay attention to the last bullet point (If neither of the above cases apply...). 1.2. Attach Behavior When attaching, OpenJPA uses several strategies to determine the optimal way to merge changes made to the detached instance. As you will see, these strategies can even be used to attach changes made to a transient instance which was never detached in the first place. * If the instance was detached and detached state is enabled, OpenJPA will use the detached state to determine the object's version and primary key values. In addition, this state will tell OpenJPA which fields were loaded at the time of detach, and in turn where to expect changes. Loaded detached fields with null values will set the attached instance's corresponding fields to null. * If the instance has a Version field, OpenJPA will consider the object detached if the version field has a non-default value, and new otherwise. When attaching null fields in these cases, OpenJPA cannot distinguish between a field that was unloaded and one that was intentionally set to null. In this case, OpenJPA will use the current detach state setting to determine how to handle null fields: fields that would have been included in the detached state are treated as loaded, and will in turn set the corresponding attached field to null. * If neither of the above cases apply, OpenJPA will check to see if an instance with the same primary key values exists in the database. If so, the object is considered detached. Otherwise, it is considered new. JIRA [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/OPENJPA-245?page=com.atlassian. j ira.plugin.system.issuetabpanels:comment-tabpanel#action_12499851 ] Pinaki Poddar commented on OPENJPA-245: --- merge() to identify that the the merged entity instance is not *truely* new but a version of a instance that is already persistent, the entity requires a version field. If the merged instance was a clone created out of serialization and desrialization, then OpenJPA will maintain the required bits to identify the difference between a truly new instance
[jira] Commented: (OPENJPA-245) Attach NEW and auto-increment identity
[
https://issues.apache.org/jira/browse/OPENJPA-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500235
]
Pinaki Poddar commented on OPENJPA-245:
---
An entity instance x which has been created by new() operator and carrying a
existing id (say idx) set by the user application is treated as detached by
merge() when the entity class is annotated with @DetachState(enabled=false).
Then merge() updates the existing database record with current state of x. If
it is not annotated with @DetachState(enabled=false), the instance x is trated
as a new instance, and if the entity is using auto-generated identity, a new
database record is created, ignoring the id set by the application. However, if
the entitymanager doing the merge() is already managing an instance with the
same identity idx then an EntityExists exception is raised.
The generated enhanced code differs based on @DetachedState setting.
So if the application has changed this setting, the entity must be enhanced
again.
Attach NEW and auto-increment identity
--
Key: OPENJPA-245
URL: https://issues.apache.org/jira/browse/OPENJPA-245
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 0.9.6, 0.9.7
Environment: jdk1.5.0_11, Win XP, Fedora Core 6, Postgres 8.1 (on
Fedora)
Reporter: Aleksandar Likic
Attachments: TestMerge.zip
According to documentation (1.2 Attach Behavior), when an entity instance is
NEW (never detached):
* If neither of the above cases apply, OpenJPA will check to see if an
instance with the same primary key values exists in the database. If so, the
object is considered detached. Otherwise, it is considered new.
This doesn't work for me - a new record in database is created on commit
instead of updating the existing one. The regular case -
detach/modify/attach works fine - the existing record is updated.
It is very easy to reproduce - just create a new instance of an entity,
assign an already existing primary key, call em.merge() and commit. A new
record will be created in database, with new, auto-generated primary key.
I stumbled on this trying to implement a web service that uses OpenJPA-based
backend. When servicing an update request, the web service instantiates a
NEW object (by performing XML de-serialization) and calls em.merge to update
the entity. A new record gets created instead of updating an existing one.
Entity class (START) --
package exaple;
public class Consumer implements java.io.Serializable {
private long id;
public long getId() {
return this.id;
}
public void setId(long id) {
this.id = id;
}
private java.lang.String firstName;
public java.lang.String getFirstName() {
return this.firstName;
}
public void setFirstName(java.lang.String firstName) {
this.firstName = firstName;
}
private java.lang.String lastName;
public java.lang.String getLastName() {
return this.lastName;
}
public void setLastName(java.lang.String lastName) {
this.lastName = lastName;
}
Entity class (END) --
persistence.xml (START) --
?xml version=1.0 encoding=UTF-8?
persistence xmlns=http://java.sun.com/xml/ns/persistence;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1.0
persistence-unit name=example transaction-type=RESOURCE_LOCAL
providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider
!-- We must enumerate each entity in the persistence unit --
classexample.Consumer/class
properties
property name=openjpa.jdbc.DBDictionary value=postgres/
property name=openjpa.ConnectionDriverName
value=org.postgresql.Driver/
property name=openjpa.ConnectionUserName value=app_user/
property name=openjpa.ConnectionPassword value=app_user/
property name=openjpa.ConnectionURL
value=jdbc:postgresql://localhost/alikic/
property name=openjpa.Log value=DefaultLevel=WARN,SQL=TRACE/
/properties
/persistence-unit
/persistence
persistence.xml (END) --
orm.xml (START) --
entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm
orm_1_0.xsd
version=1.0
entity class=example.Consumer
attributes
id name=id
generated-value strategy=IDENTITY/
/id
basic name=firstName
column name=first_name
[jira] Created: (OPENJPA-246) Interdependency of Enhancement, Detachment and Merge on detachment settings should be coherently captured
Interdependency of Enhancement, Detachment and Merge on detachment settings should be coherently captured - Key: OPENJPA-246 URL: https://issues.apache.org/jira/browse/OPENJPA-246 Project: OpenJPA Issue Type: Improvement Components: docs Reporter: Pinaki Poddar In OpenJPA, there is significant interplay between enhancement, detachment and merge operations to support a wide variety of use cases. Given that detach-modify-merge is a significant use case for multi-tier web applications built on OpenJPA, a comprehensive section that brings together how OpenJPA supports these wide variety of use cases with different detachment settings can be useful addition to the documentation. As JPA specification does not yet explicitly (i.e. via API) support detachment, these features are often OpenJPA extensions and hence such elaboration gains more usefulness. The current documentation does describe the configuration and semantics in sufficient details but such descriptions are distributed across different sections. The users often have to connect the dots for their specific use cases. The section should bring together following aspects : a) when entities are detached and how it is controlled (e.g. AutoDetach) b) what fields are detached (e.g. DetachState loaded/fetchgroups/all) c) what extra fields are added by the enhancer and how enhanced code differs based on configuration/annotation (e.g. @DetachState(enabled=true/false) d) how serialization compatibility is influenced by enhancement (e.g. whether client having access to openjpa librariers can determine whether a DetachStateManager can be associated with a detached instance) e) how the detached entity behaves (DetachStateManager) when detached (e.g. AccessUnloaded) f) how merge() determines whether an instance is detached or brand new (e.g. treatement of version field or a new instance with preassigned identity) g) performance impact on merge operation of differnt configuration choices -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-245) Attach NEW and auto-increment identity
[
https://issues.apache.org/jira/browse/OPENJPA-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pinaki Poddar updated OPENJPA-245:
--
Attachment: TestMerge.zip
Attached a test case that demonstates merge() behaviour of entities with or
without a version field and when the merged instance is a clone or a copy. A
clone is created by serialization+deserialization of the original persistent
instance. A copy is created by Java new() operator and then fields values are
set equal to the original persistent instance (including the primary key
field).
Thus we have four scenarios:
1. Unversioned + Copy
2. Unversioned + Clone
3. Versioned + Copy
4. Versioned + Clone
The first case originated this issue (at least that's what I gathered from the
description). The first case behaves 'rationally but non-intutively'. It
creates a new database record rather than updating the existing one. The
merge() operation does not see a versioned field, treats the argument instance
as a new instance, assigns a new identity (ignoring what the application has
set).
If the entity were using application identity, one would have encountered a
DuplicateKeyException of some sort, I presume but not tested here.
The rest three cases update the existing record. In the third case, the user
application has to copy the version field for merge() to treat the merged
instance 'correctly' i.e. as a update rather than an insert of a new record.
This seems to be the solution to the original use cse -- add a version field
and copy the version field to the merged instance.
Attach NEW and auto-increment identity
--
Key: OPENJPA-245
URL: https://issues.apache.org/jira/browse/OPENJPA-245
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 0.9.6, 0.9.7
Environment: jdk1.5.0_11, Win XP, Fedora Core 6, Postgres 8.1 (on
Fedora)
Reporter: Aleksandar Likic
Attachments: TestMerge.zip
According to documentation (1.2 Attach Behavior), when an entity instance is
NEW (never detached):
* If neither of the above cases apply, OpenJPA will check to see if an
instance with the same primary key values exists in the database. If so, the
object is considered detached. Otherwise, it is considered new.
This doesn't work for me - a new record in database is created on commit
instead of updating the existing one. The regular case -
detach/modify/attach works fine - the existing record is updated.
It is very easy to reproduce - just create a new instance of an entity,
assign an already existing primary key, call em.merge() and commit. A new
record will be created in database, with new, auto-generated primary key.
I stumbled on this trying to implement a web service that uses OpenJPA-based
backend. When servicing an update request, the web service instantiates a
NEW object (by performing XML de-serialization) and calls em.merge to update
the entity. A new record gets created instead of updating an existing one.
Entity class (START) --
package exaple;
public class Consumer implements java.io.Serializable {
private long id;
public long getId() {
return this.id;
}
public void setId(long id) {
this.id = id;
}
private java.lang.String firstName;
public java.lang.String getFirstName() {
return this.firstName;
}
public void setFirstName(java.lang.String firstName) {
this.firstName = firstName;
}
private java.lang.String lastName;
public java.lang.String getLastName() {
return this.lastName;
}
public void setLastName(java.lang.String lastName) {
this.lastName = lastName;
}
Entity class (END) --
persistence.xml (START) --
?xml version=1.0 encoding=UTF-8?
persistence xmlns=http://java.sun.com/xml/ns/persistence;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1.0
persistence-unit name=example transaction-type=RESOURCE_LOCAL
providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider
!-- We must enumerate each entity in the persistence unit --
classexample.Consumer/class
properties
property name=openjpa.jdbc.DBDictionary value=postgres/
property name=openjpa.ConnectionDriverName
value=org.postgresql.Driver/
property name=openjpa.ConnectionUserName value=app_user/
property name=openjpa.ConnectionPassword value=app_user/
property name=openjpa.ConnectionURL
value=jdbc:postgresql://localhost/alikic/
property name=openjpa.Log value=DefaultLevel=WARN,SQL=TRACE/
/properties
/persistence-unit
/persistence
RE: [jira] Created: (OPENJPA-245) Attach NEW and auto-increment identity
just create a new instance of an entity, assign an already existing
primary key
A new record will be created in database, with new, auto-generated
primary key.
What is the identity mechanicsm used by the entity class?
If the entity is using auto-generated identity then assigning an
already existing key is not recommneded.
If the entity is not using auto-generated, then assigning an existing
key *should* fail at commit with duplicate key exception.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Aleksandar Likic (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 27, 2007 9:05 AM
To: open-jpa-dev@incubator.apache.org
Subject: [jira] Created: (OPENJPA-245) Attach NEW and auto-increment
identity
Attach NEW and auto-increment identity
--
Key: OPENJPA-245
URL: https://issues.apache.org/jira/browse/OPENJPA-245
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 0.9.7, 0.9.6
Environment: jdk1.5.0_11, Win XP, Fedora Core 6, Postgres 8.1
(on Fedora)
Reporter: Aleksandar Likic
According to documentation (1.2 Attach Behavior), when an entity
instance is NEW (never detached):
* If neither of the above cases apply, OpenJPA will check to see if
an instance with the same primary key values exists in the database. If
so, the object is considered detached. Otherwise, it is considered new.
This doesn't work for me - a new record in database is created on commit
instead of updating the existing one. The regular case -
detach/modify/attach works fine - the existing record is updated.
It is very easy to reproduce - just create a new instance of an entity,
assign an already existing primary key, call em.merge() and commit. A
new record will be created in database, with new, auto-generated primary
key.
I stumbled on this trying to implement a web service that uses
OpenJPA-based backend. When servicing an update request, the web
service instantiates a NEW object (by performing XML de-serialization)
and calls em.merge to update the entity. A new record gets created
instead of updating an existing one.
Entity class (START) --
package exaple;
public class Consumer implements java.io.Serializable {
private long id;
public long getId() {
return this.id;
}
public void setId(long id) {
this.id = id;
}
private java.lang.String firstName;
public java.lang.String getFirstName() {
return this.firstName;
}
public void setFirstName(java.lang.String firstName) {
this.firstName = firstName;
}
private java.lang.String lastName;
public java.lang.String getLastName() {
return this.lastName;
}
public void setLastName(java.lang.String lastName) {
this.lastName = lastName;
}
Entity class (END) --
persistence.xml (START) --
?xml version=1.0 encoding=UTF-8? persistence
xmlns=http://java.sun.com/xml/ns/persistence;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1.0
persistence-unit name=example transaction-type=RESOURCE_LOCAL
providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provid
er
!-- We must enumerate each entity in the persistence unit --
classexample.Consumer/class
properties
property name=openjpa.jdbc.DBDictionary
value=postgres/
property name=openjpa.ConnectionDriverName
value=org.postgresql.Driver/
property name=openjpa.ConnectionUserName
value=app_user/
property name=openjpa.ConnectionPassword
value=app_user/
property name=openjpa.ConnectionURL
value=jdbc:postgresql://localhost/alikic/
property name=openjpa.Log
value=DefaultLevel=WARN,SQL=TRACE/
/properties
/persistence-unit
/persistence
persistence.xml (END) --
orm.xml (START) --
entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm
orm_1_0.xsd
version=1.0
entity class=example.Consumer
attributes
id name=id
generated-value strategy=IDENTITY/
/id
basic name=firstName
column name=first_name/
/basic
basic name=lastName
column name=last_name/
/basic
/attributes
/entity
/entity-mappings
orm.xml (END) --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
RE: Test failures
Is it just me, or is integration-test broken? Observed the same since did a 'svn switch' Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, May 24, 2007 4:07 PM To: open-jpa-dev@incubator.apache.org Subject: Test failures Is it just me, or is integration-test broken? [INFO] [INFO] Building OpenJPA JPA JDBC [INFO]task-segment: [integration-test] [INFO] ... Everything is fine until this. Something I'm doing wrong perhaps? Running org.apache.openjpa.persistence.relations.TestLRS 0 test INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 1 test INFO [main] openjpa.jdbc.JDBC - OpenJPA will now connect to the database to attempt to determine what type of database dictionary to use. To prevent this connection in the future, set your openjpa.jdbc.DBDictionary configuration property to the appropriate value for your database (see the documentation for available values). 2 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary (Apache Derby 10.2.2.0 - (485682) ,Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). 0 test INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 0 test INFO [main] openjpa.jdbc.JDBC - OpenJPA will now connect to the database to attempt to determine what type of database dictionary to use. To prevent this connection in the future, set your openjpa.jdbc.DBDictionary configuration property to the appropriate value for your database (see the documentation for available values). 2 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary (Apache Derby 10.2.2.0 - (485682) ,Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). 0 test INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 0 test INFO [main] openjpa.jdbc.JDBC - OpenJPA will now connect to the database to attempt to determine what type of database dictionary to use. To prevent this connection in the future, set your openjpa.jdbc.DBDictionary configuration property to the appropriate value for your database (see the documentation for available values). 1 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary (Apache Derby 10.2.2.0 - (485682) ,Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 0.205 sec FAILURE! testEMClear(org.apache.openjpa.persistence.relations.TestLRS) Time elapsed: 0.095 sec FAILURE! junit.framework.AssertionFailedError: expected:3 but was:6 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at junit.framework.Assert.assertEquals(Assert.java:207) at org.apache.openjpa.persistence.relations.TestLRS.assertLRS (TestLRS.java:92) at org.apache.openjpa.persistence.relations.TestLRS.testEMClear (TestLRS.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) 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 junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute (JUnitTestSet.java:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSe t(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute (AbstractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke
RE: Test failures
Yes, 'svn clean' was missing. $ svn switch /path/to/new/location $ mvn clean package runs successfully Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: Thursday, May 24, 2007 5:48 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Test failures That sounds like a non-clean database or something. What happens with a 'mvn clean' first? All tests are passing on my CI machine. -Patrick On 5/24/07, Pinaki Poddar [EMAIL PROTECTED] wrote: Is it just me, or is integration-test broken? Observed the same since did a 'svn switch' Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, May 24, 2007 4:07 PM To: open-jpa-dev@incubator.apache.org Subject: Test failures Is it just me, or is integration-test broken? [INFO] -- -- [INFO] Building OpenJPA JPA JDBC [INFO]task-segment: [integration-test] [INFO] -- -- ... Everything is fine until this. Something I'm doing wrong perhaps? Running org.apache.openjpa.persistence.relations.TestLRS 0 test INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 1 test INFO [main] openjpa.jdbc.JDBC - OpenJPA will now connect to the database to attempt to determine what type of database dictionary to use. To prevent this connection in the future, set your openjpa.jdbc.DBDictionary configuration property to the appropriate value for your database (see the documentation for available values). 2 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary (Apache Derby 10.2.2.0 - (485682) ,Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). 0 test INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 0 test INFO [main] openjpa.jdbc.JDBC - OpenJPA will now connect to the database to attempt to determine what type of database dictionary to use. To prevent this connection in the future, set your openjpa.jdbc.DBDictionary configuration property to the appropriate value for your database (see the documentation for available values). 2 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary (Apache Derby 10.2.2.0 - (485682) ,Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). 0 test INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 0 test INFO [main] openjpa.jdbc.JDBC - OpenJPA will now connect to the database to attempt to determine what type of database dictionary to use. To prevent this connection in the future, set your openjpa.jdbc.DBDictionary configuration property to the appropriate value for your database (see the documentation for available values). 1 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary (Apache Derby 10.2.2.0 - (485682) ,Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 0.205 sec FAILURE! testEMClear(org.apache.openjpa.persistence.relations.TestLRS) Time elapsed: 0.095 sec FAILURE! junit.framework.AssertionFailedError: expected:3 but was:6 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at junit.framework.Assert.assertEquals(Assert.java:207) at org.apache.openjpa.persistence.relations.TestLRS.assertLRS (TestLRS.java:92) at org.apache.openjpa.persistence.relations.TestLRS.testEMClear (TestLRS.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) 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 junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585
RE: [VOTE] move current release to 1.0.0-SNAPSHOT
+1 to make the current release 1.0.0-SNAPSHOT Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Wednesday, May 23, 2007 2:41 PM To: open-jpa-dev@incubator.apache.org Subject: [VOTE] move current release to 1.0.0-SNAPSHOT We recently discussed committing ourselves to the next release being OpenJPA 1.0.0. The general consensus seems to be in favor, so I'm putting it to a vote. +1 Make the current release be 1.0.0-SNAPSHOT, which indicates that the next released version will be 1.0.0 -1 Leave the current release to be 0.9.8-SNAPSHOT 0 Don't care This vote will remain open until 12pm PST on 5/26. I'll start the voting off by recording my vote: +1 Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Implied deletes
This semantics of implied deletion of elements from the database as they are removed from their collection in Java memory is supported by @ElementDependent annotation (not pure JPA but OpenJPA) http://incubator.apache.org/openjpa/docs/latest/manual/manual.html#depen dent Pinaki Poddar BEA Systems 415.402.7317 ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Phill Moran [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 22, 2007 3:23 PM To: open-jpa-dev@incubator.apache.org Subject: Implied deletes Does OPEN-JPA support implied deletes? Let me tell you of the scenario; if you have the proverbial magazine class that contains references to several article classes (1-* relationship, cascade-all) if you should remove one of the articles from the contained list and merge the resultant magazine class will the removed article class be automatically deleted? The alternative would be to remove the article class and delete it manually then merge the magazine class. Phill Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Exception while retrieving the data from database
@DiscriminatorColumn(discriminatorType=DiscriminatorType.CHAR)
@DiscriminatorValue(value=S)
The discriminator type is CHAR but the value is a String. How about
declaring the type as STRING of length 1?
@DiscriminatorColumn(discriminatorType=DiscriminatorType.STRING,
length=1)
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Praveen G [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 19, 2007 8:37 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Exception while retrieving the data from database
Hi,
I am having following two classes, modified the code as follows
@Entity
@Table(name = LOG_DB2)
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(discriminatorType=DiscriminatorType.CHAR)
@DiscriminatorValue(value=S)
public class A {
@Column(name = LOG_ID)
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
private long id;
@Column(name = TAG)
private String tag;
@Column(name = SUBTAG)
private String subtag;
@Column(name = HOST_NAME)
private String hostName;
@Entity
@Table(name = LOG_DB2)
@DiscriminatorValue(value=C)
public class B extends A {
@Column(name = INSTANCE_NAME)
private String instanceName;
@Column(name = DB2_TIMESTAMP)
private Timestamp db2Timestamp;
@Column(name = DB_ALIAS)
private String dbAlias;
@Column(name = DB_PARTITION)
private int partitionNum;
I am facing the problem while retriveing the data from the database, the
following is the code and highlighted the problem area in the code
em=ServiceLocator.getOpenJPASession(audit);
em.getTransaction().begin();
Query q = em.createQuery(select ad from B ad); ListB logs =
q.getResultList(); for (B l : logs) { System.out.println(Host Name is :
+l.getHostName()+ Instance Name is +l.getInstanceName());
em.remove(l); }
em.getTransaction().commit();
em.close();
The following error occurs
0.9.7-incubating nonfatal general error
org.apache.openjpa.persistence.PersistenceException: [IBM][CLI Driver]
CLI0112E Error in assignment. SQLSTATE=22005 at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.
java:3784)
at
org.apache.openjpa.jdbc.sql.DB2Dictionary.newStoreException(DB2Dictionar
y.java:373)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:97
)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:83
)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:59
)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreMana
ger.java:260)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingSt
oreManager.java:111)
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.jav
a:57)
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:876)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:834)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:756)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.ja
va:776)
at
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:257)
at
org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java
:2152)
at
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:251)
at
org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObj
ect(InstanceResultObjectProvider.java:59)
at
org.apache.openjpa.lib.rop.EagerResultList.init(EagerResultList.java:3
6)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1219)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:987)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:766)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:762)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:5
17)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:230)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:26
9)
at
com.vormetric.server.dao.audit.hibernate.AuditDAOImpl.purgeDebugMessages
(AuditDAOImpl.java:195)
at
com.vormetric.server.messageanalyzer.MessageAnalyzerManager.purgeDebugMe
ssages(MessageAnalyzerManager.java:113)
at
com.vormetric.server.mgmt.ConsoleManagement.purgeDebugMessages(ConsoleMa
nagement.java:675)
at
com.vormetric.server.mgmt.console.log.LogAnalyzerAction.execute(LogAnaly
zerAction.java:217)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestPr
ocessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
236)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:252
RE: Exception while retrieving the data from database
1. The code snippet and the class definitions as presented in the email
worked without error with MySQL. The error possibly in somewhere else.
2. The failure suggests NPE caused by JBoss not finding a class
(LongId?) -- can you switch type of A.id to long from Long and try?
3. Looks like your code is querying the extent of B and then deleting
each instance. Please note that JPA supports delete by query which
avoids fetching instances in memory before deleting them.
4. Instances of class B as described here will be stored in the same
table defined for A -- no need to specify it explictly
5. please post to open-jpa mailing list directly and *not* directly to
my mail address.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Praveen G [mailto:[EMAIL PROTECTED]
Sent: Friday, May 18, 2007 10:27 AM
To: Pinaki Poddar; open-jpa-dev@incubator.apache.org; Patrick Linskey
Subject: Exception while retrieving the data from database
Hello Pinaki/Patrick,
I am having following two classes
@Entity
@Table(name = LOG_DB2)
public class B extends A {
@Column(name = INSTANCE_NAME)
private String instanceName;
@Column(name = DB2_TIMESTAMP)
private Timestamp db2Timestamp;
@Column(name = DB_ALIAS)
private String dbAlias;
@Column(name = DB_PARTITION)
private int partitionNum;
@Entity
@Table(name = LOG_DB2)
@MappedSuperclass
public class A {
@Column(name = LOG_ID)
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
private Long id;
@Column(name = TAG)
private String tag;
@Column(name = SUBTAG)
private String subtag;
I am able to store the data into database successfully where as I am
facing the problem while retriveing the data from the database, the
following is the code and highlighted the problem area in the code
em=ServiceLocator.getOpenJPASession(pu1);
em.getTransaction().begin();
Query q = em.createQuery(select ad from B ad); for (B l :
(ListB)q.getResultList()) { System.out.println(Host Name is :
+l.getHostName()+ Instance Name is +l.getInstanceName());
em.remove(l); } em.getTransaction().commit();
The following error occurs
0.9.7-incubating nonfatal general error
org.apache.openjpa.persistence.PersistenceException: null at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:857)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:756)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.ja
va:776)
at
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:257)
at
org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java
:2152)
at
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:251)
at
org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObj
ect(InstanceResultObjectProvider.java:59)
at
org.apache.openjpa.lib.rop.EagerResultList.init(EagerResultList.java:3
6)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1219)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:987)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:766)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:762)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:5
17)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:230)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:26
9)
at
com.server.dao.audit.hibernate.AuditDAOImpl.purgeDebugMessages(AuditDAOI
mpl.java:196)
at
com.server.messageanalyzer.MessageAnalyzerManager.purgeDebugMessages(Mes
sageAnalyzerManager.java:113)
at
com.server.mgmt.ConsoleManagement.purgeDebugMessages(ConsoleManagement.j
ava:675)
at
com.server.mgmt.console.log.LogAnalyzerAction.execute(LogAnalyzerAction.
java:217)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestPr
ocessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
236)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:173)
at
com.server.mgmt.console.access.AuthorizationFilter.doFilter(Authorizatio
nFilter.java:70)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:173)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilte
r.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:202
RE: JNDI lookup in OpenJPA.
Hello, We are trying to understand the meaning of Enhancing the DTO object to Persistence capabilities as observed in the trace of the exception. OpenJPA needs to enhance the Java classes to be stored in a database. Enhancement means modification of original Java class bytecode with special instructions. The classes can be enhanced in following ways: 1. Build-time: After the Java class has been compiled, run $ java org.apache.openjpa.enhance.PCEnhancer -properties path to persistence.xml The enhancer program supports several other options (refer http://incubator.apache.org/openjpa/docs/latest/manual/manual.html#ref_g uide_pc_enhance) This will overwrite the bytecodes of the Java classes (you can simply notice them by growing size of *.class files or disassemble through javap or jad to see what code/methods have been added to the original). The same enhancer can be invoked through an Ant task to integrate the enhancement step in build/package/deploy process. 2. Runtime: Invoke Java runtime of your OpenJPA application with -javaagent as follows $ java -agent /path/to/openjpa.jar com.acme.MyOpenJPAApplication -javaagent works only with Java 1.5 or later. Also recommended that you enumerate all the persistent Java classes in class in persistence.xml e.g. persisetnce-unit name=... classcom.acme.MyPOJO1/class classcom.acme.MyPOJO2/class .. /persietnec-unit Pinaki Poddar ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Murali [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 10:30 PM To: Patrick Linskey; open-jpa-dev@incubator.apache.org Cc: Murali Adiraju; Deven Kalra; G.S.S. Prabhakar; Praveen G; Budigam Srinivas Rao Subject: Re: JNDI lookup in OpenJPA. Hi Patrick Linskey, We are not writing the OpenJPA code in EJB. Our Application is basically using Hibernate code for persistence D/B operations. Since, Hibernate is having LGPL licensing terms we are trying to replace Hibernate with OpenJPA which is not having any Licensing issues. We are able to create EntityManagerFactory EntityManager instances without going for JNDI lookup operation. We used the following approach: EntityManagerFactory emFactory = Persistence.createEntityManagerFactory(puName,System.getProperties()); EntityManager session = emFactory.createEntityManager(); But we are facing problems while persisting the DTO object. Following the trace of the exception that we have encountered: 2007-05-16 22:05:39,796 ERROR [com.receivables.server.dao.host.hibernate.HostGroupDAOImpl] The Security Server failed to persist data into the repository database. Refer to server.log for details. 0.9.7-incubating nonfatal user error org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance [EMAIL PROTECTED]2; name-test1; description-test1memberHosts-0policies-0] to PersistenceCapable failed. Ensure that it has been enhanced. FailedObject: [EMAIL PROTECTED]2; name-test1; description-test1memberHosts-0policies-0] at org.apache.openjpa.kernel.BrokerImpl.assertPersistenceCapable(BrokerImpl .java:4271) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2373) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2233) at org.apache.openjpa.kernel.DelegatingBroker.persist(DelegatingBroker.java :1010) at org.apache.openjpa.persistence.EntityManagerImpl.persist(EntityManagerIm pl.java:541) at com.receivables.server.dao.host.hibernate.HostGroupDAOImpl.create(HostGr oupDAOImpl.java:113) at com.receivables.server.host.HostGroupManager.createHostGroup(HostGroupMa nager.java:87) at com.receivables.server.mgmt.ConsoleManagement.createHostGroup(ConsoleMan agement.java:243) at com.receivables.server.mgmt.console.host.HostGroupAddAction.execute(Host GroupAddAction.java:92) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestPr ocessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java: 236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:173
RE: Entity creation at Runtime
You can use Serp -- a bytecode manipulation library -- (http://serp.sourceforge.net/). OpenJPA itself uses it to enhance class files. To enhance the dynamically defined class and register it to OpenJPA persistence unit requires few considerations. The attached example demonstrates these steps with a simple example that a) defines a class dynamically b) enhances c) defines database mapping for it d) pouplates instance of the defined class and finally persists it. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: James Hang [mailto:[EMAIL PROTECTED] Sent: Monday, May 14, 2007 1:18 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Entity creation at Runtime Thanks for the reply Marc. Is there a third party tool that can generate classes with annotations? Or is there something in OpenJPA that can do that? I noticed a CodeGenerator class that can generate classes from metadata. Can I use that? I'll take a look at the PCClassFileTransformer class like you suggested. Thanks for your help! James -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Monday, May 14, 2007 10:30 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Entity creation at Runtime James- It should be possible. The easiest way (and the most implementation- agnostic) would be to simply generate the classes with the appropriate mapping annotations, and then just load them at runtime. The somewhat tricky part would be to ensure they get enhanced by the system when they are loaded. You could just run the - javaagent:openjpa.jar flag with no arguments, and I believe it will scan all loaded classes for annotations, but that can slow things down quite a bit. A faster solution would be to run your generated classes through the enhancer. Take a look at the code for org.apache.openjpa.enhance.PCClassFileTransformer ... if you can't use that directly, then it might be good to use as a starting point. On May 14, 2007, at 10:00 AM, James Hang wrote: Hi, I'm curious if it's possible to create and map new entities at Runtime? We have an application which allows users to design new data models at runtime. When new tables are being created in the database, we would like to make OpenJPA aware of them. We are currently doing this in Hibernate by generating the POJO classes dynamically using CGLIB, adding dynamically generated xml mappings to the Hibernate runtime configuration and re-initializing the SessionFactory. Is there a way to do something similar in OpenJPA? Thanks, James Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: [VOTE] Graduate from Incubation
+1 Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Craig L Russell [mailto:[EMAIL PROTECTED] Sent: Thursday, May 03, 2007 9:22 AM To: open-jpa-dev@incubator.apache.org Subject: [VOTE] Graduate from Incubation This vote is to send the attached draft board resolution to the incubator for the purpose of graduation from the incubator to the Apache OpenJPA project. +1 We're ready; let's graduate 0 Don't care -1 Let's wait Establish the Apache OpenJPA project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as Apache OpenJPA, related to the implementation of object persistence, including, but not limited to, Java Persistence API, for distribution at no charge to the public; NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the OpenJPA PMC be and hereby is charged with the creation and maintenance of Apache OpenJPA; and be it further RESOLVED, that the office of Vice President, Apache OpenJPA be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the OpenJPA PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache OpenJPA PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the OpenJPA PMC: Eddie O'Neil[EMAIL PROTECTED] Geir Magnusson Jr. [EMAIL PROTECTED] Brian McCallister [EMAIL PROTECTED] Patrick Linskey [EMAIL PROTECTED] Craig Russell [EMAIL PROTECTED] Kevin Sutter[EMAIL PROTECTED] Abe White [EMAIL PROTECTED] Marc Prud'hommeaux [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Craig Russell be appointed to the office of Vice President, Apache OpenJPA, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial OpenJPA PMC be and hereby is tasked with the migration and rationalization of the Apache Incubator OpenJPA podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator OpenJPA podling and encumbered upon the Apache Incubator PMC are hereafter discharged. Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Open JPA error-Could not locate metadata for the class using alias
Persistent Java classes when used in Query use an alias (which is, be
deafult, the unqualified name of the Java class). However, the alias is
known to the runtime once the Java class is loaded in to JVM. When the
very first JPA operation is a query and the persistence unit does not
explictly declare all the persistent classes, the runtime is not yet
aware of/registered the aliases. Hence the error.
possible resolution:
a) declare the persistent classes in class tag of persistence.xml
b) load the class before using it -- e.g. call
Class.forName(a.b.c.MyClass)
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: saidulu chitipolu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 11, 2007 1:23 PM
To: open-jpa-dev@incubator.apache.org
Subject: Open JPA error-Could not locate metadata for the class using
alias
Hi,
I am trying to run standalone application access the database using
spring ,openjpa.
part of code in main method
EntityManagerFactory factory =
Persistence.createEntityManagerFactory(tsf);
EntityManager em = factory.createEntityManager();
System.out.println(--/ +em);
Query q = em.createQuery(select m from AbstractItemEntity m);
ListAbstractItemEntity absEntity=q.getResultList();
facing the problem at
Query q = em.createQuery(select m from AbstractItemEntity m);
we have persistance.xml and orm files.
Log is as like below
your earliest suggetions are valuable
110 INFO [main] openjpa.Runtime - Starting OpenJPA 0.9.6-incubating
422 INFO [main] openjpa.jdbc.JDBC - Using dictionary class
org.apache.openjpa.jdbc.sql.OracleDictionary.
766 INFO [main] openjpa.MetaData - Found 10 classes with metadata
in 31 milliseconds.
--/ [EMAIL PROTECTED]
Exception in thread main 4|true|0.9.6-incubating
org.apache.openjpa.persistence.ArgumentException: Could not locate
metadata for the class using alias AbstractItemEntity. Registered
alias mappings: {AbstractItemEntity=null}
at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepositor
y.java:343)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JP
QLExpressionBuilder.java:164)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaDat
a(JPQLExpressionBuilder.java:142)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaDat
a(JPQLExpressionBuilder.java:211)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaDat
a(JPQLExpressionBuilder.java:181)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JP
QLExpressionBuilder.java:174)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpr
essionBuilder.java:61)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate
(JPQLExpressionBuilder.java:1657)
at
org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:52)
at
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(E
xpressionStoreQuery.java:145)
at
org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:642)
at
org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:
623)
at
org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java
:589)
at
org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:65
1)
at
org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1464)
at
org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.j
ava:120)
at
org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:202)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:25
1)
at com.symcor.sis.tecp.dao.ExecuteDB.main(ExecuteDB.java:35)
-
Check out what you're missing if you're not on Yahoo! Messenger
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
RE: Testing an OpenJPA module
Hello Craig, Done. Thanks for your advice. Please review: https://glassfish.dev.java.net/issues/show_bug.cgi?id=2814 Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 5:11 PM To: open-jpa-dev@incubator.apache.org Cc: cmp-dev Subject: Re: Testing an OpenJPA module Hi Pinaki, On Apr 10, 2007, at 6:44 PM, Pinaki Poddar wrote: provide a patch. Will such a patch be given to Glassfish project? But some kind of committer-level privilege will be required, i suppose. have added few more informative messages to distinguish between different ways persistence unit creation/ lookup can fail. please advise on how to proceed on contributing a patch. This is great. Can you please file a Glassfish/persistence issue in their issue tracker and attach your patch? If you have trouble doing this, I'll be glad to help some more... Thanks! Craig Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 4:14 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module FYI, Persistence is an open source project at Glassfish. Anyone, even an OpenJPA contributor, who wants to contribute to the project for example to improve the error messages, is welcome to look at the sources and provide a patch. I know people who will be happy to commit usability patches. ;-) Craig On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote: The error message could have been more specific in the following way: a) no META-INF/persistence.xml has not been found in classpath b) META-INF/persistence.xml has been found but there is no 'ode- store' unit defined in it. c) META-INF/persistence.xml has been found but provider can not be loaded/invoked When I first encountered this error, my interpreation was (b) from the way the message was worded. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski Sent: Tuesday, April 10, 2007 2:52 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module On 4/10/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Glad you got it fixed. It's annoying that javax.persistence.Persistence doesn't provide more of a clue as to why it failed. I wonder what else you'd like to see other than what's already printed out? It tells exactly why it's failed - No Persistence provider for EntityManager named ode-store is just a JPA version of NoClassDefFoundError in pure Java. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Testing an OpenJPA module
The error message could have been more specific in the following way: a) no META-INF/persistence.xml has not been found in classpath b) META-INF/persistence.xml has been found but there is no 'ode-store' unit defined in it. c) META-INF/persistence.xml has been found but provider can not be loaded/invoked When I first encountered this error, my interpreation was (b) from the way the message was worded. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski Sent: Tuesday, April 10, 2007 2:52 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module On 4/10/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Glad you got it fixed. It's annoying that javax.persistence.Persistence doesn't provide more of a clue as to why it failed. I wonder what else you'd like to see other than what's already printed out? It tells exactly why it's failed - No Persistence provider for EntityManager named ode-store is just a JPA version of NoClassDefFoundError in pure Java. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Testing an OpenJPA module
provide a patch. Will such a patch be given to Glassfish project? But some kind of committer-level privilege will be required, i suppose. have added few more informative messages to distinguish between different ways persistence unit creation/ lookup can fail. please advise on how to proceed on contributing a patch. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 4:14 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module FYI, Persistence is an open source project at Glassfish. Anyone, even an OpenJPA contributor, who wants to contribute to the project for example to improve the error messages, is welcome to look at the sources and provide a patch. I know people who will be happy to commit usability patches. ;-) Craig On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote: The error message could have been more specific in the following way: a) no META-INF/persistence.xml has not been found in classpath b) META-INF/persistence.xml has been found but there is no 'ode-store' unit defined in it. c) META-INF/persistence.xml has been found but provider can not be loaded/invoked When I first encountered this error, my interpreation was (b) from the way the message was worded. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski Sent: Tuesday, April 10, 2007 2:52 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module On 4/10/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Glad you got it fixed. It's annoying that javax.persistence.Persistence doesn't provide more of a clue as to why it failed. I wonder what else you'd like to see other than what's already printed out? It tells exactly why it's failed - No Persistence provider for EntityManager named ode-store is just a JPA version of NoClassDefFoundError in pure Java. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Errors with 0.9.7
kodo.conf.KodoProductDerivation.beforeConfigurationLoad(KodoProductDeriv ation.java:93) Is Kodo available in your runtime environment or only OpenJPA? The stack trace suggests that you have a Kodo installation. Please elaborate the runtime environment with versions of OpenJPA, Kodo, Spring you have been using. Also can you post AbstractTransactionalCommonSpringBase.xml? Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: yangdq [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 2:31 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Errors with 0.9.7 Here is the stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [spring/AbstractTransactionalCommonSpringBase.xml]: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: org/apache/openjpa/util/ProxyArrayList Caused by: java.lang.NoClassDefFoundError: org/apache/openjpa/util/ProxyArrayList at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at kodo.profile.proxies.ProfilingProxyManager.clinit(ProfilingProxyManage r.java:20) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:164) at kodo.conf.KodoProductDerivation.class$(KodoProductDerivation.java:31) at kodo.conf.KodoProductDerivation.beforeConfigurationLoad(KodoProductDeriv ation.java:93) at org.apache.openjpa.lib.conf.ProductDerivations.beforeConfigurationLoad(P roductDerivations.java:176) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigura tionImpl.java:486) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigura tionImpl.java:154) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigura tionImpl.java:145) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerI mpl.init(PersistenceProviderImpl.java:124) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerI mpl.init(PersistenceProviderImpl.java:116) at org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEn tityManagerFactory(PersistenceProviderImpl.java:93) at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.creat eNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java: 204) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterProper tiesSet(AbstractEntityManagerFactoryBean.java:242) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1118) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1085) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObjec t(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.g etSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.get BeansOfType(DefaultListableBeanFactory.java:236) at org.springframework.beans.factory.support.DefaultListableBeanFactory.get BeansOfType(DefaultListableBeanFactory.java:225) at org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingA ncestors(BeanFactoryUtils.java:205) at org.springframework.beans.factory.BeanFactoryUtils.beanOfTypeIncludingAn cestors(BeanFactoryUtils.java:292) at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcess or.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcesso r.java:411
RE: composite ID w/ another composite ID as a field
i can also pass along a maven2 project
Can you post the Java source of the test case and domain classes for us
to reproduce the error?
afaik, Application identity classes like PageId are not enhanced in
current versions, they used to be.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 11:57 AM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID w/ another composite ID as a field
thanks pinaki,
as a test, i removed Page.book as an @Id, and made the corresponding
change in PageId (removed the book field of type PageId). this caused
the class cast exception below to go away. so, it does appear to have
some relation of to the use of the composite ID within a composite ID,
although you're right it might be a completely different issue.
this is with a trunk (as of this morning) build of openjpa.
i have attached the log you asked for. nothing stood out. i can also
pass along a maven2 project that contains the test case that fails if
that helps. i can't see to attach it here directly though as apache's
spam filter doesn't like it. let me know.
thanks again.
Pinaki Poddar [EMAIL PROTECTED] wrote:
Jeff,
1. The errors look rather unrelated to original problem of
composite
id.
2. The errors apparently caused by enviroment setup, so please
a) get a clean 0.9.7 openjpa (either building locally from the
source, or pre-built jars from the openjpa web-site)
b) if the error persists, report with trace-level logging
(property name=openjpa.Log value=DefaultLevel=TRACE/
and complete stack trace.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 4:12 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID w/ another composite ID as a field
thanks pinaki,
after making those changes, on 0.9.6, i get:
Caused by: java.lang.ClassCastException:
org.apache.openjpa.util.ObjectId
at com.mycompany.book.Page.pcCopyKeyFieldsToObjectId(Page.java)
at
org.apache.openjpa.util.ApplicationIds.create(ApplicationIds.java:383)
at
org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2349)
i built the trunk locally, and mvn installed it into my local
repository. when i run against it, i get:
Caused by: java.lang.RuntimeException: There were errors
initializing
your configuration: org.apache.openjpa.lib.util.ParseException:
Instantiation of plugin QueryCompilationCache with value
true caused
an error java.lang.IllegalArgumentException:
java.lang.ClassNotFoundException:
org.apache.openjpa.util.CacheMap. The
alias or class name may have been misspelled (as it closely
matches the
valid plugin alias true), or the class may not be available in
the
class path. Valid aliases for this plugin are: [all, false,
true]
followed by:
Caused by: java.lang.IllegalArgumentException:
java.lang.ClassNotFoundException:
org.apache.openjpa.util.CacheMap
at serp.util.Strings.toClass(Strings.java:211)
at serp.util.Strings.toClass(Strings.java:140)
at
org.apache.openjpa.lib.conf.Configurations.newInstance(Configurations.ja
va:191)
are there known issues w/ 0.9.7? what i don't understand is that
...CacheMap is in the sample place, in the same JAR as w/ the
0.9.6
dependency, just in my local repository.
also odd is that i only see the one info message during
enhancement:
[java] 1268 book INFO [main] openjpa.Tool - No targets were
given. Running on all classes in your persistent classes list,
or all
metadata files in classpath directories if you have not listed
your
persistent classes. Use -help to display tool usage information.
no details are printed about the classes being enhanced.
obviously this
was working in version 0,9.6.
any ideas?
Pinaki Poddar wrote: Hello Jeff,
OpenJPA supports the cited example where Page using a composite
ID which
in turn refers to Book's composite ID.
Book/Page/Library classes work with
a) openjpa-0.9.7 (do not know whether observed errors are due to
usage
of earlier 0.9.6 version)
b) following modifications in Page.book field (with a + sign)
@Id
@Column(nullable = false)
@ManyToOne (cascade = CascadeType.ALL)
+ @JoinColumns({
+ @JoinColumn(name=book_library_LIBRARY_NAME,
referencedColumnName
RE: composite ID w/ another composite ID as a field
Hello Jeff,
OpenJPA supports the cited example where Page using a composite ID which
in turn refers to Book's composite ID.
Book/Page/Library classes work with
a) openjpa-0.9.7 (do not know whether observed errors are due to usage
of earlier 0.9.6 version)
b) following modifications in Page.book field (with a + sign)
@Id
@Column(nullable = false)
@ManyToOne (cascade = CascadeType.ALL)
+ @JoinColumns({
+ @JoinColumn(name=book_library_LIBRARY_NAME,
referencedColumnName=library_LIBRARY_NAME),
+ @JoinColumn(name=book_BOOK_NAME,
referencedColumnName=BOOK_NAME)
})
private Book book;
where the JoinColumns specification refers to following schema (as per
your Page/Book/Library class annotations):
mysql desc book;
+--+--+--+-+-+---+
| Field| Type | Null | Key | Default | Extra |
+--+--+--+-+-+---+
| library_LIBRARY_NAME | varchar(255) | NO | PRI | NULL| |
| BOOK_NAME| varchar(255) | NO | PRI | NULL| |
+--+--+--+-+-+---+
mysql desc page;
+---+--+--+-+-+-
--+
| Field | Type | Null | Key | Default |
Extra |
+---+--+--+-+-+-
--+
| book_library_LIBRARY_NAME | varchar(255) | NO | PRI | NULL|
|
| book_BOOK_NAME| varchar(255) | NO | PRI | NULL|
|
| PAGE_NUMBER | int(11) | NO | PRI | NULL|
|
+---+--+--+-+-+-
--+
Without explicitly naming the join columns, following error is
generated:
Caused by: 4|true|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.ArgumentException: crxxx.Page.book does
not supply a name for at least one declared column. Since this mapping
can involve multiple columns or uses constant joins, each column must
give either its name or a non-constant target.
at
org.apache.openjpa.jdbc.meta.MappingInfo.mergeJoinColumn(MappingInfo.jav
a:1372)
at
org.apache.openjpa.jdbc.meta.MappingInfo.createJoins(MappingInfo.java:11
86)
at
org.apache.openjpa.jdbc.meta.MappingInfo.createForeignKey(MappingInfo.ja
va:948)
at
org.apache.openjpa.jdbc.meta.ValueMappingInfo.getTypeJoin(ValueMappingIn
fo.java:101)
at
org.apache.openjpa.jdbc.meta.strats.RelationFieldStrategy.map(RelationFi
eldStrategy.java:144)
at
org.apache.openjpa.jdbc.meta.FieldMapping.setStrategy(FieldMapping.java:
117)
at
org.apache.openjpa.jdbc.meta.RuntimeStrategyInstaller.installStrategy(Ru
ntimeStrategyInstaller.java:77)
at
org.apache.openjpa.jdbc.meta.FieldMapping.resolveMapping(FieldMapping.ja
va:435)
at
org.apache.openjpa.jdbc.meta.FieldMapping.resolve(FieldMapping.java:400)
at
org.apache.openjpa.jdbc.meta.ClassMapping.resolveNonRelationMappings(Cla
ssMapping.java:810)
at
org.apache.openjpa.jdbc.meta.MappingRepository.prepareMapping(MappingRep
ository.java:316)
at
org.apache.openjpa.meta.MetaDataRepository.preMapping(MetaDataRepository
.java:602)
at
org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.ja
va:489)
... 24 more
NestedThrowables:
4|true|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.ArgumentException: Field
crxxx.Book.pages declares crxxx.Page.book as its mapped-by field,
but this field is not a direct relation.
at
org.apache.openjpa.jdbc.meta.strats.RelationToManyInverseKeyFieldStrateg
y.map(RelationToManyInverseKeyFieldStrategy.java:123)
at
org.apache.openjpa.jdbc.meta.strats.RelationCollectionInverseKeyFieldStr
ategy.map(RelationCollectionInverseKeyFieldStrategy.java:92)
at
org.apache.openjpa.jdbc.meta.FieldMapping.setStrategy(FieldMapping.java:
117)
at
org.apache.openjpa.jdbc.meta.RuntimeStrategyInstaller.installStrategy(Ru
ntimeStrategyInstaller.java:77)
at
org.apache.openjpa.jdbc.meta.FieldMapping.resolveMapping(FieldMapping.ja
va:435)
at
org.apache.openjpa.jdbc.meta.FieldMapping.resolve(FieldMapping.java:400)
at
org.apache.openjpa.jdbc.meta.ClassMapping.resolveMapping(ClassMapping.ja
va:781)
at
org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1570)
...
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 12:42 PM
To: open-jpa-dev@incubator.apache.org
Subject: composite ID w/ another composite ID as a field
say i have Library, Book, and Page classes. a Library has many Books,
and a Book has many Pages. A Library's ID is it's name (simple). A
Book's ID is a composite of it's name and it's owning Library's name
(bidirectional relationship). A Page's ID is a composite of it's number
and it's owning Book's ID, a BookID.
so
RE: composite ID w/ another composite ID as a field
Jeff,
1. The errors look rather unrelated to original problem of composite
id.
2. The errors apparently caused by enviroment setup, so please
a) get a clean 0.9.7 openjpa (either building locally from the
source, or pre-built jars from the openjpa web-site)
b) if the error persists, report with trace-level logging
(property name=openjpa.Log value=DefaultLevel=TRACE/
and complete stack trace.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 4:12 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID w/ another composite ID as a field
thanks pinaki,
after making those changes, on 0.9.6, i get:
Caused by: java.lang.ClassCastException:
org.apache.openjpa.util.ObjectId
at com.mycompany.book.Page.pcCopyKeyFieldsToObjectId(Page.java)
at
org.apache.openjpa.util.ApplicationIds.create(ApplicationIds.java:383)
at
org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2349)
i built the trunk locally, and mvn installed it into my local
repository. when i run against it, i get:
Caused by: java.lang.RuntimeException: There were errors initializing
your configuration: org.apache.openjpa.lib.util.ParseException:
Instantiation of plugin QueryCompilationCache with value true caused
an error java.lang.IllegalArgumentException:
java.lang.ClassNotFoundException: org.apache.openjpa.util.CacheMap. The
alias or class name may have been misspelled (as it closely matches the
valid plugin alias true), or the class may not be available in the
class path. Valid aliases for this plugin are: [all, false, true]
followed by:
Caused by: java.lang.IllegalArgumentException:
java.lang.ClassNotFoundException: org.apache.openjpa.util.CacheMap
at serp.util.Strings.toClass(Strings.java:211)
at serp.util.Strings.toClass(Strings.java:140)
at
org.apache.openjpa.lib.conf.Configurations.newInstance(Configurations.ja
va:191)
are there known issues w/ 0.9.7? what i don't understand is that
...CacheMap is in the sample place, in the same JAR as w/ the 0.9.6
dependency, just in my local repository.
also odd is that i only see the one info message during enhancement:
[java] 1268 book INFO [main] openjpa.Tool - No targets were
given. Running on all classes in your persistent classes list, or all
metadata files in classpath directories if you have not listed your
persistent classes. Use -help to display tool usage information.
no details are printed about the classes being enhanced. obviously this
was working in version 0,9.6.
any ideas?
Pinaki Poddar [EMAIL PROTECTED] wrote: Hello Jeff,
OpenJPA supports the cited example where Page using a composite ID which
in turn refers to Book's composite ID.
Book/Page/Library classes work with
a) openjpa-0.9.7 (do not know whether observed errors are due to usage
of earlier 0.9.6 version)
b) following modifications in Page.book field (with a + sign)
@Id
@Column(nullable = false)
@ManyToOne (cascade = CascadeType.ALL)
+ @JoinColumns({
+ @JoinColumn(name=book_library_LIBRARY_NAME,
referencedColumnName=library_LIBRARY_NAME),
+ @JoinColumn(name=book_BOOK_NAME,
referencedColumnName=BOOK_NAME)
})
private Book book;
where the JoinColumns specification refers to following schema (as per
your Page/Book/Library class annotations):
mysql desc book;
+--+--+--+-+-+---+
| Field| Type | Null | Key | Default | Extra |
+--+--+--+-+-+---+
| library_LIBRARY_NAME | varchar(255) | NO | PRI | NULL| |
| BOOK_NAME| varchar(255) | NO | PRI | NULL| |
+--+--+--+-+-+---+
mysql desc page;
+---+--+--+-+-+-
--+
| Field | Type | Null | Key | Default |
Extra |
+---+--+--+-+-+-
--+
| book_library_LIBRARY_NAME | varchar(255) | NO | PRI | NULL|
|
| book_BOOK_NAME| varchar(255) | NO | PRI | NULL|
|
| PAGE_NUMBER | int(11) | NO | PRI | NULL|
|
+---+--+--+-+-+-
--+
Without explicitly naming the join columns, following error is
generated:
Caused by: 4|true|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.ArgumentException: crxxx.Page.book does
not supply a name for at least one declared column. Since this mapping
can involve multiple columns or uses constant joins, each column must
give either its name or a non-constant target.
at
org.apache.openjpa.jdbc.meta.MappingInfo.mergeJoinColumn(MappingInfo.jav
a:1372)
at
org.apache.openjpa.jdbc.meta.MappingInfo.createJoins(MappingInfo.java:11
86
RE: error building openjpa
Some of the attendees in a traininng course also experienced the same
error involving SurefireBooter.
The solution was to run mvn package -Dtest=false target few (3, in
this case) times.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of
Marc Prud'hommeaux
Sent: Wednesday, March 28, 2007 3:47 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: error building openjpa
That's a pretty weird error ... it looks more like Maven isn't installed
correctly. Are you able to build any other projects using maven?
If you re-install maven and delete (or move aside) your ~/.m2/
directory, do you still get the error?
On Mar 28, 2007, at 12:24 AM, Xibin Zeng wrote:
Hi -
I just downloaded the source through svn and failed at building
openjpa. It failed at a NoClassDefFoundError for SurefireBooter. What
did I miss?
This is the output:
$ mvn package -Dtest=false
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] OpenJPA
[INFO] OpenJPA Utilities
[INFO] OpenJPA Kernel
[INFO] OpenJPA JDBC
[INFO] OpenJPA XML Store
[INFO] OpenJPA Kernel 1.5
[INFO] OpenJPA JDBC 1.5
[INFO] OpenJPA JPA
[INFO] OpenJPA JPA JDBC
[INFO] OpenJPA Aggregate Jar
[INFO] OpenJPA Persistence Examples
[INFO] OpenJPA Distribution
[INFO] OpenJPA Integration Tests
[INFO] OpenJPA Examples Integration Tests
[INFO] OpenJPA JPA TCK Integration Tests
[INFO]
--
---
[INFO] Building OpenJPA
[INFO]task-segment: [package]
[INFO]
--
---
[INFO] [site:attach-descriptor]
[INFO]
--
---
[INFO] Building OpenJPA Utilities
[INFO]task-segment: [package]
[INFO]
--
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date [INFO]
[antrun:run {execution: set subversion revision}] [INFO] Executing
tasks
[echo] Revision: 406193:523071
[INFO] Executed tasks
[INFO] [antrun:run {execution: delete sun.misc.Perf}] [INFO] Executing
tasks [INFO] Executed tasks [INFO] [resources:testResources] [INFO]
Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date [INFO]
[surefire:test] [INFO] Surefire report directory:
c:\Development\openjpa\openjpa-lib\target\sure
orts
[INFO] Building jar: c:\DOCUME~1\xibin\LOCALS~1\Temp
\surefirebooter17408.jar
java.lang.NoClassDefFoundError:
org/apache/maven/surefire/booter/SurefireBooter
Exception in thread main
[INFO]
--
--
[ERROR] BUILD FAILURE
[INFO]
--
--
[INFO] There are test failures.
[INFO]
--
--
[INFO] For more information, run Maven with the -e switch [INFO]
--
--
[INFO] Total time: 6 seconds
[INFO] Finished at: Wed Mar 28 00:09:14 PDT 2007 [INFO] Final Memory:
8M/15M [INFO]
--
--
Thanks
- Xibin
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
RE: error building openjpa
After the third execution of mvn package -Dtest=false
the target succeeded in creating the openjpa jars and zips.
The attendee mentioned that he had run svn update before building.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 4:17 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: error building openjpa
What did that solution accomplish? It sounds like the .m2 repository was
out-of-date or something.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
-Original Message-
From: Pinaki Poddar [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 1:47 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: error building openjpa
Some of the attendees in a traininng course also experienced the same
error involving SurefireBooter.
The solution was to run mvn package -Dtest=false target few (3, in
this case) times.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf
Of Marc Prud'hommeaux
Sent: Wednesday, March 28, 2007 3:47 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: error building openjpa
That's a pretty weird error ... it looks more like Maven isn't
installed correctly. Are you able to build any other projects using
maven?
If you re-install maven and delete (or move aside) your ~/.m2/
directory, do you still get the error?
On Mar 28, 2007, at 12:24 AM, Xibin Zeng wrote:
Hi -
I just downloaded the source through svn and failed at building
openjpa. It failed at a NoClassDefFoundError for
SurefireBooter. What
did I miss?
This is the output:
$ mvn package -Dtest=false
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] OpenJPA
[INFO] OpenJPA Utilities
[INFO] OpenJPA Kernel
[INFO] OpenJPA JDBC
[INFO] OpenJPA XML Store
[INFO] OpenJPA Kernel 1.5
[INFO] OpenJPA JDBC 1.5
[INFO] OpenJPA JPA
[INFO] OpenJPA JPA JDBC
[INFO] OpenJPA Aggregate Jar
[INFO] OpenJPA Persistence Examples
[INFO] OpenJPA Distribution
[INFO] OpenJPA Integration Tests
[INFO] OpenJPA Examples Integration Tests
[INFO] OpenJPA JPA TCK Integration Tests
[INFO]
--
---
[INFO] Building OpenJPA
[INFO]task-segment: [package]
[INFO]
--
---
[INFO] [site:attach-descriptor]
[INFO]
--
---
[INFO] Building OpenJPA Utilities
[INFO]task-segment: [package]
[INFO]
--
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date [INFO]
[antrun:run {execution: set subversion revision}] [INFO] Executing
tasks
[echo] Revision: 406193:523071
[INFO] Executed tasks
[INFO] [antrun:run {execution: delete sun.misc.Perf}]
[INFO] Executing
tasks [INFO] Executed tasks [INFO] [resources:testResources] [INFO]
Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date [INFO]
[surefire:test] [INFO] Surefire report directory:
c:\Development\openjpa\openjpa-lib\target\sure
orts
[INFO] Building jar: c:\DOCUME~1\xibin\LOCALS~1\Temp
\surefirebooter17408.jar
java.lang.NoClassDefFoundError:
org/apache/maven/surefire/booter/SurefireBooter
Exception in thread main
[INFO]
--
--
[ERROR] BUILD FAILURE
[INFO]
--
--
[INFO] There are test failures.
[INFO]
--
--
[INFO] For more information, run Maven with the -e switch [INFO]
--
--
[INFO] Total time: 6 seconds
[INFO] Finished at: Wed Mar 28 00:09:14 PDT 2007 [INFO]
Final Memory:
8M/15M [INFO]
--
--
Thanks
- Xibin
Notice
RE: composite ID based on one side of a bidirectional one-many relationship
Page can have a primary key field type of Book.
@IdClass(com.mycompany.book.PageId.class)
@Entity
public class Page {
@Id
int number;
@Id
@ManyToOne
private Book book;
}
public class PageId {
int number;
String book; // the type String must match the type of primary key
used in Book.java
// the name of the variable book must match
the name of the variable in Page class.
}
public class Book {
@Id
String title;
}
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 4:35 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID based on one side of a bidirectional
one-many relationship
hi,
abe closed this with the reasoning ...
the book field in the PageId class must be of type String to match the
primary key field type of Book
was i mistaken when i understood you to say that Page could have a PK
field of type Book? if not, very sorry for all the confusion.
or were you just saying that open JPA allowed the PK field to be a
ManyToOne relationship?
p.s., it's issue #191
https://issues.apache.org/jira/browse/OPENJPA-191
Patrick Linskey [EMAIL PROTECTED] wrote: Yes, please do. It looks like
your code should work.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 10:31 AM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID based on one side of a bidirectional
one-many relationship
yes, i see the problem w/ the attached classes, and with a completely
different model where i am trying to accomplish the same thing.
should i file a bug? i can attach the test case there.
Patrick Linskey
wrote: Are you still
seeing that same problem with the code that you attached?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
__
_
Notice: This email message, together with any attachments, may
contain information of BEA Systems, Inc., its subsidiaries and
affiliated entities, that may be confidential, proprietary,
copyrighted and/or legally privileged, and is intended solely for the
use of the individual or entity named in this message. If you are not
the intended recipient, and have received this message in error,
please immediately return this by email and then delete it.
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 27, 2007 1:42 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID based on one side of a bidirectional
one-many relationship
Patrick Linskey
wrote:
my ID class has a book field, and getters and setters for it
to match Page's book field. i wonder about the last line where it
says java.lang.String. that seems odd.
Can you post your Book and Page classes and the Page's IdClass?
attached. i keep trying to attach the entire project as a zip, but
apache's spam filter keeps dropping it. let me know i could send to
you directly.
so, regardless, even if that did work, correct me if i am
wrong, but it'd be a really bad idea to depend on openjpa
specifics, because my app doesn't get to choose the JPA
implementation, it has to use whatever the java ee container
gives it ... right?
No -- a Java EE 5 container *must* allow you to specify your
persistence provider. Whatever you put in the element in the
persistence.xml must be obeyed. Only if you do not specify a
element can the implementation can choose whatever it wants to use.
yes, duh. sorry.
Correct.
so, assuming i do need to accomplish this, is there a best
practice? as i mentioned, what i did to make it work was make the
Page's composite ID incorporate the Book's ID by adding a
derived bookName field to Page, like ...
You could add a private bookName field that has no external
mutators or accessors, and create a @PreStore callback that copies
the value from the related Book into the field. That would do a
decent job of isolating the artifact from the rest of your app.
yes, that works.
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites
RE: Using DDL generation in a Java EE environment?
They do in SE, but as there is no requirement to do it in EE, people try to reduce the amount of typing ;). In EE, persistent classes can be specified via a) explictly via class b) via one or more jar-file c) via one or more mapping-file d) leave everything unspecified and OpenJPA will scan for @Entity annotated classes in the deployed unit Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Tuesday, March 20, 2007 6:22 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Using DDL generation in a Java EE environment? Marina- They do in SE, but as there is no requirement to do it in EE, people try to reduce the amount of typing ;). Hmm ... we might not actually require it in EE, since we do examine the ejb jar to look for persistent classes. I'm not sure though. You should test with both listing them and not listing them. I'd be interested to know if it works without. On Mar 20, 2007, at 4:19 PM, Marina Vatkina wrote: Marc, Marc Prud'hommeaux wrote: Marina- On Mar 20, 2007, at 4:02 PM, Marina Vatkina wrote: Marc, Thanks for the pointers. Can you please answer the following set of questions? 1. The doc requires that In order to enable automatic runtime mapping, you must first list all your persistent classes. Is this true for EE case also? Yes. People usually list them all in the class tags in the persistence.xml file. They do in SE, but as there is no requirement to do it in EE, people try to reduce the amount of typing ;). If OpenJPA can identify all entities in EE world, why can't it do the same for the schema generation? I'll check the rest. thanks, -marina 2. Section 1.2.Generating DDL SQL talks about .sql files, but what I am looking for are jdbc files, i.e. files with the lines that can be used directly as java.sql statements to be executed against database. The output should be sufficient. Try it out and see if the format is something you can use. 3. Is there a document that describes all possible values for the openjpa.jdbc.SynchronizeMappings property? Unfortunately, no. Basically, the setting of the SynchronizeMappings property will be of the form action (Bean1=value1,Bean2=value2), where the bean values are those listed in org.apache.openjpa.jdbc.meta.MappingTool (whose javadoc you can see http://incubator.apache.org/openjpa/docs/latest/ javadoc/org/ apache/openjpa/jdbc/meta/MappingTool.html ). thank you, -marina Marc Prud'hommeaux wrote: Marina- On Mar 15, 2007, at 5:01 PM, Marina Vatkina wrote: Hi, I am part of the GlassFish persistence team and was wondering how does OpenJPA support JPA auto DDL generation (we call it java2db) in a Java EE application server. Our application server supports java2db via creating two sets of files for each PU: a ...dropDDL.jdbc and a ...createDDL.jdbc file on deploy (i.e. before the application is actually loaded into the container) and then executing 'create' file as the last step in deployment, and 'drop' file on undeploy or the 1st step in redeploy. This allows us to drop tables created by the previous deploy operation. This approach is done for both, the CMP and the default JPA provider. It would be nice to add java2db support for OpenJPA as well, and I'm wondering if we need to do anything special, or it'll all work just by itself? We do have support for runtime creation of the schema via the openjpa.jdbc.SynchronizeMappings property. It is described at: http://incubator.apache.org/openjpa/docs/latest/manual/ manual.html#ref_guide_mapping_synch The property can be configured to run the mappingtool (also described in the documentation) at runtime against all the registered persistent classes. Here are my 1st set of questions: 1. Which API would trigger the process, assuming the correct values are specified in the persistence.xml file? Is it: a) provider.createContainerEntityManagerFactory(...)? or b) the 1st call to emf.createEntityManager() in this VM? c) something else? b 2. How would a user drop the tables in such environment? I don't think it can be used to automatically drop then create tables. The mappingtool can be executed manually twice, the first time to drop all the tables, and the second time to re- create them, but I don't think it can be automatically done at runtime with the SynchronizeMappings property. 3. If the answer to either 1a or 1b is yes, how does the code distinguish between the server startup time and the application being loaded for the 1st time? That is one of the reasons why we think it would be inadvisable to automatically drop tables at runtime :) 4. Is there a mode that allows creating a file with the jdbc statements to create or drop the tables and constraints? Yes. See
RE: EMF JNDI lookup is starting openJPA every time - was: Howto integrate JPA within EJB2.1 session beans?
EntityManagerFactory emf =
OpenJPAPersistence.createEntityManagerFactory(EMF_JNDI_LOCATION,
(Context) null);
1. Instead of passing null context, if the same Context instance is
passed on every invocation -- does the behaviour change?
2. If the emf and its underlying brokerfactory bf from two consecutive
invocation are emf1,bf1 and emf2, bf2 then which of the following are
true?
a) emf1 == emf2 and bf1 == bf2
b). emf1 != emf2 but bf1 == bf2
c). emf1!=emf2 and bf1!=bf2
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Hans J. Prueller [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 27, 2007 10:30 PM
To: open-jpa-dev@incubator.apache.org
Subject: AW: EMF JNDI lookup is starting openJPA every time - was: Howto
integrate JPA within EJB2.1 session beans?
please see below. The method PersistenceService.getEntityManager() is
invoked directly in SLSB's methods if access to the EM is needed, so
there could be multiple invocations within a single transaction spanning
multiple SLSB methods.
hth,
Hans
public class PersistenceService {
private static final Logger logger =
Logger.getLogger(PersistenceService.class.getName());
public static final String EMF_JNDI_LOCATION =
your/EMF/JNDI/location;
public static EntityManager getEntityManager() {
logger.log(Level.FINEST, creating a fresh, clean
EntityManager from JNDI EMF.);
EntityManagerFactory emf = OpenJPAPersistence
.createEntityManagerFactory(EMF_JNDI_LOCATION, (Context) null);
final BrokerFactory bf =
OpenJPAPersistence.toBrokerFactory(emf);
final Broker b = bf.newBroker(bf.getConfiguration()
.getConnectionUserName(),
bf.getConfiguration()
.getConnectionPassword(), true,
bf.getConfiguration().getConnectionRetainModeConstant(), true);
// do some JPA configuration setup. Logic stolen from
// EntityManagerFactoryImpl.
b.setAutoDetach(AutoDetach.DETACH_CLOSE, true);
b.setAutoDetach(AutoDetach.DETACH_ROLLBACK, true);
b.setDetachedNew(false);
return OpenJPAPersistence.toEntityManager(b);
}
}
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
RE: [jira] Commented: (OPENJPA-35) In-memory Delete operation fails with active DataCache
The issue is now better be stated as Delete by Query does not remove the copy from L2 cache. a) Tried to lock the instance, before delete causes commit to fail with OptimisticVerification b) Modifying the object before delete causes no change in behaviour in the scope of the given test. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Patrick Linskey (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 2:00 PM To: open-jpa-dev@incubator.apache.org Subject: [jira] Commented: (OPENJPA-35) In-memory Delete operation fails with active DataCache [ https://issues.apache.org/jira/browse/OPENJPA-35?page=com.atlassian.jira .plugin.system.issuetabpanels:comment-tabpanel#action_12476732 ] Patrick Linskey commented on OPENJPA-35: What happens if the user modifies the object or if the user obtains a read lock on the instance? In-memory Delete operation fails with active DataCache -- Key: OPENJPA-35 URL: https://issues.apache.org/jira/browse/OPENJPA-35 Project: OpenJPA Issue Type: Bug Components: datacache, query Environment: Only happens when DataCache is active property name=openjpa.DataCache value=true/ property name=openjpa.RemoteCommitProvider value=sjvm/ Reporter: Pinaki Poddar Priority: Critical Attachments: openjpa-35.test.zip Delete through query such as Query query = em.createQuery(DELETE FROM Node n); query.executeUpdate(); fails with following exception (only when DataCache is active) Exception in thread main 4|false|0.0.0 org.apache.openjpa.persistence.ArgumentException: org.apache.openjpa.datacache.QueryCacheStoreQuery at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1029) at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.execute Delete(ExpressionStoreQuery.java:665) at org.apache.openjpa.datacache.QueryCacheStoreQuery$QueryCacheExecutor.exe cuteDelete(QueryCacheStoreQuery.java:348) at org.apache.openjpa.kernel.QueryImpl.delete(QueryImpl.java:1012) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:768) at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:831) at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:827) at org.apache.openjpa.kernel.DelegatingQuery.deleteAll(DelegatingQuery.java :544) at org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:29 9) at control.Test.clear(Test.java:87) at control.Test.run(Test.java:37) at control.Test.main(Test.java:178) Caused by: java.lang.ClassCastException: org.apache.openjpa.datacache.QueryCacheStoreQuery at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.execute Query(ExpressionStoreQuery.java:651) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:949) at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1018) ... 11 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Updated: (OPENJPA-35) In-memory Delete operation fails with active DataCache
[ https://issues.apache.org/jira/browse/OPENJPA-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-35: - Attachment: openjpa-35.trace.txt Added a trace output of the test case that is failing. shows that the deleted instance (PObject-4501) is in L2 Cache. Please note the instance was locked and modified *after* delete by query (as we still has its reference). Does that give the cache a chance to heal? Please note that PObject-4501 has a DetachedStateManager when we lock/modify it after delete. In-memory Delete operation fails with active DataCache -- Key: OPENJPA-35 URL: https://issues.apache.org/jira/browse/OPENJPA-35 Project: OpenJPA Issue Type: Bug Components: datacache, query Environment: Only happens when DataCache is active property name=openjpa.DataCache value=true/ property name=openjpa.RemoteCommitProvider value=sjvm/ Reporter: Pinaki Poddar Priority: Critical Attachments: openjpa-35.test.zip, openjpa-35.trace.txt Delete through query such as Query query = em.createQuery(DELETE FROM Node n); query.executeUpdate(); fails with following exception (only when DataCache is active) Exception in thread main 4|false|0.0.0 org.apache.openjpa.persistence.ArgumentException: org.apache.openjpa.datacache.QueryCacheStoreQuery at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1029) at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeDelete(ExpressionStoreQuery.java:665) at org.apache.openjpa.datacache.QueryCacheStoreQuery$QueryCacheExecutor.executeDelete(QueryCacheStoreQuery.java:348) at org.apache.openjpa.kernel.QueryImpl.delete(QueryImpl.java:1012) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:768) at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:831) at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:827) at org.apache.openjpa.kernel.DelegatingQuery.deleteAll(DelegatingQuery.java:544) at org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:299) at control.Test.clear(Test.java:87) at control.Test.run(Test.java:37) at control.Test.main(Test.java:178) Caused by: java.lang.ClassCastException: org.apache.openjpa.datacache.QueryCacheStoreQuery at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:651) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:949) at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1018) ... 11 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [jira] Commented: (OPENJPA-35) In-memory Delete operation fails with active DataCache
Patrick, I added the trace output of the test for delete via query does not remove the copy from the L2 cache. The deleted instance was locked/modified after the transaction that deleted it was committed. Does that signal the L2 cache to heal itself? Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 3:24 PM To: open-jpa-dev@incubator.apache.org Subject: RE: [jira] Commented: (OPENJPA-35) In-memory Delete operation fails with active DataCache I'm wondering whether or not the cache is properly healing itself, which gives us a feel for how severe the problem is. em.begin(); em.remove(pc); em.commit(); pc.setSomething(); em.lock(pc, READ); I am interested in the behavior when using delete-by-query, as I'm pretty sure that I know what will happen in that situation. My expectation is that the cache will clean itself up after the initial locked read or write, which isn't nearly as bad as the cache never cleaning itself up, but clearly worse than the cache cleaning itself up in the first place. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Pinaki Poddar [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 2:58 PM To: open-jpa-dev@incubator.apache.org Subject: RE: [jira] Commented: (OPENJPA-35) In-memory Delete operation fails with active DataCache do you mean to lock or modify the object *after* delete? something like: em.begin(); em.remove(pc); em.commit(); pc.setSomething(); em.lock(pc, READ); Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Patrick Linskey Sent: Wednesday, February 28, 2007 2:47 PM To: open-jpa-dev@incubator.apache.org Subject: RE: [jira] Commented: (OPENJPA-35) In-memory Delete operation fails with active DataCache I was referring to subsequent transactions after the delete. The delete happens in its own persistence context, meaning that anything that has happened in the transaction to date is basically ignored. -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Pinaki Poddar [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 2:14 PM To: open-jpa-dev@incubator.apache.org Subject: RE: [jira] Commented: (OPENJPA-35) In-memory Delete operation fails with active DataCache The issue is now better be stated as Delete by Query does not remove the copy from L2 cache. a) Tried to lock the instance, before delete causes commit to fail with OptimisticVerification b) Modifying the object before delete causes no change in behaviour in the scope of the given test. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Patrick Linskey (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 2:00 PM To: open-jpa-dev@incubator.apache.org Subject: [jira] Commented: (OPENJPA-35) In-memory Delete operation fails with active DataCache [ https://issues.apache.org/jira/browse/OPENJPA-35?page=com.atla ssian.jira .plugin.system.issuetabpanels:comment-tabpanel#action_12476732 ] Patrick Linskey commented on OPENJPA-35: What happens if the user modifies the object or if the user obtains a read lock on the instance? In-memory Delete operation fails with active DataCache -- Key: OPENJPA-35 URL: https://issues.apache.org/jira/browse/OPENJPA-35 Project: OpenJPA Issue Type: Bug Components: datacache, query Environment: Only happens when DataCache is active property name=openjpa.DataCache value=true
[jira] Commented: (OPENJPA-35) In-memory Delete operation fails with active DataCache
[ https://issues.apache.org/jira/browse/OPENJPA-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476790 ] Pinaki Poddar commented on OPENJPA-35: -- Right -- a newly looked up copy (the copy comes out of L2 cache and not from the database where it really do not exist anymore) -- is essentially not usable i.e. any commit set containing that object fails. The L2 cache heals as soon as the commit fails. So let me summarize a) delete via query leaves a copy in the L2 cache b) the cached copy can be located via em.find() c) however, any modify operation on this ghost copy will fail d) this failure will signal to clear the copy from the L2 cache. Do you think, it is worth mentioning in the doc? In-memory Delete operation fails with active DataCache -- Key: OPENJPA-35 URL: https://issues.apache.org/jira/browse/OPENJPA-35 Project: OpenJPA Issue Type: Bug Components: datacache, query Environment: Only happens when DataCache is active property name=openjpa.DataCache value=true/ property name=openjpa.RemoteCommitProvider value=sjvm/ Reporter: Pinaki Poddar Priority: Critical Attachments: openjpa-35.test.zip, openjpa-35.trace.txt Delete through query such as Query query = em.createQuery(DELETE FROM Node n); query.executeUpdate(); fails with following exception (only when DataCache is active) Exception in thread main 4|false|0.0.0 org.apache.openjpa.persistence.ArgumentException: org.apache.openjpa.datacache.QueryCacheStoreQuery at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1029) at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeDelete(ExpressionStoreQuery.java:665) at org.apache.openjpa.datacache.QueryCacheStoreQuery$QueryCacheExecutor.executeDelete(QueryCacheStoreQuery.java:348) at org.apache.openjpa.kernel.QueryImpl.delete(QueryImpl.java:1012) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:768) at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:831) at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:827) at org.apache.openjpa.kernel.DelegatingQuery.deleteAll(DelegatingQuery.java:544) at org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:299) at control.Test.clear(Test.java:87) at control.Test.run(Test.java:37) at control.Test.main(Test.java:178) Caused by: java.lang.ClassCastException: org.apache.openjpa.datacache.QueryCacheStoreQuery at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:651) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:949) at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1018) ... 11 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: OpenJPA Transaction configuration
instead of _em.persist(ret);
try
_em.merge(ret);
as ret is detached instance rather than new.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Matthieu Riou [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 28, 2007 6:29 PM
To: open-jpa-dev@incubator.apache.org
Subject: OpenJPA Transaction configuration
Hi,
I'm going back at the OpenJPA implementation for the Apache ODE project
and am still having problems with the setup. Whan I try to persist a new
object I get an exception Attempt to persist detached object. I guess
the when I instantiate my object OpenJPA can't locate its transactional
context or something related therefore assuming that the object is
instantiated outside of any persistent context.
Here is the code that creates the EntityManagerFactory:
HashMapString, Object propMap = new HashMapString,Object();
propMap.put(openjpa.Log, DefaultLevel=TRACE);
propMap.put(openjpa.jdbc.DBDictionary,
org.apache.openjpa.jdbc.sql.DerbyDictionary);
propMap.put(openjpa.ManagedRuntime, new TxMgrProvider());
propMap.put(openjpa.ConnectionFactory, _ds);
propMap.put(openjpa.ConnectionFactoryMode, managed);
propMap.put(openjpa.Log, DefaultLevel=TRACE);
_emf = Persistence.createEntityManagerFactory(ode-dao,
propMap);
And here is my object instantiation code:
ProcessDAOImpl ret = new
ProcessDAOImpl(pid,type,guid,this,version);
System.out.println(detached +
((PersistenceCapable)ret).pcIsDetached());
_em.persist(ret);
My little debugging statement outputs true. I've reproduced the full
log below. I've also encapsulated to transaction manager and the
transaction to check whether OpenJPA was getting the transaction and
registering a synchronizer properly. It seems to be doing so (the log
statements are just a couple lines above the '.'). I've removed all
the mapping logs just to avoid making this too lengthy.
Any idea of what the problem could be? I'm kind of stuck on this as it's
hard to debug the enhanced code that gets called when I instantiate my
process object.
DEBUG - ODEMessageReceiver.receive(47) | Received message for
helloWorld.hello DEBUG - ODEService.onAxisMessageExchange(96) | Starting
transaction.
DEBUG - BpelEngineImpl.route(237) | Routed: svcQname {
http://ode/bpel/unit-test.wsdl}HelloService -- BpelProcess[{
http://ode/bpel/unit-test}HelloWorld2-1]
29603 ode-dao INFO [http-8080-Processor25] openjpa.Runtime -
Starting
OpenJPA 0.9.7-incubating-SNAPSHOT
29604 ode-dao TRACE [http-8080-Processor25] openjpa.Runtime -
Properties:
openjpa.EntityManagerFactory: default
openjpa.DataCache: false
openjpa.MetaDataFactory: jpa(Types=
org.apache.ode.dao.jpa.ActivityRecoveryDAOImpl
;org.apache.ode.dao.jpa.CorrelationSetDAOImpl;org.apache.ode.dao.jpa.Cor
relatorDAOImpl;org.apache.ode.dao.jpa.EventDAOImpl;org.apache.ode.dao.jp
a.FaultDAOImpl;org.apache.ode.dao.jpa.MessageDAOImpl;org.apache.ode.dao.
jpa.MessageExchangeDAOImpl;org.apache.ode.dao.jpa.MessageRouteDAOImpl;or
g.apache.ode.dao.jpa.PartnerLinkDAOImpl;org.apache.ode.dao.jpa.ProcessDA
OImpl;org.apache.ode.dao.jpa.ProcessInstanceDAOImpl;org.apache.ode.dao.j
pa.ScopeDAOImpl;org.apache.ode.dao.jpa.XmlDataDAOImpl)
openjpa.InverseManager: false
openjpa.ReadLockLevel: read
openjpa.DataCacheManager: default
openjpa.jdbc.SubclassFetchMode: join
openjpa.jdbc.UpdateManager: default
openjpa.jdbc.SynchronizeMappings: false
openjpa.NontransactionalRead: true
openjpa.QueryCompilationCache: true
openjpa.MaxFetchDepth: -1
openjpa.RetainState: true
openjpa.DynamicDataStructs: false
openjpa.BrokerFactory: jdbc
openjpa.WriteLockLevel: write
openjpa.ManagedRuntime:
org.apache.ode.dao.jpa.BPELDAOConnectionFactoryImpl$TxMgrProvider
openjpa.jdbc.EagerFetchMode: parallel
openjpa.RestoreState: immutable
openjpa.jdbc.SchemaFactory: dynamic
openjpa.LockManager: version
openjpa.BrokerImpl: default
openjpa.NontransactionalWrite: true
openjpa.MetaDataRepository: default
openjpa.Log: true(DefaultLevel=TRACE)
openjpa.jdbc.ResultSetType: forward-only
openjpa.AutoDetach:
openjpa.ConnectionRetainMode: on-demand
openjpa.SavepointManager: in-mem
openjpa.jdbc.DBDictionary: derby
openjpa.Optimistic: true
openjpa.ConnectionFactoryMode: managed
openjpa.Sequence: table
openjpa.FetchGroups: default
openjpa.jdbc.Schemas:
openjpa.Id: ode-dao
openjpa.OrphanedKeyAction: log
openjpa.FlushBeforeQueries: true
openjpa.AutoClear: datastore
openjpa.Compatibility: default
openjpa.DetachState: loaded
openjpa.jdbc.LRSSize: query
openjpa.Multithreaded: false
openjpa.FetchBatchSize: -1
openjpa.jdbc.SQLFactory: default
openjpa.IgnoreChanges: false
openjpa.jdbc.MappingDefaults: jpa
openjpa.TransactionMode: local
openjpa.RetryClassRegistration: false
openjpa.jdbc.FetchDirection: forward
openjpa.ClassResolver: default
openjpa.LockTimeout: -1
openjpa.DataCacheTimeout: -1
openjpa.QueryCache: true
openjpa.jdbc.DriverDataSource: simple
openjpa.jdbc.TransactionIsolation: default
RE: EMF JNDI lookup is starting openJPA every time - was: Howto integrate JPA within EJB2.1 session beans?
But maybe something funky is happening with JNDI serializing the factory and
then deserializing it or something.
From J2EE 1.4 spec, page 59 (J2EE.5.2 Java Naming and Directory Interface:
In general, lookups of objects in the JNDI java: namespace are required to
return a new instance of the requested object every time. Exceptions are
allowed for the following:
- The container knows the object is immutable (for example, objects of type
java.lang.String), or knows that the application can't change the state of
the object.
-The object is defined to be a singleton, such that only one instance of the
object may exist in the JVM.
-The name used for the lookup is defined to return an instance of the object
that might be shared. The name java:comp/ORB is such a name.
In these cases, a shared instance of the object may be returned. In all other
cases, a new instance of the requested object must be returned on each
lookup.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent: Monday, February 26, 2007 11:11 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: EMF JNDI lookup is starting openJPA every time - was: Howto
integrate JPA within EJB2.1 session beans?
It should be going through the following code:
public static OpenJPAEntityManagerFactory createEntityManagerFactory
(String jndiLocation, Context context) {
if (jndiLocation == null)
throw new NullPointerException(jndiLocation == null);
try {
if (context == null)
context = new InitialContext();
Object o = context.lookup(jndiLocation);
return (OpenJPAEntityManagerFactory) PortableRemoteObject.narrow(o,
OpenJPAEntityManagerFactory.class);
} catch (NamingException ne) {
throw new ArgumentException(_loc.get(naming-exception,
jndiLocation), new Throwable[]{ ne }, null, true);
}
}
I don't see anything in there that would be causing a creation to happen. But
maybe something funky is happening with JNDI serializing the factory and then
deserializing it or something.
Do you have any means of getting a stack from where the creation is happening?
It'd be great to get a bit more context about what's going on.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
-Original Message-
From: Hans J. Prueller [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 24, 2007 10:36 PM
To: open-jpa-dev@incubator.apache.org
Subject: EMF JNDI lookup is starting openJPA every time -
was: Howto integrate JPA within EJB2.1 session beans?
Hi together, Patrick,
the code you suggested for doing a helper method that deals with the
EMF JNDI lookup and the EM creating within our J2EE1.4 app basically
works fine, but as you perhaps may remember I asked why the method is
called create:
EntityManagerFactory myemf =
OpenJPAPersistence.createEntityManagerFactory(strJNDILocation,
(Context)null);
It seems that the method above really creates a NEW EMF on every
invocation!
I checked the logs of my application and I see the following messages
on every invocation of my PersistenceService.getEntityManger()
method (which
does the above lookup and some more ..)
2007-02-25 07:27:05,687 : PersistenceService.getEntityManager
: creating a
fresh
, clean EntityManager from JNDI EMF.
15 lbsims INFO [RMI TCP Connection(35)-192.168.0.5]
openjpa.Runtime -
Starti
ng OpenJPA 0.9.7-incubating-SNAPSHOT
15 lbsims INFO [RMI TCP Connection(35)-192.168.0.5]
openjpa.jdbc.JDBC -
Open
JPA will now connect to the database to attempt to determine what type
of databa se dictionary to use. To prevent this connection in the
future, set your openjp a.jdbc.DBDictionary configuration property to
the appropriate value for your dat abase (see the documentation for
available values).
15 lbsims INFO [RMI TCP Connection(35)-192.168.0.5]
openjpa.jdbc.JDBC -
Usin
g dictionary class
org.apache.openjpa.jdbc.sql.MySQLDictionary (MySQL 5.0.27-c
ommunity-nt ,MySQL-AB JDBC Driver mysql-connector-java-5.0.4 ( $Date:
2006-10-19
17:47:48 +0200 (Thu, 19 Oct 2006) $, $Revision: 5908 $ )).
15 lbsims INFO [RMI TCP Connection(35)-192.168.0.5]
openjpa.MetaData -
Found
1 classes with metadata in 0 milliseconds.
It seems that OpenJPA is now bootstrapping everytime I access
[jira] Resolved: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar resolved OPENJPA-151. --- Resolution: Fixed Fixed with SVN revision 511998: http://svn.apache.org/viewvc?view=revrev=511998 Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions. - Key: OPENJPA-151 URL: https://issues.apache.org/jira/browse/OPENJPA-151 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Attachments: diff.txt, PCEnhancer.AddVersion.Diff.txt Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant. This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation: 1. class A has one-to-one relation to class B 2. an instance a of A is related to b1 of B. b2 is another instance of B. 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*. 4. in the remote process a* is associated with b2* 5. a* is merged to the original process. The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade. The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty. Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: EMF JNDI lookup is starting openJPA every time - was: Howto integrate JPA within EJB2.1 session beans?
The JNDI spec says: the container knows that the application can't change the
state of the object.
How does one tell the container that the JNDI-bound instance is one such
'application immutable' object?
What we ended up with was implementing the naming.Referenceable interface
Did the JDO solution defined its own javax.naming.spi.ObjectFactory to take
control of how JNDI-bound instances are created on lookup?
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 27, 2007 3:32 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: EMF JNDI lookup is starting openJPA every time - was: Howto
integrate JPA within EJB2.1 session beans?
We had a similar issue with the JDO Reference Implementation. What we ended up
with was implementing the naming.Referenceable interface and writing our own
externalization protocols that basically allowed the container to create new
instances of our Factory that were actually trivial wrappers that delegated to
the real Factory.
So yes, I believe that unless a container knows that a bound value is
actually sharable (see below), it will generally serialize the instance and
then deserialize it for each caller. The way to make this operation perform
well (short of telling the container to share
it) is to implement the Referenceable contracts.
I can drag out more details if there is interest. Or you can look at the
implementation of FOStorePMF in the Apache JDO project.
Craig
On Feb 27, 2007, at 9:47 AM, Pinaki Poddar wrote:
But maybe something funky is happening with JNDI serializing the
factory and then deserializing it or something.
From J2EE 1.4 spec, page 59 (J2EE.5.2 Java Naming and Directory
Interface:
In general, lookups of objects in the JNDI java: namespace are
required to return a new instance of the requested object every time.
Exceptions are allowed for the following:
- The container knows the object is immutable (for example, objects of
type java.lang.String), or knows that the application can't change the
state of the object.
-The object is defined to be a singleton, such that only one instance
of the object may exist in the JVM.
-The name used for the lookup is defined to return an instance of the
object that might be shared. The name java:comp/ORB is such a name.
In these cases, a shared instance of the object may be returned. In
all other cases, a new instance of the requested object must be
returned on each lookup.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent: Monday, February 26, 2007 11:11 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: EMF JNDI lookup is starting openJPA every time - was:
Howto integrate JPA within EJB2.1 session beans?
It should be going through the following code:
public static OpenJPAEntityManagerFactory
createEntityManagerFactory
(String jndiLocation, Context context) {
if (jndiLocation == null)
throw new NullPointerException(jndiLocation == null);
try {
if (context == null)
context = new InitialContext();
Object o = context.lookup(jndiLocation);
return (OpenJPAEntityManagerFactory)
PortableRemoteObject.narrow(o,
OpenJPAEntityManagerFactory.class);
} catch (NamingException ne) {
throw new ArgumentException(_loc.get(naming-exception,
jndiLocation), new Throwable[]{ ne }, null, true);
}
}
I don't see anything in there that would be causing a creation to
happen. But maybe something funky is happening with JNDI serializing
the factory and then deserializing it or something.
Do you have any means of getting a stack from where the creation is
happening? It'd be great to get a bit more context about what's going
on.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
__
_
Notice: This email message, together with any attachments, may
contain information of BEA Systems, Inc., its subsidiaries
and affiliated entities, that may be confidential, proprietary,
copyrighted and/or legally privileged, and is intended solely for the
use of the individual or entity named in this message. If you are not
the intended recipient, and have received this message in error,
please immediately return this by email and then delete it.
-Original Message-
From: Hans J. Prueller [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 24, 2007 10:36 PM
To: open-jpa-dev@incubator.apache.org
Subject: EMF JNDI lookup is starting openJPA every time -
was: Howto integrate JPA within EJB2.1 session beans?
Hi together, Patrick,
the code you suggested for doing a helper method that deals with the
EMF JNDI lookup and the EM creating within our
RE: possible to write a JPA Query to that filters both an Entity and its relationship entities?
Respected Sir, Sorry to disagree. If you fetch Department instances, I think you always want the _employees collection to contain all the related Employees. You never want a filtered collection unless you provide a filter via some Java behavior. I agree that department.getEmployees() must return all the employees. However, i was considering the state of a Department instance in memory that has just been selected by a query. Which of the native (String/int etc.) field values are populated and which of its related objects are instantiated is controlled by the currently active fetch plan (if not explicitly then at least implicitly by 'default' fetch group). If the application accesses any unrealized field of this 'partially filled' department, then that field is populated irrespective of whether it is in active fetch group or not via a new, separate database access call. In a sense, the fecth plan determines a 'partial' view of the 'complete' department -- both in terms of its native state and its relations -- as and when it appears for the first time in memory. In fact, if the department instance leaves the managed environment via detachment at that point -- the detached department in a remote process will only have this partially filled 'view'. And, of course, the application can explictly load any unrealized state of the partial view via any getter method. I was trying to draw an equivalence/parallel of this normal fetch behavior to the use case where a owner object has a high, multi-cardinalty relationship but only wants a subset of the elements of that relationship. In such a scheme, the traversal on a fetch path relation (which is now a binary decision) can be further adorned to support a predicate i.e. Query query = // a JPQL query that selects a Department based on some critria query.getFetchPlan().addField(employees, yearsOfSevice10); Department dept = query.getSingleResult(); // dept will be constructed in memory with a collection of Employees with yearsOfService10 dept.getEmployees(); // now the dept will load a collection of all Employees Of course, the suggested alternative approach where the application explictly constructs this partial/filtered multi-cardinality relatinship by choosing the elements via query is feasible and available right now with current features. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, February 23, 2007 8:32 PM To: open-jpa-dev@incubator.apache.org Subject: Re: possible to write a JPA Query to that filters both an Entity and its relationship entities? On Feb 23, 2007, at 7:49 PM, Pinaki Poddar wrote: One way to realize a owner object with a partially filled multi-cardinality relationship is to expand fetchplan concept. For example, if we consider a Department of 100 Employees of which only 20 are oldtimers, then a query can select the particular Department from the datastore but to realize that Department as a Java object in memory with only 20 senior Employees in _employees collection will need to tune the fetch plan acconrdingly. In JDO, fetch plan is specified to certain details to extract a subset of native states and subset of relationships. JPA does not yet specify fetch plan, but OpenJPA does via @FetchGroup extension. However currently, no filtering criterion is applied to filter the content while a particular relationship path is traversed. It is a all-or-nothing affair. Either Department is fetched with all its 100 Employees or the Employees relation is not traversed at all. The only control available now is to specify which native states and relationship will be considered for fetching and in case of recursive relationship how many times a particular relation path will be traversed. Essentially query and fecth paths are working in conjunction -- query selects the root object and fetch plan decides which subset of the closure of this root object is realized in memory. It will surely be a useful feature to consider expanding fetch plan with filtering criteria. Sorry to disagree. If you fetch Department instances, I think you always want the _employees collection to contain all the related Employees. You never want a filtered collection unless you provide a filter via some Java behavior. In the query case, you want to get references to the filtered instances but there's no connection to the _employees field of the department. This is a good thing. Craig Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Patrick Linskey Sent: Friday, February 23, 2007 4:37 PM To: open-jpa-dev@incubator.apache.org Subject: RE: possible to write a JPA Query to that filters both an Entity and its relationship entities? I would expect that your query would return the unfiltered employees collection. But I have not run any tests. In other words, I would expect that the oldtimers
Test failure @ svn revision 511041
I am seeing a test failure @ revision 511041, $ mvn package The following test is failing: org.apache.openjpa.persistence.models.company.propertyaccess.TestPropert yCompanyModel#testBasicQueries Runs on Apache Derby 10.2.2.0 - (485682) Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). Will someone please verify that the tests are passing in their environment? Pinaki Poddar BEA Systems 415.402.7317 ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Updated: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-151: -- Attachment: diff.txt Prposed changes to remove pcFlags from enhanced classes i. remove pcFlags related interface method from PersistenceCapable and StateManager ii. remove pcFlags related code generation from PCEnhancer Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions. - Key: OPENJPA-151 URL: https://issues.apache.org/jira/browse/OPENJPA-151 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Attachments: diff.txt Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant. This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation: 1. class A has one-to-one relation to class B 2. an instance a of A is related to b1 of B. b2 is another instance of B. 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*. 4. in the remote process a* is associated with b2* 5. a* is merged to the original process. The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade. The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty. Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[
https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475099
]
Pinaki Poddar commented on OPENJPA-151:
---
Why will this require re-enhancement?
==
Previous enhancement:
private static final void pcSetdepartment(Employee employee, Department
department1) {
if(employee.pcFlags == 0) {
employee.department = department1;
return;
}
if(employee.pcStateManager == null) {
employee.department = department1;
return;
} else {
employee.pcStateManager.settingObjectField(employee,
pcInheritedFieldCount + 0, employee.department, department1, 0);
return;
}
}
Enhanced version once pcFlags is removed:
private static final void pcSetdepartment(Employee employee, Department
department1) {
if(employee.pcStateManager == null) {
employee.department = department1;
return;
} else {
employee.pcStateManager.settingObjectField(employee,
pcInheritedFieldCount + 0, employee.department, department1, 0);
return;
}
}
==
If the previous enhanced version is used, the behaviour of serialized domain
class will remain unchanged even with new OpenJPA runtime (i.e. PC/SM
interfaces without calling back on pcReplaceFlags()).
But all this optimization to short-circuit StateManager mediation is only
happening with JDO facade that too when the accessed field in not in default
fetch group.
Added field in enhanced vesrion of a class is not serialized. Hence the
change in detached+serialized instances is not registered under certain
conditions.
-
Key: OPENJPA-151
URL: https://issues.apache.org/jira/browse/OPENJPA-151
Project: OpenJPA
Issue Type: Improvement
Components: kernel
Reporter: Pinaki Poddar
Assigned To: Pinaki Poddar
Attachments: diff.txt
Enhancement adds a transient byte member field pcFlags to the class. This
field is originally used to optimize field access/mutation i.e. to
short-circuit mediation via StateManager under certain conditions (e.g. when
the field is part of the default fetch group). The field is transient,
perhaps, to maintain serialization compatibility. However, later changes such
as DetachedStateManager and improved attach strategies have made the usage of
these flag redundant.
This issue is a proposal to remove this field from the enhanced classes. The
proposed change is initiated by the following observation:
1. class A has one-to-one relation to class B
2. an instance a of A is related to b1 of B. b2 is another instance of B.
3. a, b1, b2 are detached, serialized, transported over the wire, desrialized
in a remote process as a*, b1* and b2*.
4. in the remote process a* is associated with b2*
5. a* is merged to the original process.
The change is not persisted when OpenJPA kernel is used with a JDO facade. It
works with JPA facade.
The initial analysis shows that the reason can be attributed to pcFlags and
the optimization in enhanced classes based on to its value. Because pcFlags
is not
serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of
a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the
detached version was carrying its own StateManager). While merging the
instance a* back, it was adjudged clean while actually it was dirty. In JPA
facade, the enhancement process did not add the extra optimization for setter
and so the cloned owner instance was righly marked dirty.
Please note that if this proposal is accepted by the community, it will
require reenhancement of existing domain classes. The change will impact the
internal StateManager and PersistenceCapable API (essentally removal of
certain methods than any other behavioural change).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475144 ] Pinaki Poddar commented on OPENJPA-151: --- One way is to add some extra checks on isPersistenceCapable() for the deprecated pcFlags() method and warn if the enhanced version is old. Or is that too arbitrary? Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions. - Key: OPENJPA-151 URL: https://issues.apache.org/jira/browse/OPENJPA-151 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Attachments: diff.txt Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant. This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation: 1. class A has one-to-one relation to class B 2. an instance a of A is related to b1 of B. b2 is another instance of B. 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*. 4. in the remote process a* is associated with b2* 5. a* is merged to the original process. The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade. The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty. Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-151: -- Attachment: PCEnhancer.AddVersion.Diff.txt Added a public int getEnhancementContractVersion() to all enhanced classes. Please review these baby steps into bytecode manipulation. The diff also contains removal of pcFlags related changes. It does not include the change in PersistenceCapable interface. 1. Should the method be static? 2. The ENHANCER_VERSION is public static final in PCEnhncer. So the user can: PersistenceCapable pc = ... if (pc.getEnhancementContractVersion() PCEnhancer.ENHANCER_VERSION) // warn or throw exception 3. What is a good central location to add the above check? Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions. - Key: OPENJPA-151 URL: https://issues.apache.org/jira/browse/OPENJPA-151 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Attachments: diff.txt, PCEnhancer.AddVersion.Diff.txt Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant. This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation: 1. class A has one-to-one relation to class B 2. an instance a of A is related to b1 of B. b2 is another instance of B. 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*. 4. in the remote process a* is associated with b2* 5. a* is merged to the original process. The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade. The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty. Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Howto integrate JPA within EJB2.1 session beans? [architecture]
One way to provide acccess to EntityManagerFactory/EntityManager to the SLSB is to collate JPA-related facilities into a separate class (say PersistenceService). PersistenceService will a) ensure EntityManagerFactory is created once (or at least not too often) as that is the 'heavy' operation b) provide EntityManager either i) by creating a new one in every call and/or ii) providing an existing EntityManager bound to the current thread (using ThreadLocal, for example) to emulate a session-per-thread model. This session-per-thread is useful when one bean calling another within the same transaction. c) this will provide a layer of isolation to the SLSBs from the actual implementaion of a persistence service. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Hans Prueller [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 1:02 AM To: open-jpa-dev@incubator.apache.org Subject: Howto integrate JPA within EJB2.1 session beans? [architecture] Hi together, I'm sorry for bothering you with numerous basic questions regarding OpenJPA and its usage but I have to migrate existing CMP EJBs to migrate within short time to OpenJPA as we're having stability issues with the current CMP engine. One last question I'd like to ask is regarding the recommended architecture of using OpenJPA within EJB2.1 Stateless sessino beans: I need to work with persistence i.e. the EntityManager throughout all the session beans methods so my idea is to: - create a EntityManagerFactory in the ejbCreate() method of the SLSB - and also create the EntityManager itself in the ejbCreeate() method and store it as a member variable of the SLSB - this would allow easy access within the SB's methods by just using the already initialized entity manager varialbe em.createNamedQuery() .. etc. etc. - clean up should be performed in the ejbRemove() method of the SLSB I think doing so will allow migratino to openJPA with less work than doing the whole lookup procedure in every method separately. what do you think? are there any pitfalls i've overlooked? thank you for your ideas! regards Hans -- Feel free - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Can enhancer operate on jar files?
That implies that I'm that own the development cycle of this code. In this case, I just get a jar from the user. With current facilities: 1. Unpack the entire content of the original jar to some temp directory. 2. Run enhancer with temp in classpath and *not* the original jar 3. Jar the temp directory 4. Overwrite the original jar, optinally This way, if the original content contained other files (meta-inf etc.) will be packaged exactly in the final jar. Enhancer will not require to handle rewriting of a Jar file's content. Pinaki Poddar BEA Systems 415.402.7317 ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Updated: (OPENJPA-147) T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface
[ https://issues.apache.org/jira/browse/OPENJPA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-147: -- Attachment: IPerson.java The Java interface definition is attached. I did not use an orm.xml. T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface - Key: OPENJPA-147 URL: https://issues.apache.org/jira/browse/OPENJPA-147 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Pinaki Poddar Attachments: iface.trace.1.txt, iface.trace.2.txt, iface.trace.3.txt, iface.trace.4.txt, IPerson.java, TestInterface.java According to JavaDoc, OpenJPAEntityManager.createInstance() method public T T createInstance(ClassT cls); behaves as follows: Create a new instance of type codecls/code. If codecls/code is an interface or an abstract class whose abstract methods follow the JavaBeans convention, this method will create a concrete implementation according to the metadata that defines the class The method fails when T is an interface. The failure may be due to incorrect user configuration, however, further information on this extension method is not available in OpenJPA documentation. Firstly, how to specify metadata for a interface that has bean-style methods? Possibilities are: a) Annotating the Java interface definition with @Entity b) Specifying in classorg.acme.IPerson/class in persistence.xml Either of the above fails. a) fails at parsing b) fails with no metadata There may be a correct but undocumented way of specifying a managed interface. If that is the case, then this JIRA report should be treated as a documentation bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-147) T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface
[ https://issues.apache.org/jira/browse/OPENJPA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-147: -- Attachment: iface.trace.1.txt T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface - Key: OPENJPA-147 URL: https://issues.apache.org/jira/browse/OPENJPA-147 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Pinaki Poddar Attachments: iface.trace.1.txt, iface.trace.2.txt, iface.trace.3.txt, iface.trace.4.txt According to JavaDoc, OpenJPAEntityManager.createInstance() method public T T createInstance(ClassT cls); behaves as follows: Create a new instance of type codecls/code. If codecls/code is an interface or an abstract class whose abstract methods follow the JavaBeans convention, this method will create a concrete implementation according to the metadata that defines the class The method fails when T is an interface. The failure may be due to incorrect user configuration, however, further information on this extension method is not available in OpenJPA documentation. Firstly, how to specify metadata for a interface that has bean-style methods? Possibilities are: a) Annotating the Java interface definition with @Entity b) Specifying in classorg.acme.IPerson/class in persistence.xml Either of the above fails. a) fails at parsing b) fails with no metadata There may be a correct but undocumented way of specifying a managed interface. If that is the case, then this JIRA report should be treated as a documentation bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-147) T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface
[ https://issues.apache.org/jira/browse/OPENJPA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-147: -- Attachment: iface.trace.2.txt T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface - Key: OPENJPA-147 URL: https://issues.apache.org/jira/browse/OPENJPA-147 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Pinaki Poddar Attachments: iface.trace.1.txt, iface.trace.2.txt, iface.trace.3.txt, iface.trace.4.txt According to JavaDoc, OpenJPAEntityManager.createInstance() method public T T createInstance(ClassT cls); behaves as follows: Create a new instance of type codecls/code. If codecls/code is an interface or an abstract class whose abstract methods follow the JavaBeans convention, this method will create a concrete implementation according to the metadata that defines the class The method fails when T is an interface. The failure may be due to incorrect user configuration, however, further information on this extension method is not available in OpenJPA documentation. Firstly, how to specify metadata for a interface that has bean-style methods? Possibilities are: a) Annotating the Java interface definition with @Entity b) Specifying in classorg.acme.IPerson/class in persistence.xml Either of the above fails. a) fails at parsing b) fails with no metadata There may be a correct but undocumented way of specifying a managed interface. If that is the case, then this JIRA report should be treated as a documentation bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-147) T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface
[ https://issues.apache.org/jira/browse/OPENJPA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-147: -- Attachment: TestInterface.java T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface - Key: OPENJPA-147 URL: https://issues.apache.org/jira/browse/OPENJPA-147 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Pinaki Poddar Attachments: iface.trace.1.txt, iface.trace.2.txt, iface.trace.3.txt, iface.trace.4.txt, TestInterface.java According to JavaDoc, OpenJPAEntityManager.createInstance() method public T T createInstance(ClassT cls); behaves as follows: Create a new instance of type codecls/code. If codecls/code is an interface or an abstract class whose abstract methods follow the JavaBeans convention, this method will create a concrete implementation according to the metadata that defines the class The method fails when T is an interface. The failure may be due to incorrect user configuration, however, further information on this extension method is not available in OpenJPA documentation. Firstly, how to specify metadata for a interface that has bean-style methods? Possibilities are: a) Annotating the Java interface definition with @Entity b) Specifying in classorg.acme.IPerson/class in persistence.xml Either of the above fails. a) fails at parsing b) fails with no metadata There may be a correct but undocumented way of specifying a managed interface. If that is the case, then this JIRA report should be treated as a documentation bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection Key: OPENJPA-117 URL: https://issues.apache.org/jira/browse/OPENJPA-117 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Priority: Minor Currently TransactionListeners can be added/removed to a broker but the list of transaction listeners registered to a particular broker is not available. Such a collection can be made available in read-only mode so a caller can determine whether to add a new listener or not, or whether a particular listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468719 ] Pinaki Poddar commented on OPENJPA-117: --- The use case is the code that intends to register a listener but gets the PersistenceManager/EntityManager from another layer outside of its own control. Then the registerer does not know whether the obtained PM/EM is already carrying a particular listener or not. Currently the internal collection of listener is not a Set, so unconditionally adding a listener results in duplicates. Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection Key: OPENJPA-117 URL: https://issues.apache.org/jira/browse/OPENJPA-117 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Priority: Minor Currently TransactionListeners can be added/removed to a broker but the list of transaction listeners registered to a particular broker is not available. Such a collection can be made available in read-only mode so a caller can determine whether to add a new listener or not, or whether a particular listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-109) every NativeQuery using SqlResultSetMapping fails at runtime with There is no query result mapping for null with name xxx when the entity is persisted in a differen
[ https://issues.apache.org/jira/browse/OPENJPA-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467492 ] Pinaki Poddar commented on OPENJPA-109: --- Will you please attach a test case + annotated domain classes or domain classes + xml descriptors. This will help us to reproduce this failure as the test cases (within Kodo test corpus) for SQLResultMapping and SQLResultSetMappings that are based on the same implementation are not showing similar failure. every NativeQuery using SqlResultSetMapping fails at runtime with There is no query result mapping for null with name xxx when the entity is persisted in a different method than the method doing the query. --- Key: OPENJPA-109 URL: https://issues.apache.org/jira/browse/OPENJPA-109 Project: OpenJPA Issue Type: Bug Environment: windows xp, openjpa_097_incubating Reporter: George Hongell every NativeQuery using SqlResultSetMapping fails at runtime with There is no query result mapping for null with name xxx when the entity is persisted in a different method than the method doing the query. 4|true|0.9.7-incubating-SNAPSHOT org.apache.openjpa.persistence.ArgumentException: There is no query result mapping for null with name DeptBeanMapping. at org.apache.openjpa.jdbc.meta.MappingRepository.getQueryResultMapping(MappingRepository.java:175) at org.apache.openjpa.jdbc.kernel.SQLStoreQuery$SQLExecutor.init(SQLStoreQuery.java:174) at org.apache.openjpa.jdbc.kernel.SQLStoreQuery.newDataStoreExecutor(SQLStoreQuery.java:143) at org.apache.openjpa.kernel.QueryImpl.createExecutor(QueryImpl.java:718) at org.apache.openjpa.kernel.QueryImpl.compileForDataStore(QueryImpl.java:676) at org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:658) at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1463) at org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:120) at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:214) at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:264) at com.ibm.ws.query.tests.JUNamedNativeQueryTest.testSelectDeptBean(JUNamedNativeQueryTest.java:457) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(Unknown Source) at junit.framework.TestCase.runBare(Unknown Source) at junit.framework.TestResult$1.protect(Unknown Source) at junit.framework.TestResult.runProtected(Unknown Source) at junit.framework.TestResult.run(Unknown Source) at junit.framework.TestCase.run(Unknown Source) at junit.framework.TestSuite.runTest(Unknown Source) at junit.framework.TestSuite.run(Unknown Source) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: has @SqlResultSetMapping been tested
Query updateDeptName = _em.createNativeQuery(sql,DeptBeanMapping); If any persistence operation using DeptBean.class preceeds this call (e.g. _em.persist(new DeptBean())), then is there any change in behavior? Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: George Hongell [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 10, 2007 9:49 AM To: open-jpa-dev@incubator.apache.org Subject: Fwd: has @SqlResultSetMapping been tested I tried using both a native query and it failed, has it ever been tested? also named native query with resultSetMapping fails at runtime, also @SqlResultSetMappings does not seem to be implemented in openjpa and fails in the MappingTool with *java.lang.ArrayStoreException* using @SqlResultSetMapping(name=DeptBeanMapping, [EMAIL PROTECTED](entityClass=DeptBean.class ) ) this fails Query updateDeptName = _em.createNativeQuery(sql,DeptBeanMapping); this works // Query updateDeptName = _em.createNativeQuery(sql,DeptBean.class); 4|true|0.9.7-incubating-SNAPSHOT org.apache.openjpa.persistence.ArgumentException: There is no query result mapping for null with name DeptBeanMapping. at org.apache.openjpa.jdbc.meta.MappingRepository.getQueryResultMapping( MappingRepository.java:175) at org.apache.openjpa.jdbc.kernel.SQLStoreQuery$SQLExecutor.init( SQLStoreQuery.java:174) at org.apache.openjpa.jdbc.kernel.SQLStoreQuery.newDataStoreExecutor( SQLStoreQuery.java:143) at org.apache.openjpa.kernel.QueryImpl.createExecutor(QueryImpl.java:718) at org.apache.openjpa.kernel.QueryImpl.compileForDataStore(QueryImpl.java :676) at org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java :658) at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1463) at org.apache.openjpa.kernel.DelegatingQuery.getOperation( DelegatingQuery.java:120) at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:214) at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java :264) at com.ibm.ws.query.tests.JUNamedNativeQueryTest.testSelectDeptBean( JUNamedNativeQueryTest.java:457) ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: svn commit: r492225 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/ openjpa-jdbc/src/main/resourc
Hello Michael,
is there any reason why we can't move the code into a more common
location?
None. I will move it to SchemaGenerator.
Thanks --
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Michael Dick [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 04, 2007 11:38 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: svn commit: r492225 - in /incubator/openjpa/trunk:
openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/
openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/
openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/meta/
openjpa-persisten
I'm a little unclear on why the code is in ClassMapping, too. It seems
like it could go in the SchemaGenerator along with
generatePrimaryKeys(), generateIndexes(), etc.
Pinaki, is there any reason why we can't move the code into a more
common location?
On 1/3/07, Abe White [EMAIL PROTECTED] wrote:
I don't agree with this implementation. It doesn't leave any room for
customization through MappingDefaults, it ties the ClassMapping to the
XMLSchemaParser (?!), and it's totally different than our mapping of
indexes, foreign keys, and primary keys, the other supported
constraint types.
+mapUniqueConstraints();
+}
+
+/**
+ * Adds unique constraints to the mapped table.
+ *
+ */
+void mapUniqueConstraints() {
+Log log = getRepository().getLog();
+Collection uniqueInfos = _info.getUniqueConstraints();
+if (uniqueInfos == null || uniqueInfos.isEmpty())
+return;
+Iterator iter = uniqueInfos.iterator();
+Table table = getTable();
+int i = 1;
+while (iter.hasNext()) {
+XMLSchemaParser.UniqueInfo uniqueInfo =
+(XMLSchemaParser.UniqueInfo)iter.next();
+if (uniqueInfo.cols == null ||
uniqueInfo.cols.isEmpty())
+continue;
+String constraintName = table.getName() + _UNIQUE_ +
i;
+i++;
+Unique uniqueConstraint = table.addUnique
(constraintName);
+Iterator uniqueColumnNames =
uniqueInfo.cols.iterator();
+while (uniqueColumnNames.hasNext()) {
+String uniqueColumnName = (String)
uniqueColumnNames.next();
+Column uniqueColumn = table.getColumn
(uniqueColumnName);
+if (uniqueColumn != null) {
+uniqueConstraint.addColumn(uniqueColumn);
+} else {
+table.removeUnique(uniqueConstraint);
+if (log.isWarnEnabled())
+log.warn(_loc.get(missing-unique-column,
this,
+table.getName(), uniqueColumnName));
+break;
+}
}
}
}
__
_
Notice: This email message, together with any attachments, may
contain information of BEA Systems, Inc., its subsidiaries and
affiliated entities, that may be confidential, proprietary,
copyrighted and/or legally privileged, and is intended solely for the
use of the individual or entity named in this message. If you are not
the intended recipient, and have received this message in error,
please immediately return this by email and then delete it.
--
-Michael Dick
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
RE: Are relation sets identity, pk or bean.equals() based?
In addition to Marc's explanation+
If the collection/map field is instantiated with a type more specific
than the declared type (either in field declaration or in no-arg
constructor), then the more specific type is used.
for example,
public class A {
Collection f1 = new HashSet();
List f2;
public A() {
f2 = new LinkedList();
}
}
OpenJPA will use ProxyHashSet for f1 and ProxyLinkedList for f2.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 13, 2006 7:24 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Are relation sets identity, pk or bean.equals() based?
On Dec 13, 2006, at 4:56 PM, Marc Prud'hommeaux wrote:
If you declare the field to be an interface type and you don't
initialize the field to anything, I don't remember how we decide what
impl to use.
Looking at the code in ProxyManagerImpl.java, it appears that we
default to ArrayList for fields declared as type Collection, HashSet
for fields declared as type Set, TreeSet for fields declared as type
SortedSet, and ArrayList for fields declared as type List.
Thanks! That is exactly what I wanted to know.
-dain
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
RE: Get primary key from persistent bean
This is a major hole in the JPA spec if you ask me. Once upon a time, there was a spec called JDO. It had a API javax.jdo.JDOHelper.getObjectId(Object pc); I think it got left out while copying ;) Pinaki Poddar BEA Systems 415.402.7317 ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
cache-topic for clustered Kodo
Patrick, Your 'cacheTopic' theme effectively replaces the original requirement of having a configuration.getId(), at least for this purpose (I remember that it has other usages e.g. in logging). For ClusterRemoteCommitProvider, i will default cacheTopic value with configuration.getId(). Pinaki Poddar BEA Systems 415.402.7317 ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-60) Specifying the wrong persistence implementation in persistence.xml leads to misleading error message
[ http://issues.apache.org/jira/browse/OPENJPA-60?page=comments#action_12438249 ] Pinaki Poddar commented on OPENJPA-60: -- Fix available on revision #450632. Specifying the wrong persistence implementation in persistence.xml leads to misleading error message Key: OPENJPA-60 URL: http://issues.apache.org/jira/browse/OPENJPA-60 Project: OpenJPA Issue Type: Bug Reporter: David Ezzio Priority: Minor If kodo.persistence.PersistenceProviderImpl is specified instead of org.apache.openjpa.persistence.PersistenceProviderImpl, a misleading error message results that suggests that the persistence.xml file is missing or cannot be found. enhance: [java] Exception in thread main java.util.MissingResourceException: org.apache.openjpa.persistence.PersistenceProductDerivation:java.util.MissingResourceException: The specified XML resource META-INF/persistence.xml for persistence unit null can't be found in your class path. [java] at org.apache.openjpa.lib.conf.ProductDerivations.reportErrors(ProductDerivations.java:217) [java] at org.apache.openjpa.lib.conf.ProductDerivations.load(ProductDerivations.java:135) [java] at org.apache.openjpa.lib.conf.Configurations.populateConfiguration(Configurations.java:198) [java] at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3468) [java] at org.apache.openjpa.enhance.PCEnhancer.main(PCEnhancer.java:3441) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: question on FetchGroup
MaxFetchDepth is the upper limit of the number of relations traversed to reach a node in the graph from the root object node. By default, it is set to 1. -1 means infinte. RecursionDepth controls the number of times a particular relation would be traveresed in case of self-relation. Say Male has a relation field father to another Male. If recusrion-depth is set to 3 for father -- a Male instance will also fetch his father, grandfather and great-grandfather. A single depth being fetched irrespective of recursionDepth setting is perhaps because maxFetchDepth is set to 1. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: David Wisneski [mailto:[EMAIL PROTECTED] Sent: Thursday, September 07, 2006 11:19 PM To: open-jpa-dev@incubator.apache.org Subject: Re: question on FetchGroup By not working I meant that irregardless of what value for recursionDepth was specified ( we tried 0, 1, 2 ) only one level was retrieved. However we did not try changing the MaxFetchDepth property. On 9/7/06, Abe White [EMAIL PROTECTED] wrote: But that does not seem to work. Is this a code bug or is a document error? Or an error in my understanding of FetchGroup depth ? Both a documentation error and a misunderstanding. I'll try to update the docs later today. In the meantime, I don't know what you mean when you say it does not seem to work, but one important note is that the MaxFetchDepth is 1 by default, so if you want to fetch deep relations, you'll need to increase that -- either on the FetchPlan or using the openjpa.MaxFetchDepth configuration property. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: version numbers
Neat idea. +1. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Patrick Linskey Sent: Tuesday, August 29, 2006 6:01 PM To: open-jpa-dev@incubator.apache.org Subject: RE: version numbers Does anyone have any thoughts about the questions posed below? In particular, I haven't heard a peep about issues 1. Marc Prud'hommeaux proposed an interesting alternate to solution 2b -- we could prefix all the current @since tags with '0.', so that the old Kodo version information is still accessible (i.e., we'd have @since 0.3.3 for things that were introduced in Kodo 3.3). Thoughts? -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Patrick Linskey Sent: Saturday, August 05, 2006 9:59 AM To: open-jpa-dev@incubator.apache.org Subject: version numbers Hi, Some questions about version numbers: 1. Is it true that we should keep the OpenJPA version number below 1.0 until we get out of incubation? 2. The @since tags in the OpenJPA javadocs are currently all relative to Kodo version numbers (i.e., the most recent ones say @since 4.1, etc.). How do we want to rectify this? Options: a) Move OpenJPA's version number up to 4.1 as soon as it comes out of incubation. b) The Reverse Emacs. Toss a 1 onto the beginning, so that 4.1 becomes 1.4.1. c) Ignore the problem. There's nothing to see here. d) Remove all the @since tags, and start afresh. 3. Should we be striving to keep the version numbers of the various sub-modules in sync, or should each get a separate version number moving forward? -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Data + Query cache
DataCache or L2 cache being a performance optimization feature not mandated by the spec, makes it a candidate for *not* being on by default. a) If the user explictly turns the feature on, it makes him/her aware of its advantages as well as behavioral difference e.g. refresh(). b) If the user turns it on and observes a performance improvement -- that makes the benefit of the feature obvious. c) It keeps the option of product level differentiation open On the other hand, if the feature is on by default what would be the likely reason to turn it off? Some JavaEE portal may then report how default behaviour of OpenJPA is not spec-compliant :( On performance front, initial results indicate that OpenJPA is significantly better than other alternatives against industry standard benchmarks -- so even leaving DataCache off would not give a reason to report otherwise. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Marc Logemann [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 10:18 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Data + Query cache Hi, of course my intention wasnt to ask about kodo, but i was confused that a feature will be on by default that was formerly on sale. I will look into the packages to get an idea. The other question regarding the cache or a method like isCached() was to solve the issue that users could get irritated where the results come from. Without such a method, there is no way to solve the irritation for certain users then ;-) But the other thing is, if you dont turn it on by default, you can be sure to see a review that says that hibernate is faster by default on some JavaEE portal. -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 25.08.2006 um 18:31 schrieb Patrick Linskey: (Performance pack is Kodo parlance, and this is a Kodo-related email.) Actually, we're getting rid of Performance Pack altogether, at long last, and replacing with a Professional Edition. (I never much liked the Performance Pack name, given that the other two were editions.) I don't remember the details of what lands where, but we aren't going to be selling things that are available in OpenJPA. You can get a feeling for what the JDO bindings for Kodo look like by taking a look at the openjpa-persistence and openjpa-persistence-jdbc modules in OpenJPA -- you'll notice that the bindings largely add spec behavior to the core kernel. So the features available in the core kernel are available to all bindings. -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Marc Logemann [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 7:01 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Data + Query cache Hi, does that mean that the performance pack gets obsolete or how do you want to control the cache then? It would be weird to sell the cache to JDO users while its free for JPA users right? -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 24.08.2006 um 22:54 schrieb Abe White: How does the list feel about turning the L2 data and query caches on by default? Traditionally, Kodo always left them off by default, primarily because they required a performance pack license to run. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
code stats on OpenJPA
You can get a feeling for what the JDO bindings for Kodo look like by taking a look at the openjpa-persistence and openjpa-persistence-jdbc modules in OpenJPA -- you'll notice that the bindings largely add spec behavior to the core kernel. So the features available in the core kernel are available to all bindings. 94% of codebase (in terms of filesize) are independent of JPA or JDO spec-specified interfaces/classes. These are available in openjpa-kernel/lib/jdbc package. The core kernel is subdivided into object management (57%) and store management (37%) while object managment being independent of specific storage technology (a JDO legacy:). 6% code is JPA implementation following a facade pattern (available in openjpa-persistence package) built on top of this kernel. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Patrick Linskey Sent: Friday, August 25, 2006 9:32 AM To: open-jpa-dev@incubator.apache.org Subject: RE: Data + Query cache (Performance pack is Kodo parlance, and this is a Kodo-related email.) Actually, we're getting rid of Performance Pack altogether, at long last, and replacing with a Professional Edition. (I never much liked the Performance Pack name, given that the other two were editions.) I don't remember the details of what lands where, but we aren't going to be selling things that are available in OpenJPA. You can get a feeling for what the JDO bindings for Kodo look like by taking a look at the openjpa-persistence and openjpa-persistence-jdbc modules in OpenJPA -- you'll notice that the bindings largely add spec behavior to the core kernel. So the features available in the core kernel are available to all bindings. -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Marc Logemann [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 7:01 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Data + Query cache Hi, does that mean that the performance pack gets obsolete or how do you want to control the cache then? It would be weird to sell the cache to JDO users while its free for JPA users right? -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 24.08.2006 um 22:54 schrieb Abe White: How does the list feel about turning the L2 data and query caches on by default? Traditionally, Kodo always left them off by default, primarily because they required a performance pack license to run. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Data + Query cache
I did not mean it is. I was just how a some JavaEE portal may spin it! Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Patrick Linskey Sent: Friday, August 25, 2006 11:22 AM To: open-jpa-dev@incubator.apache.org Subject: RE: Data + Query cache On the other hand, if the feature is on by default what would be the likely reason to turn it off? Some JavaEE portal may then report how default behaviour of OpenJPA is not spec-compliant :( How is the data cache not spec-compliant? -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
