Re: Entity manager injection
Hmm. I believe that you actually fall into the first category -- OpenJPA
only uses the ManagedRuntime when it thinks that it's integrating with
JTA. It sounds like you're using JTA to control transactions, and
plugging into OpenJPA SPIs to tell OpenJPA about how to bind into JTA.
I see, so if what JPA needs is just a JTA transaction then yes we're in that
category. So I guess the next question is do you have an idea why my entity
manager is null when I use:
@Entity
public class Foo {
@PersistenceContext private EntityManager em;
...
}
?? These 3 links point to the place we initialize the EM factory, the EM and
a the persistence object that uses the EM and would like to use injection:
http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/src/main/java/org/apache/ode/dao/jpa/BPELDAOConnectionFactoryImpl.java
http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/src/main/java/org/apache/ode/dao/jpa/BPELDAOConnectionImpl.java
http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/src/main/java/org/apache/ode/dao/jpa/ProcessDAOImpl.java
The hooks certainly do exist, for the most part. However, we already
have an API-based way to do this --
OpenJPAPersistence.getEntityManager(Object). Since injecting an
instance's EntityManager not quite the same as what happens with the
@PersistenceContext annotation from a Java EE standpoint, I prefer to
recommend the proprietary OpenJPA extension API. This makes it more
clear where you are depending on OpenJPA-specific features, and avoids
any semantic confusion.
Makes sense.
Thanks!
Matthieu
-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: Matthieu Riou [mailto:[EMAIL PROTECTED]
Sent: Monday, March 05, 2007 8:48 AM
To: Patrick Linskey
Cc: open-jpa-dev@incubator.apache.org
Subject: Re: Entity manager injection
We're managing our own transactions using our
TransactionManager provided through openjpa.ManagedRuntime.
So I guess we'll have to go for your second solution. I'll
probably implement a simple ThreadLocal holding the
EntityManager associated with the current tx.
Btw it's just an idea but wouldn't it be possible for OpenJPA
to handle persistence manager injection even outside of an
EJB container? It seems to me that all the necessary hooks
exist. Just an idea though :)
Thanks for the help,
Matthieu
On 3/5/07, Patrick Linskey [EMAIL PROTECTED] wrote:
Hi,
IIRC, you're doing something like so:
@Entity
public class Foo {
@PersistenceContext private EntityManager em;
...
}
The Java EE spec's support for resource injection does
not apply for
entity types. So, from an EJB standpoint, you can only
use resource
injection in session beans and MDBs. You're getting the
NPE because your
EJB container ignores the @PersistenceContext
annotation on your entity.
(Note that OpenJPA doesn't do anything at all with
@PersistenceContext
annotations.)
If you were using a session bean, then there are two
possible answers to
your question:
1. If you are managing your own transactions using JTA
and bean-managed
transactions, then you'd be in good shape using
@PersistenceContext.
2. If you are managing your own transactions using the JPA
EntityTransaction API, then you cannot use
@PersistenceContext to inject
an EM, but instead must use @PersistenceUnit to inject an
EntityManagerFactory (or some other EMF lookup means),
and do your own
lifecycle management.
-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: Matthieu Riou [mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] ]
Sent: Friday, March 02, 2007 8:32 AM
To:
Re: Entity manager injection
Hi Matthew,
Basically, with JPA we have formalized separation of concerns between
the user's Domain Object Model, represented by Entity, and the user's
Business Object, represented by Session Beans.
There is no need for managing an EntityManager from the Entity
itself. So you should simply remove references to the em in your
Entity classes, and put them instead into your Session Beans.
So injection doesn't work at all for Entity, but works for Session
Beans.
Craig
On Mar 5, 2007, at 9:28 AM, Matthieu Riou wrote:
Hmm. I believe that you actually fall into the first category --
OpenJPA
only uses the ManagedRuntime when it thinks that it's integrating
with
JTA. It sounds like you're using JTA to control transactions, and
plugging into OpenJPA SPIs to tell OpenJPA about how to bind into
JTA.
I see, so if what JPA needs is just a JTA transaction then yes
we're in that
category. So I guess the next question is do you have an idea why
my entity
manager is null when I use:
@Entity
public class Foo {
@PersistenceContext private EntityManager em;
...
}
?? These 3 links point to the place we initialize the EM factory,
the EM and
a the persistence object that uses the EM and would like to use
injection:
http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/src/
main/java/org/apache/ode/dao/jpa/BPELDAOConnectionFactoryImpl.java
http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/src/
main/java/org/apache/ode/dao/jpa/BPELDAOConnectionImpl.java
http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/src/
main/java/org/apache/ode/dao/jpa/ProcessDAOImpl.java
The hooks certainly do exist, for the most part. However, we already
have an API-based way to do this --
OpenJPAPersistence.getEntityManager(Object). Since injecting an
instance's EntityManager not quite the same as what happens with the
@PersistenceContext annotation from a Java EE standpoint, I prefer to
recommend the proprietary OpenJPA extension API. This makes it more
clear where you are depending on OpenJPA-specific features, and
avoids
any semantic confusion.
Makes sense.
Thanks!
Matthieu
-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: Matthieu Riou [mailto:[EMAIL PROTECTED]
Sent: Monday, March 05, 2007 8:48 AM
To: Patrick Linskey
Cc: open-jpa-dev@incubator.apache.org
Subject: Re: Entity manager injection
We're managing our own transactions using our
TransactionManager provided through openjpa.ManagedRuntime.
So I guess we'll have to go for your second solution. I'll
probably implement a simple ThreadLocal holding the
EntityManager associated with the current tx.
Btw it's just an idea but wouldn't it be possible for OpenJPA
to handle persistence manager injection even outside of an
EJB container? It seems to me that all the necessary hooks
exist. Just an idea though :)
Thanks for the help,
Matthieu
On 3/5/07, Patrick Linskey [EMAIL PROTECTED] wrote:
Hi,
IIRC, you're doing something like so:
@Entity
public class Foo {
@PersistenceContext private EntityManager em;
...
}
The Java EE spec's support for resource injection does
not apply for
entity types. So, from an EJB standpoint, you can only
use resource
injection in session beans and MDBs. You're getting the
NPE because your
EJB container ignores the @PersistenceContext
annotation on your entity.
(Note that OpenJPA doesn't do anything at all with
@PersistenceContext
annotations.)
If you were using a session bean, then there are two
possible answers to
your question:
1. If you are managing your own transactions using JTA
and bean-managed
transactions, then you'd be in good shape using
@PersistenceContext.
2. If you are managing your own transactions using the JPA
EntityTransaction API, then you cannot use
@PersistenceContext to inject
an EM, but instead must use @PersistenceUnit to inject an
EntityManagerFactory (or some other EMF lookup means),
and do your own
lifecycle management.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
__
_
Notice: This email message, together with any
attachments, may contain
information of BEA Systems, Inc., its
Re: Entity manager injection
Hi Craig,
I plainly understand the rational when your application is living in an EJB
container and relies on session beans. However when you're in a standalone
environment (like Apache Ode is) or only with a servlet container, there are
many cases where you'll want your Entity to know about the EM. It allows you
to have a nice design with some entities being responsible of the lifecycle
of other entities they manage.
For example in Ode the process entity creates and finds process instances,
all the persistence details being hidden behind generic (as non persistence
specific) interfaces.
Thanks a lot for the reply and the clarification,
Matthieu
On 3/5/07, Craig L Russell [EMAIL PROTECTED] wrote:
Hi Matthew,
Basically, with JPA we have formalized separation of concerns between
the user's Domain Object Model, represented by Entity, and the user's
Business Object, represented by Session Beans.
There is no need for managing an EntityManager from the Entity
itself. So you should simply remove references to the em in your
Entity classes, and put them instead into your Session Beans.
So injection doesn't work at all for Entity, but works for Session
Beans.
Craig
On Mar 5, 2007, at 9:28 AM, Matthieu Riou wrote:
Hmm. I believe that you actually fall into the first category --
OpenJPA
only uses the ManagedRuntime when it thinks that it's integrating
with
JTA. It sounds like you're using JTA to control transactions, and
plugging into OpenJPA SPIs to tell OpenJPA about how to bind into
JTA.
I see, so if what JPA needs is just a JTA transaction then yes
we're in that
category. So I guess the next question is do you have an idea why
my entity
manager is null when I use:
@Entity
public class Foo {
@PersistenceContext private EntityManager em;
...
}
?? These 3 links point to the place we initialize the EM factory,
the EM and
a the persistence object that uses the EM and would like to use
injection:
http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/src/
main/java/org/apache/ode/dao/jpa/BPELDAOConnectionFactoryImpl.java
http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/src/
main/java/org/apache/ode/dao/jpa/BPELDAOConnectionImpl.java
http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/src/
main/java/org/apache/ode/dao/jpa/ProcessDAOImpl.java
The hooks certainly do exist, for the most part. However, we already
have an API-based way to do this --
OpenJPAPersistence.getEntityManager(Object). Since injecting an
instance's EntityManager not quite the same as what happens with the
@PersistenceContext annotation from a Java EE standpoint, I prefer to
recommend the proprietary OpenJPA extension API. This makes it more
clear where you are depending on OpenJPA-specific features, and
avoids
any semantic confusion.
Makes sense.
Thanks!
Matthieu
-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: Matthieu Riou [mailto:[EMAIL PROTECTED]
Sent: Monday, March 05, 2007 8:48 AM
To: Patrick Linskey
Cc: open-jpa-dev@incubator.apache.org
Subject: Re: Entity manager injection
We're managing our own transactions using our
TransactionManager provided through openjpa.ManagedRuntime.
So I guess we'll have to go for your second solution. I'll
probably implement a simple ThreadLocal holding the
EntityManager associated with the current tx.
Btw it's just an idea but wouldn't it be possible for OpenJPA
to handle persistence manager injection even outside of an
EJB container? It seems to me that all the necessary hooks
exist. Just an idea though :)
Thanks for the help,
Matthieu
On 3/5/07, Patrick Linskey [EMAIL PROTECTED] wrote:
Hi,
IIRC, you're doing something like so:
@Entity
public class Foo {
@PersistenceContext private EntityManager em;
...
}
The Java EE spec's support for resource injection does
not apply for
entity types. So, from an EJB standpoint, you can only
use resource
injection in session beans and MDBs. You're getting the
NPE because your
EJB container ignores the @PersistenceContext
annotation on your entity.
(Note that OpenJPA doesn't do anything at all with
@PersistenceContext
annotations.)
If you were using a session bean, then there are two
possible answers to
your question:
[jira] Commented: (OPENJPA-162) @OrderBy on @OneToMany does not allow ordering by @Id value
[ https://issues.apache.org/jira/browse/OPENJPA-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478122 ] Patrick Linskey commented on OPENJPA-162: - I believe that the issue is that the field is not in the current fetch configuration; i.e., it's a lazy relationship. The ID field will clearly be part of the instance that is selected , but when you're selecting Messages, not Threads (or whatever it is that contains Messages). What happens if you just say '@OrderBy' and leave out the string argument? According to 9.1.28 of the spec, if you just specify @OrderBy and nothing else, the ordering will be ascending by the pk of the associated records, which happens to be what you want. @OrderBy on @OneToMany does not allow ordering by @Id value --- Key: OPENJPA-162 URL: https://issues.apache.org/jira/browse/OPENJPA-162 Project: OpenJPA Issue Type: Bug Components: jpa Affects Versions: 0.9.6 Environment: Using PostgreSQL 8.1 as the database Reporter: Nick Johnson Using the following annotation: @OneToMany(mappedBy=root, fetch=FetchType.LAZY) @OrderBy(objectId ASC) private ListMessage messages; I get the exception Cannot order net.spatula.tally_ho.model.MessageRoot.messages on objectId, because that field is not in the default fetch group. You can only order on fields that will be selected when the related object is loaded. I should certainly hope that the primary key of the related object is going to be selected when the object is loaded: @Id @Column(name = object_id) private long objectId; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-162) @OrderBy on @OneToMany does not allow ordering by @Id value
[ https://issues.apache.org/jira/browse/OPENJPA-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White resolved OPENJPA-162. --- Resolution: Fixed Fix Version/s: 0.9.7 Fixed in revision 514847. Test case TestIdOrderedOneMany added. @OrderBy on @OneToMany does not allow ordering by @Id value --- Key: OPENJPA-162 URL: https://issues.apache.org/jira/browse/OPENJPA-162 Project: OpenJPA Issue Type: Bug Components: jpa Affects Versions: 0.9.6 Environment: Using PostgreSQL 8.1 as the database Reporter: Nick Johnson Fix For: 0.9.7 Using the following annotation: @OneToMany(mappedBy=root, fetch=FetchType.LAZY) @OrderBy(objectId ASC) private ListMessage messages; I get the exception Cannot order net.spatula.tally_ho.model.MessageRoot.messages on objectId, because that field is not in the default fetch group. You can only order on fields that will be selected when the related object is loaded. I should certainly hope that the primary key of the related object is going to be selected when the object is loaded: @Id @Column(name = object_id) private long objectId; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Missing PK Values
So I got into the console and enabled the
jpa logging but, I am not seeing anything.
I'm not positive, but I think that you may need to enable each of the
particular JPA debug options in the ServerDebugMBean (via console or
config.xml), and not just one global setting. So, in this situation,
enabling the JDBC and SQL debug options will be useful.
If you're still not seeing anything, can you post your persistence.xml
file?
Also, what happens if you use a different GenerationType (other than
IDENTITY or SEQUENECE)? What does the schema definition for your table
look like?
-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: Dan Bush [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 04, 2007 6:25 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Missing PK Values
The pk is being assigned in the DB. When I look up the entity with the
EM, the pk is not set in the entity correctly. In fact it's 0 and I
would have expected null any way as its a java.lang.Long, not a
primitive ... I will try the enable the logging again. I did put the
appropriate property in the persistence.xml but, WL is logging a
warning that it is going to be ignored and the logging should be
configured in the console. So I got into the console and enabled the
jpa logging but, I am not seeing anything.
Some more facts:
1) I am making remote calls into a session bean that is then
interacting with an injected EM. So the transaction demarcation should
be being controlled by the container at the session bean method level.
All the methods of the session bean are of transaction type requires
by default.
2) I am NOT using the WLs XA Sybase driver because I have to get the
DBAs to grant some role to make it work. So for now I am using WLs non
XA driver.
I am not positive that the EM is playing nice with JTA and maybe thats
why the pks are not being refreshed / loaded back from the db. Then
again the underlying inserts are committed.
On 3/4/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Dan-
Once you commit the transaction, is the PK assigned? Can you enable
SQL logging any show us the SQL that is executed in the transaction?
Finally, if you look up the Entity using a new EntityManager, is the
PK set correctly?
On Mar 2, 2007, at 3:38 PM, Dan Bush wrote:
I am using WL 10T and OpenJPA(0.9.7 nightly) against a
Sybase(12.5.3)
DB . My PK types are IDENTITY and I have the entities
mapped like so:
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = myPk)
private Long id;
public Long getId() {// i only have a setter ...
return id;
}
When I execute the following code, the PK comes back 0! :
Entity e = new EntityX();
_em.persist(entity);
// _em.flush();
// _em.refresh() // tried this too
System.out.println(entity.getId()); // returning 0
It doesn't look like the PKs are being relayed back from
the DB. Not
sure if I have a driver issue or what(using the non XA WL Sybase
driver). Even when I find an entity all the fields values
seam to be
working except for the pks. Anyone have any ideas?
