How do we know the entity is successfully deployed on appserver
Dear all, How do I know whether an entity is successfully deployed on an appserver? Usually I detect this by autogenerating tables in database. Is there anyway I can autogenerate tables in database with OpenJPA? I've searched in documentation but perhaps I have missed it when reading it. Last but not least, am I allowed to ask user questions in this list? Since this is a dev list. Thanks in advance -- YM!: thejavafreak Blog: http://www.nagasakti.or.id/roller/joshua/
Re: Accessing Trasaction or EnityManager in LifeCycle methods
There is no JPA spec-mandated way to do this. In OpenJPA, you can do
the following:
EntityManager em = OpenJPAPersistence.getEntityManager(this);
Note that the JPA spec does not require that impls allow you to
operate on the EM during a callback. OpenJPA does allow this behavior.
You might also be interested in the OpenJPA transaction-level or
lifecycle-level callbacks. See the listener interfaces in
org.apache.openjpa.event. You can add these with a call to
OpenJPAEntityManager.addTransactionListener() and
OpenJPAEntityManager.addLifecycleListener().
-Patrick
On 5/10/07, Majeed Arni <[EMAIL PROTECTED]> wrote:
If I have @PrePersist or @PreRemove, in the methods that gets called, how
can I access the Transaction object?
Example:
@PrePersist
public void prePersist()
{
em.persist(anotherObj); // How do I get access to em?
}
Thanks for the help.
--
View this message in context:
http://www.nabble.com/Accessing-Trasaction-or-EnityManager-in-LifeCycle-methods-tf3722974.html#a10417736
Sent from the open-jpa-dev mailing list archive at Nabble.com.
--
Patrick Linskey
202 669 5907
Accessing Trasaction or EnityManager in LifeCycle methods
If I have @PrePersist or @PreRemove, in the methods that gets called, how
can I access the Transaction object?
Example:
@PrePersist
public void prePersist()
{
em.persist(anotherObj); // How do I get access to em?
}
Thanks for the help.
--
View this message in context:
http://www.nabble.com/Accessing-Trasaction-or-EnityManager-in-LifeCycle-methods-tf3722974.html#a10417736
Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: Bug when persisting two related objects
I am using DB2 to generate the Identity as in the DDL:
ID BIGINT NOT NULL GENERATED BY DEFAULT AS IDENTITY (START WITH 1, INCREMENT
BY 1)
And in code for the base class:
@MappedSuperclass
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class Base {
.
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "ID")
private long someID;
.}
Will this not use a unique ID generator per derived class? Is there a better
way of doing it in DB2? Thanks for the help.
Majeed Arni
Abe White wrote:
>
> Are the two types related by inheritance? If two classes in an
> inheritance hierarchy use the same id class, then every instance of
> both classes must have a distinct id value. If you want instances in
> inheritance-related classes to be able to have the same id values,
> then you must use different id classes for different classes in the
> inheritance hierarchy.
>
> 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.
>
>
--
View this message in context:
http://www.nabble.com/Bug-when-persisting-two-related-objects-tf3719319.html#a10416417
Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: Bug when persisting two related objects
Are the two types related by inheritance? If two classes in an inheritance hierarchy use the same id class, then every instance of both classes must have a distinct id value. If you want instances in inheritance-related classes to be able to have the same id values, then you must use different id classes for different classes in the inheritance hierarchy. 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.
OpenJPA meet-up at JavaOne?
Hi, After scheduling my third one-on-one meeting with an OpenJPA person for this week, it just occurred to me that there are a lot of us in town for JavaOne. Yes, I'm slow on the uptake sometimes. Let's meet up this afternoon at the Thirsty Bear. How does 5:30pm sound? In honor of the principle of freedom-as-in-beer, the first round will be on BEA. As with all incubating projects, I'm hopeful that we can establish a diversity in our round-sponsoring organization list. -Patrick -- Patrick Linskey 202 669 5907
Re: Bug when persisting two related objects
Have a base class, say B and have 2 classes derived from it X and Y.
B is
@MappedSuperclass
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
X has oneY (1 to 1) unidirection
@OneToOne(fetch = FetchType.EAGER, cascade = { CascadeType.ALL})
@JoinColumn(name = "Y_ID", nullable=false)
Y does not know of X.
Caused by: <0.9.7-incubating fatal store error>
org.apache.openjpa.persistence.RollbackException: Attempt to assign id
"com.testc.reporting.core.pbo.Base-201" to new instance
"com.testc.reporting.core.pbo.Project-com.testc.reporting.core.pbo.Base-201"
failed; there is already an object in the L1 cache with this id. You must
delete this object (in a previous transaction or the current one) before
reusing its id. This error can also occur when a horizontally or vertically
mapped classes uses auto-increment application identity and does not use a
hierarchy of application identity classes.
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:420)
at
com.testc.reporting.core.TestProject.testCreateProject(TestProject.java:54)
at com.testc.reporting.core.TestProject.testProject(TestProject.java:24)
at com.testc.reporting.core.Main.main(Main.java:19)
... 27 more
Caused by: <0.9.7-incubating fatal user error>
org.apache.openjpa.persistence.ArgumentException: Attempt to assign id
"com.testc.reporting.core.pbo.Base-201" to new instance
"com.testc.reporting.core.pbo.Project-com.testc.reporting.core.pbo.Base-201"
failed; there is already an object in the L1 cache with this id. You must
delete this object (in a previous transaction or the current one) before
reusing its id. This error can also occur when a horizontally or vertically
mapped classes uses auto-increment application identity and does not use a
hierarchy of application identity classes.
FailedObject:
com.testc.reporting.core.pbo.Project-com.testc.reporting.core.pbo.Base-201
at
org.apache.openjpa.kernel.BrokerImpl$ManagedCache.commitNew(BrokerImpl.java:4528)
at
org.apache.openjpa.kernel.BrokerImpl.setStateManager(BrokerImpl.java:3787)
at
org.apache.openjpa.kernel.StateManagerImpl.commit(StateManagerImpl.java:925)
at
org.apache.openjpa.kernel.BrokerImpl.endTransaction(BrokerImpl.java:2194)
at
org.apache.openjpa.kernel.BrokerImpl.afterCompletion(BrokerImpl.java:1801)
at
org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:93)
at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1311)
at
org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:866)
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:409)
... 30 more
Patrick Linskey-2 wrote:
>
> Hi,
>
> Can you describe the relationship between Project and Base (and any
> other relevant persistent classes and superclasses)? If possible, it'd
> be great to see some relevant code snippets.
>
> Thanks,
>
> -Patrick
>
> On 5/9/07, Majeed Arni <[EMAIL PROTECTED]> wrote:
>> I have 2 objects related, when I create both in a transaction and "set
>> one
>> object on another" and then committing. I get this error. The objects are
>> stored in DB2 with auto increment -ing identity.
>>
>> "This error can also occur when a horizontally or vertically mapped
>> classes uses auto-increment application identity and does not use a
>> hierarchy of application identity classes."
>>
>> Caused by: <0.9.7-incubating fatal user error>
>> org.apache.openjpa.persistence.ArgumentException: Attempt to assign id
>> "com.XXX.core.pbo.Base-141" to new instance
>> "com..core.pbo.Project-com..core.pbo.Base-141" failed; there is
>> already an object in the L1 cache with this id. You must delete this
>> object (in a previous transaction or the current one) before reusing its
>> id. This error can also occur when a horizontally or vertically mapped
>> classes uses auto-increment application identity and does not use a
>> hierarchy of application identity classes.
>> FailedObject: com.X.core.pbo.Project-com..core.pbo.Base-141
>> at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.commitNew(
>> BrokerImpl.java:4528)
>> at org.apache.openjpa.kernel.BrokerImpl.setStateManager(
>> BrokerImpl.java:3787)
>> at org.apache.openjpa.kernel.StateManagerImpl.commit(
>> StateManagerImpl.java:925)
>> at org.apache.openjpa.kernel.BrokerImpl.endTransaction(
>> BrokerImpl.java:2194)
>> at org.apache.openjpa.kernel.BrokerImpl.afterCompletion(
>> BrokerImpl.java:1801)
>> at org.apache.openjpa.kernel.LocalManagedRuntime.commit(
>> LocalManagedRuntime.java:93)
>> at org.apache.openjpa.kernel.BrokerImpl.commit(
>> BrokerImpl.java:1311)
>> at org.apache.openjpa.kernel.DelegatingBroker.commit(
>> DelegatingBroker.java:866)
>> at org.apache.openjpa.persistence.EntityManagerImpl.commit(
>> EntityManagerImpl.java:409)
Error in persisting 2 related object in OpenJPA 0.9.7/DB2
I am trying to save 2 objects which have 1-to-Many relationship. Both are created in a transaction and then persisted. Both have identity generated by DB2. Is this a bug? is there a workaournd this? Caused by: <0.9.7-incubating fatal store error> org.apache.openjpa.persistence.RollbackException: Attempt to assign id "com.testc.reporting.core.pbo.Base-201" to new instance "com.testc.reporting.core.pbo.Project-com.testc.reporting.core.pbo.Base-201" failed; there is already an object in the L1 cache with this id. You must delete this object (in a previous transaction or the current one) before reusing its id. This error can also occur when a horizontally or vertically mapped classes uses auto-increment application identity and does not use a hierarchy of application identity classes. at org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:420) at com.testc.reporting.core.TestProject.testCreateProject(TestProject.java:54) at com.testc.reporting.core.TestProject.testProject(TestProject.java:24) at com.testc.reporting.core.Main.main(Main.java:19) ... 27 more Caused by: <0.9.7-incubating fatal user error> org.apache.openjpa.persistence.ArgumentException: Attempt to assign id "com.testc.reporting.core.pbo.Base-201" to new instance "com.testc.reporting.core.pbo.Project-com.testc.reporting.core.pbo.Base-201" failed; there is already an object in the L1 cache with this id. You must delete this object (in a previous transaction or the current one) before reusing its id. This error can also occur when a horizontally or vertically mapped classes uses auto-increment application identity and does not use a hierarchy of application identity classes. FailedObject: com.testc.reporting.core.pbo.Project-com.testc.reporting.core.pbo.Base-201 at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.commitNew(BrokerImpl.java:4528) at org.apache.openjpa.kernel.BrokerImpl.setStateManager(BrokerImpl.java:3787) at org.apache.openjpa.kernel.StateManagerImpl.commit(StateManagerImpl.java:925) at org.apache.openjpa.kernel.BrokerImpl.endTransaction(BrokerImpl.java:2194) at org.apache.openjpa.kernel.BrokerImpl.afterCompletion(BrokerImpl.java:1801) at org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:93) at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1311) at org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:866) at org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:409) ... 30 more
[jira] Commented: (OPENJPA-78) Automatic runtime enhancement only works when the class is listed in the first persistence-unit
[ https://issues.apache.org/jira/browse/OPENJPA-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494694 ] Markus Wolf commented on OPENJPA-78: This problem also occurs when enhancing classes at build-time. The workaround here is listing all classes on the commandline (or from ant/maven) but this is a duplication of the class list. > Automatic runtime enhancement only works when the class is listed in the > first persistence-unit > --- > > Key: OPENJPA-78 > URL: https://issues.apache.org/jira/browse/OPENJPA-78 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Reporter: Marc Prud'hommeaux >Priority: Minor > Fix For: 0.9.8 > > > When multiple persistence-units are defined in the persistence.xml, only the > first one is examined when looking for classes to enhance when using the > automatic runtime enhancement (e.g., using the "-javaagent:openjpa.jar" > argument). So if the project uses the following persistence.xml: > http://java.sun.com/xml/ns/persistence"; version="1.0"> > > unit1.SomeClass > > > unit2.SomeClass > > > In this example, when unit1.SomeClass is loaded, it will be enhanced, but > unit2.SomeClass won't ever be enhanced. > The only workaround is to list all of your persistent classes in an initial > entry in the persistence-unit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-78) Automatic runtime enhancement only works when the class is listed in the first persistence-unit
[ https://issues.apache.org/jira/browse/OPENJPA-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Wolf updated OPENJPA-78: --- Priority: Major (was: Minor) > Automatic runtime enhancement only works when the class is listed in the > first persistence-unit > --- > > Key: OPENJPA-78 > URL: https://issues.apache.org/jira/browse/OPENJPA-78 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Reporter: Marc Prud'hommeaux > Fix For: 0.9.8 > > > When multiple persistence-units are defined in the persistence.xml, only the > first one is examined when looking for classes to enhance when using the > automatic runtime enhancement (e.g., using the "-javaagent:openjpa.jar" > argument). So if the project uses the following persistence.xml: > http://java.sun.com/xml/ns/persistence"; version="1.0"> > > unit1.SomeClass > > > unit2.SomeClass > > > In this example, when unit1.SomeClass is loaded, it will be enhanced, but > unit2.SomeClass won't ever be enhanced. > The only workaround is to list all of your persistent classes in an initial > entry in the persistence-unit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
