Deployment on JBoss
Hi guys, One of our users in ODE is trying to deploy on JBoss. There seems to be some configuration problems, most probably related to the presence of Hibernate in the server. He's having the following stacktrace (I trimmed the non relevant bits): 13:15:29,343 INFO [STDOUT] ERROR - ODEServer.initDAO(413) | Error instantiating DAO Connection Factory class org.apache.ode.dao.jpa.BPELDAO ConnectionFactoryImp l. javax.persistence.PersistenceException: Provider error. Provider: org.hibernate. ejb.HibernatePersistence at javax.persistence.Persistence.createFactory(Persistence.java:175) at javax.persistence.Persistence.createEntityManagerFactory (Persistence. java:111) at org.apache.ode.dao.jpa.BPELDAOConnectionFactoryImpl.init (BPELDAOConne ctionFactoryImpl.java:108) at org.apache.ode.il.dbutil.Database.createDaoCF(Database.java:267) at org.apache.ode.axis2.ODEServer.initDAO(ODEServer.java:410) at org.apache.ode.axis2.ODEServer.init(ODEServer.java:144) 13:15:31,078 INFO [STDOUT] ERROR - StandardContext.loadOnStartup(4073) | Servle t /ode threw load() exception java.lang.ClassCastException: org.hibernate.ejb.HibernatePersistence at javax.persistence.Persistence.createFactory(Persistence.java:169) at javax.persistence.Persistence.createEntityManagerFactory (Persistence. java:111) at org.apache.ode.dao.jpa.BPELDAOConnectionFactoryImpl.init (BPELDAOConne ctionFactoryImpl.java:108) at org.apache.ode.il.dbutil.Database.createDaoCF(Database.java:267) at org.apache.ode.axis2.ODEServer.initDAO(ODEServer.java:410) at org.apache.ode.axis2.ODEServer.init(ODEServer.java:144) As you can see there's a ClassCastException in javax.persistence.Persistence.createFactory which is a bit weird. Note that we instantiate the factory using a specific name: _emf = Persistence.createEntityManagerFactory(ode-dao, propMap); And that our persistence.xml *only* references the OpenJPA persistence factory. I've looked at the sources of Persistence.java in Glassfish but couldn't find the right version that seems to be used here (the createFactory method doesn't seem to exist anymore). I'm running out of ideas and thought the knowledgeable people would probably know more about the JBoss environment. Any idea? Thanks! Matthieu
Re: Deployment on JBoss
It's hard for me to test as this is reported by one of our users but I can ask him to try that. But wouldn't that result in selecting the Hibernate implementation instead OpenJPA (which we don't want)? Thanks, Matthieu On 4/30/07, Patrick Linskey [EMAIL PROTECTED] wrote: What happens if you toss 'providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provi der' into your persistence.xml file? -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, April 30, 2007 9:05 AM To: open-jpa-dev@incubator.apache.org Subject: Deployment on JBoss Hi guys, One of our users in ODE is trying to deploy on JBoss. There seems to be some configuration problems, most probably related to the presence of Hibernate in the server. He's having the following stacktrace (I trimmed the non relevant bits): 13:15:29,343 INFO [STDOUT] ERROR - ODEServer.initDAO(413) | Error instantiating DAO Connection Factory class org.apache.ode.dao.jpa.BPELDAO ConnectionFactoryImp l. javax.persistence.PersistenceException: Provider error. Provider: org.hibernate. ejb.HibernatePersistence at javax.persistence.Persistence.createFactory(Persistence.java:175) at javax.persistence.Persistence.createEntityManagerFactory (Persistence. java:111) at org.apache.ode.dao.jpa.BPELDAOConnectionFactoryImpl.init (BPELDAOConne ctionFactoryImpl.java:108) at org.apache.ode.il.dbutil.Database.createDaoCF(Database.java:267) at org.apache.ode.axis2.ODEServer.initDAO(ODEServer.java:410) at org.apache.ode.axis2.ODEServer.init(ODEServer.java:144) 13:15:31,078 INFO [STDOUT] ERROR - StandardContext.loadOnStartup(4073) | Servle t /ode threw load() exception java.lang.ClassCastException: org.hibernate.ejb.HibernatePersistence at javax.persistence.Persistence.createFactory(Persistence.java:169) at javax.persistence.Persistence.createEntityManagerFactory (Persistence. java:111) at org.apache.ode.dao.jpa.BPELDAOConnectionFactoryImpl.init (BPELDAOConne ctionFactoryImpl.java:108) at org.apache.ode.il.dbutil.Database.createDaoCF(Database.java:267) at org.apache.ode.axis2.ODEServer.initDAO(ODEServer.java:410) at org.apache.ode.axis2.ODEServer.init(ODEServer.java:144) As you can see there's a ClassCastException in javax.persistence.Persistence.createFactory which is a bit weird. Note that we instantiate the factory using a specific name: _emf = Persistence.createEntityManagerFactory(ode-dao, propMap); And that our persistence.xml *only* references the OpenJPA persistence factory. I've looked at the sources of Persistence.java in Glassfish but couldn't find the right version that seems to be used here (the createFactory method doesn't seem to exist anymore). I'm running out of ideas and thought the knowledgeable people would probably know more about the JBoss environment. Any idea? Thanks! Matthieu 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 System.out gives me the correct path to the URL: file:/home/dusty/Dev/Projects/ode/bpel-store/target/classes/META-INF/persistence.xml The corresponding file contains: persistence xmlns=http://java.sun.com/xml/ns/persistence; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1.0 persistence-unit name=ode-store providerorg.apache.openjpa.persistence.PersistenceProviderImpl /provider classorg.apache.ode.store.jpa.ProcessConfDaoImpl/class classorg.apache.ode.store.jpa.ProcessConfPropertyDaoImpl/class classorg.apache.ode.store.jpa.DeploymentUnitDaoImpl/class classorg.apache.ode.store.jpa.VersionTrackerDAOImpl/class /persistence-unit /persistence Thanks, Matthieu On 4/9/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Matthieu- Note that there shouldn't be any problem with running against a directory versus a jar (I do it all the time), so there is probably some environment issue. Can you post your persistence.xml? If you write a little main() method that just does: System.out.println(getClass().getResource(/ META-INF/persistence.xml), what does it show? On Apr 9, 2007, at 11:54 AM, Matthieu Riou wrote: Hi, I'm having some difficulties testing a module that uses persistent classes. In that case the classes aren't loaded from a jar but are directly in the classpath and so does the persistence.xml. However I always get No Persistence provider for EntityManager named ode-store. I've tried several things: - placing persistence.xml in a META-INF subdirectory of a directory directly in my classpath - placing persistence.xml in a directory directly in my classpath - renaming my persistence.xml to openjpa.xml and placing its directory directly in my classpath - setting the openjpa.properties system property to the location of the openjpa.xml None of these worked, same error message. I guess I'm missing something but can't spot what, any idea? Thanks! Matthieu
Re: Testing an OpenJPA module
I thought I had OpenJPA correctly placed but actually it wasn't copied at the right place. Thanks for the hint! Matthieu On 4/9/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Matthieu- Hmm ... the persistence.xml file is fine (I just tried it locally). I think the error No Persistence provider for EntityManager named ode- store is coming from javax.persistence.Persistence not being able to load org.apache.openjpa.persistence.PersistenceProviderImpl. Are you sure the OpenJPA jar (and all its required dependencies) are in your CLASSPATH? Can you send us the setting of your classpath? If you write a main() method that just tries new org.apache.openjpa.persistence.PersistenceProviderImpl(), what happens? On Apr 9, 2007, at 12:25 PM, Matthieu Riou wrote: The System.out gives me the correct path to the URL: file:/home/dusty/Dev/Projects/ode/bpel-store/target/classes/META- INF/persistence.xml The corresponding file contains: persistence xmlns=http://java.sun.com/xml/ns/persistence; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1.0 persistence-unit name=ode-store providerorg.apache.openjpa.persistence.PersistenceProviderImpl /provider classorg.apache.ode.store.jpa.ProcessConfDaoImpl/class classorg.apache.ode.store.jpa.ProcessConfPropertyDaoImpl/ class classorg.apache.ode.store.jpa.DeploymentUnitDaoImpl/class classorg.apache.ode.store.jpa.VersionTrackerDAOImpl/class /persistence-unit /persistence Thanks, Matthieu On 4/9/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Matthieu- Note that there shouldn't be any problem with running against a directory versus a jar (I do it all the time), so there is probably some environment issue. Can you post your persistence.xml? If you write a little main() method that just does: System.out.println(getClass().getResource(/ META-INF/persistence.xml), what does it show? On Apr 9, 2007, at 11:54 AM, Matthieu Riou wrote: Hi, I'm having some difficulties testing a module that uses persistent classes. In that case the classes aren't loaded from a jar but are directly in the classpath and so does the persistence.xml. However I always get No Persistence provider for EntityManager named ode-store. I've tried several things: - placing persistence.xml in a META-INF subdirectory of a directory directly in my classpath - placing persistence.xml in a directory directly in my classpath - renaming my persistence.xml to openjpa.xml and placing its directory directly in my classpath - setting the openjpa.properties system property to the location of the openjpa.xml None of these worked, same error message. I guess I'm missing something but can't spot what, any idea? Thanks! Matthieu
0.9.7 release
Hi guys, We've started preparing an incubator release for ODE and we're now using OpenJPA (pretty happily I should say). We can't use 0.9.6 as we need a couple of fixes from 0.9.7 so we've been using the snapshot so far. But as you know we won't be able to release with it (and generally speaking depending on snapshots is not that nice). So we were just wondering if you had any time frame so far for 0.9.7 final. I've seen that you started discussing future plans so maybe 0.9.7 should happen soon enough? Thanks, Matthieu
Re: OpenJPA love
The primary reason was the license, Hibernate is LGPL and it's not compatible with the Apache license. But we've found some other benefits during the migration. For us an important one is the good control OpenJPA gives you on the flush. Theoretically you can do the same thing with Hibernate but practically when you're in a JTA environment it just flushes whenever it wants (depending on the queries you execute). If you don't flush exclusively at the end of the transaction you can very quickly run into very hard to solve deadlocks with some non MVCC databases (thinking mostly of SQL Server 2000 here). Cheers, Matthieu On 3/12/07, Hans J. Prueller [EMAIL PROTECTED] wrote: Any special reason why you have been migrating from Hibernate to OpenJPA (in addition to that it is an Apache project)? regards, hans -Ursprüngliche Nachricht- Von: Matthieu Riou [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 13. März 2007 03:33 An: open-jpa-dev@incubator.apache.org Betreff: OpenJPA love Hi guys, Just a quick note to let you know we've completed the migration of Apache ODE from Hibernate to OpenJPA. Everything seem to work pretty well now. I expect a few glitches here and there as we run in heavily parallelized environments but the transition has been pretty smooth. Thanks a lot for your help and all the good work! The ODE team.
OpenJPA love
Hi guys, Just a quick note to let you know we've completed the migration of Apache ODE from Hibernate to OpenJPA. Everything seem to work pretty well now. I expect a few glitches here and there as we run in heavily parallelized environments but the transition has been pretty smooth. Thanks a lot for your help and all the good work! The ODE team.
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: open-jpa-dev
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
Entity manager injection
Hi, For ODE we're managing our transactions ourselves. We start them and commit them explicitly. By the same token we create the EntityManagerFactory ourselves. Is there a possibility to use the EntityManager injection in the persistent classes in this context or do we have to implement our own ThreadLocal based thingy to have the EM available in our persistent classes using it? I've tried doing something like: 1. Adding @PersistenceContext private EntityManager _em; in a persistence class. 2. Load the persistence class from an EntityManager created with the factory. 3. Use _em in my persistent class = NullPointerException Thanks, Matthieu
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.CorrelatorDAOImpl;org.apache.ode.dao.jpa.EventDAOImpl;org.apache.ode.dao.jpa.FaultDAOImpl;org.apache.ode.dao.jpa.MessageDAOImpl;org.apache.ode.dao.jpa.MessageExchangeDAOImpl;org.apache.ode.dao.jpa.MessageRouteDAOImpl;org.apache.ode.dao.jpa.PartnerLinkDAOImpl;org.apache.ode.dao.jpa.ProcessDAOImpl;org.apache.ode.dao.jpa.ProcessInstanceDAOImpl;org.apache.ode.dao.jpa.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
openjpa.ProxyManager: default
29604 ode-dao TRACE [http-8080-Processor25] openjpa.MetaData - Using
metadata factory
[EMAIL PROTECTED].
29604 ode-dao INFO [http-8080-Processor25] openjpa.jdbc.JDBC - Using
dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary.
WARN - BPELDAOConnectionFactoryImpl$DebugTxMgr.getTransaction(130) | JPA get
transaction
WARN
Re: OpenJPA Transaction configuration
Thanks! But shouldn't I worry about the fact that a brand new instance is
detached? I could be wrong but it looks like it's more a symptom of
something wrong in my configuration, no?
On 2/28/07, Pinaki Poddar [EMAIL PROTECTED] wrote:
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
Re: OpenJPA Transaction configuration
Here is a link to the source (and no version field): http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/src/main/java/org/apache/ode/dao/jpa/ProcessDAOImpl.java How can I try to change the default detach manager? Which one should I use instead? Thanks! Matthieu On 2/28/07, Patrick Linskey [EMAIL PROTECTED] wrote: Can you post the source for ProcessDAOImpl? Also, are there any other OpenJPA properties in your configuration? Finally, I'm assuming that you're using a somewhat-current 0.9.7-SNAPSHOT. Correct me if I'm wrong. But shouldn't I worry about the fact that a brand new instance is detached? I could be wrong but it looks like it's more a symptom of I believe that you should. I think I remember reading something about this recently, but I don't remember the details. My suspicion is that you don't have an @Version field, and you're using the default detach manager. IIRC, this combination leaves OpenJPA with no way to detect a detached object vs. a new object, and we default to detached. I thought that we had improved the docs around this at the least; certainly, it'd be good to figure out your particulars and make sure that this is clearer for others. (IIRC, the default detach manager uses a heuristic on the value in the version field to determine whether an instance is new or detached. OpenJPA supports more flexible detach managers that can do fun things like providing useful errors when attempting to navigate past the end of a detached object graph, and fine-grained tracking of changes made while detached. But it's not serialization-compatible with the unenhanced code, meaning that you need to put the enhanced classes into your client tier, which I think that we decided was a bad default.) -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: Wednesday, February 28, 2007 7:50 PM To: Pinaki Poddar Cc: open-jpa-dev@incubator.apache.org Subject: Re: OpenJPA Transaction configuration Thanks! But shouldn't I worry about the fact that a brand new instance is detached? I could be wrong but it looks like it's more a symptom of something wrong in my configuration, no? On 2/28/07, Pinaki Poddar [EMAIL PROTECTED] wrote: 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
Re: No tx commit when providing ManagedRuntime
Thanks for all the options, I'll try that.
On 1/24/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Matthieu-
My only other guess is that you might not actually be using your
ManagedRuntime setting, because we might need it to be a String (the
fully-qualified class name of your ManagedRuntime implementation),
rather than an actual instance of the class. Can you try specifying
the class name in the openjpa.ManagedRuntime setting? Also, try
enabling TRACE logging and posting the complete output from when you
run your test, since that might help show what the value is getting
set to.
If it's not that, then I'm afraid I'm stumped.
Can you try to debug it by either seeing if you can enable logging
for the JOTM TransactionManager, or by subclassing it? I want to see
if TransactionManager.registerSynchronization(broker) is ever being
called. Alternately, you can put in some debugging code in
AbstractBrokerFactory.syncWithManagedTransaction() and rebuilding
OpenJPA and seeing if that is ever called, although that might be
more work.
On Jan 24, 2007, at 2:49 PM, Matthieu Riou wrote:
Any idea why my transaction manager setting seems to be ignored?
Thanks,
Matthieu
On 1/16/07, Matthieu Riou [EMAIL PROTECTED] wrote:
Hi,
I've tried several thing:
- First I made sure that the tx was started when I get the
EntityManager.
- Second I've tried calling em.joinTransaction() while the
transaction is
being executed, didn't change anything.
- Lastly I've tried to call em.flush() before commit and got the
following:
Caused by: 4|false|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.TransactionRequiredException: Can only
perform operation while a transaction is active.
at
org.apache.openjpa.kernel.BrokerImpl.assertActiveTransaction(
BrokerImpl.java:4250)
at
org.apache.openjpa.kernel.DelegatingBroker.assertActiveTransaction(
DelegatingBroker.java:1292)
at org.apache.openjpa.persistence.EntityManagerImpl.flush(
EntityManagerImpl.java:472)
at org.apache.ode.bpel.engine.BpelDatabase$1.call(
BpelDatabase.java:79)
at
org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl.execTransact
ion (
QuartzSchedulerImpl.java:245)
at org.apache.ode.bpel.engine.BpelDatabase.exec
(BpelDatabase.java
:75)
Seems that it doesn't see the transaction at all. Is there
something I
could check or make sure that the tx mgr is properly associated?
Thanks,
Matthieu
On 1/15/07, Patrick Linskey [EMAIL PROTECTED] wrote:
Also, what happens if you manually call flush() at the end of your
persistence operations? This should at least tell us something
about
whether or not the connections are being used correctly.
-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: Marc Prud'hommeaux [mailto: [EMAIL PROTECTED] On
Behalf Of Marc Prud'hommeaux
Sent: Monday, January 15, 2007 4:22 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: No tx commit when providing ManagedRuntime
Matthieu-
That's pretty weird. What happens if you just try to manually
commit
the transaction from the EntityManager itself (with
em.getTransaction
().commit())?
Also, has the global transaction already been started as the
point
when you obtain the EntityManager from the EntityManagerFactory?
Finally, what happens if you call em.joinTransaction() and then
commit the global transaction. Any change?
On Jan 15, 2007, at 3:41 PM, Matthieu Riou wrote:
Does your TxMgrProvider provide a correctly functioning
TransactionManager? OpenJPA will register a
Synchronization with it,
which should get committed when your global transaction is
committed.
It does, I directly provide JOTM transaction manager. The
same code
works
correctly with Hibernate as far as transaction handling is
concerned. My
managedRuntime impl is just:
public class TxMgrProvider implements ManagedRuntime {
public TxMgrProvider() {
}
public TransactionManager getTransactionManager() throws
Exception {
return _txMgr;
}
}
Do you see any log messages at all when you commit the global
transaction?
No I don't. I only see some selects here and there. For example
there should
be a commit between the 2
Re: No tx commit when providing ManagedRuntime
Hi,
I've tried several thing:
- First I made sure that the tx was started when I get the EntityManager.
- Second I've tried calling em.joinTransaction() while the transaction is
being executed, didn't change anything.
- Lastly I've tried to call em.flush() before commit and got the following:
Caused by: 4|false|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.TransactionRequiredException: Can only
perform operation while a transaction is active.
at org.apache.openjpa.kernel.BrokerImpl.assertActiveTransaction(
BrokerImpl.java:4250)
at
org.apache.openjpa.kernel.DelegatingBroker.assertActiveTransaction(
DelegatingBroker.java:1292)
at org.apache.openjpa.persistence.EntityManagerImpl.flush(
EntityManagerImpl.java:472)
at org.apache.ode.bpel.engine.BpelDatabase$1.call(BpelDatabase.java
:79)
at
org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl.execTransaction(
QuartzSchedulerImpl.java:245)
at org.apache.ode.bpel.engine.BpelDatabase.exec(BpelDatabase.java
:75)
Seems that it doesn't see the transaction at all. Is there something I could
check or make sure that the tx mgr is properly associated?
Thanks,
Matthieu
On 1/15/07, Patrick Linskey [EMAIL PROTECTED] wrote:
Also, what happens if you manually call flush() at the end of your
persistence operations? This should at least tell us something about
whether or not the connections are being used correctly.
-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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
Behalf Of Marc Prud'hommeaux
Sent: Monday, January 15, 2007 4:22 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: No tx commit when providing ManagedRuntime
Matthieu-
That's pretty weird. What happens if you just try to manually commit
the transaction from the EntityManager itself (with
em.getTransaction
().commit())?
Also, has the global transaction already been started as the point
when you obtain the EntityManager from the EntityManagerFactory?
Finally, what happens if you call em.joinTransaction() and then
commit the global transaction. Any change?
On Jan 15, 2007, at 3:41 PM, Matthieu Riou wrote:
Does your TxMgrProvider provide a correctly functioning
TransactionManager? OpenJPA will register a
Synchronization with it,
which should get committed when your global transaction is
committed.
It does, I directly provide JOTM transaction manager. The
same code
works
correctly with Hibernate as far as transaction handling is
concerned. My
managedRuntime impl is just:
public class TxMgrProvider implements ManagedRuntime {
public TxMgrProvider() {
}
public TransactionManager getTransactionManager() throws
Exception {
return _txMgr;
}
}
Do you see any log messages at all when you commit the global
transaction?
No I don't. I only see some selects here and there. For example
there should
be a commit between the 2 following selects:
58194 ode-dao TRACE [Thread-4] openjpa.Query - Executing query:
select p
from ProcessDAOImpl p
58205 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - t
21912919, conn
30031746 executing prepstmnt 8828117 SELECT t0.PROCESS_ID,
t0.VERSION,
t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
t0.PROCESS_TYPE FROM ODE_PROCESS t0
58206 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - t
21912919, conn
30031746 [1 ms] spent
58206 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - t 21912919,
conn
30031746 [0 ms] close
58208 ode-dao TRACE [Thread-4] openjpa.Query - Executing query:
select p
from ProcessDAOImpl p
58208 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - t
21912919, conn
13257390 executing prepstmnt 15527192 SELECT t0.PROCESS_ID,
t0.VERSION,
t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
t0.PROCESS_TYPE FROM ODE_PROCESS t0
58209 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - t
21912919, conn
13257390 [0 ms] spent
58209 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - t 21912919,
conn
13257390 [0 ms] close
Thanks,
Matthieu
On Jan 15, 2007, at 10:35 AM, Matthieu Riou wrote:
Hi,
I now have a working setup (at least something that
starts) using a
programmaticaly provided datasource and transaction manager. Here
is the
code now:
HashMap propMap = new HashMap
Re: Using _attributes
I see. I specifically had problems with relation tables though. I had columns generated as _attribute_OTHERTABLENAME and the first _ didn't make it through Derby. Hence the necessary usage of @ElementJoinColumn. Are these mandated by the spec as well? On 1/15/07, Abe White [EMAIL PROTECTED] wrote: I think it could be nicer and a bit easier if OpenJPA was automatically eliminating the first _ from attribute names to build its default coumn names, don't you think? The default column names are mandated by the JPA specification. And unless you're using OpenJPA-specific mappings, you shouldn't have to use OpenJPA-specific annotations just to rename columns. The JPA spec includes standard annotations for naming the columns in all standard mappings. ___ 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.
No tx commit when providing ManagedRuntime
Hi, I now have a working setup (at least something that starts) using a programmaticaly provided datasource and transaction manager. Here is the code now: HashMap propMap = new HashMap(); propMap.put(openjpa.jdbc.DBDictionary, org.apache.openjpa.jdbc.sql.DerbyDictionary); propMap.put(openjpa.ManagedRuntime, new TxMgrProvider()); propMap.put(openjpa.ConnectionFactory, _datasource); propMap.put(openjpa.Log, DefaultLevel=TRACE); EntityManagerFactory emf = Persistence.createEntityManagerFactory(ode-dao, propMap); HashMap propMap2 = new HashMap(); propMap2.put(openjpa.TransactionMode, managed); EntityManager em = emf.createEntityManager(propMap2); _daoCF = new BPELDAOConnectionFactoryImpl(em); I've tried both with and without the propMap2, in both cases I never get OpenJPA to commit (and therefore no insert/update/delete) when I commit the transaction. Any idea of what could be wrong? Thanks! Matthieu
Re: No tx commit when providing ManagedRuntime
Does your TxMgrProvider provide a correctly functioning
TransactionManager? OpenJPA will register a Synchronization with it,
which should get committed when your global transaction is committed.
It does, I directly provide JOTM transaction manager. The same code works
correctly with Hibernate as far as transaction handling is concerned. My
managedRuntime impl is just:
public class TxMgrProvider implements ManagedRuntime {
public TxMgrProvider() {
}
public TransactionManager getTransactionManager() throws Exception {
return _txMgr;
}
}
Do you see any log messages at all when you commit the global
transaction?
No I don't. I only see some selects here and there. For example there should
be a commit between the 2 following selects:
58194 ode-dao TRACE [Thread-4] openjpa.Query - Executing query: select p
from ProcessDAOImpl p
58205 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - t 21912919, conn
30031746 executing prepstmnt 8828117 SELECT t0.PROCESS_ID, t0.VERSION,
t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
t0.PROCESS_TYPE FROM ODE_PROCESS t0
58206 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - t 21912919, conn
30031746 [1 ms] spent
58206 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - t 21912919, conn
30031746 [0 ms] close
58208 ode-dao TRACE [Thread-4] openjpa.Query - Executing query: select p
from ProcessDAOImpl p
58208 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - t 21912919, conn
13257390 executing prepstmnt 15527192 SELECT t0.PROCESS_ID, t0.VERSION,
t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
t0.PROCESS_TYPE FROM ODE_PROCESS t0
58209 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - t 21912919, conn
13257390 [0 ms] spent
58209 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - t 21912919, conn
13257390 [0 ms] close
Thanks,
Matthieu
On Jan 15, 2007, at 10:35 AM, Matthieu Riou wrote:
Hi,
I now have a working setup (at least something that starts) using a
programmaticaly provided datasource and transaction manager. Here
is the
code now:
HashMap propMap = new HashMap();
propMap.put(openjpa.jdbc.DBDictionary,
org.apache.openjpa.jdbc.sql.DerbyDictionary);
propMap.put(openjpa.ManagedRuntime, new TxMgrProvider());
propMap.put(openjpa.ConnectionFactory, _datasource);
propMap.put(openjpa.Log, DefaultLevel=TRACE);
EntityManagerFactory emf =
Persistence.createEntityManagerFactory(ode-dao,
propMap);
HashMap propMap2 = new HashMap();
propMap2.put(openjpa.TransactionMode, managed);
EntityManager em = emf.createEntityManager(propMap2);
_daoCF = new BPELDAOConnectionFactoryImpl(em);
I've tried both with and without the propMap2, in both cases I
never get
OpenJPA to commit (and therefore no insert/update/delete) when I
commit the
transaction.
Any idea of what could be wrong?
Thanks!
Matthieu
Re: Configuration: either / or ?
If I don't set openjpa.ConnectionDriverName (and even if I set openjpa.ConnectionFactory with my datasource instance) I get the A JDBC Driver or DataSource class name must be specified in the ConnectionDriverName property error. So I'm getting more and more confused as to which properties I should set... On 1/8/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Matthieu- I think you want openjpa.ConnectionFactory, not openjpa.ConnectionDriverName. On Jan 8, 2007, at 9:45 AM, Matthieu Riou wrote: Hi, I've just tried your fix after compiling the OpenJPA trunk. I'm getting a ClassCastException as the openjpa.ConnectionDriverName is set as a StringValue. Should I use another property instead? My code: propMap.put(openjpa.jdbc.DBDictionary, org.apache.openjpa.jdbc.sql.DerbyDictionary); propMap.put(openjpa.ManagedRuntime, new TxMgrProvider()); propMap.put(openjpa.ConnectionDriverName, _datasource); propMap.put(openjpa.Log, DefaultLevel=TRACE); EntityManagerFactory emf = Persistence.createEntityManagerFactory(ode-dao, propMap); EntityManager em = emf.createEntityManager(); The exception: 0|true|0.9.7-incubating-SNAPSHOT org.apache.openjpa.persistence.PersistenceException: There was an error when invoking the static newInstance method on the named factory class org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory. See the nested exception for details. at org.apache.openjpa.kernel.Bootstrap.newBrokerFactory( Bootstrap.java:62) at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityMan agerFactory (PersistenceProviderImpl.java:70) at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityMan agerFactory (PersistenceProviderImpl.java:78) at javax.persistence.Persistence.createEntityManagerFactory( Persistence.java:83) at org.apache.ode.axis2.ODEServerJPA.initJPA (ODEServerJPA.java:345) at org.apache.ode.axis2.ODEServerJPA.init(ODEServerJPA.java:96) at org.apache.ode.axis2.hooks.ODEAxisServlet.init( ODEAxisServlet.java:50) at org.apache.catalina.core.StandardWrapper.loadServlet( StandardWrapper.java:1105) at org.apache.catalina.core.StandardWrapper.load( StandardWrapper.java:932) at org.apache.catalina.core.StandardContext.loadOnStartup( StandardContext.java:3917) at org.apache.catalina.core.StandardContext.start( StandardContext.java:4201) at org.apache.catalina.core.ContainerBase.addChildInternal( ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild( ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild (StandardHost.java :524) at org.apache.catalina.startup.HostConfig.deployWAR (HostConfig.java :809) at org.apache.catalina.startup.HostConfig.deployWARs (HostConfig.java :698) at org.apache.catalina.startup.HostConfig.deployApps (HostConfig.java :472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java :1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent( HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent( LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start (ContainerBase.java :1021) at org.apache.catalina.core.StandardHost.start (StandardHost.java :718) at org.apache.catalina.core.ContainerBase.start (ContainerBase.java :1013) at org.apache.catalina.core.StandardEngine.start (StandardEngine.java :442) at org.apache.catalina.core.StandardService.start( StandardService.java:450) at org.apache.catalina.core.StandardServer.start (StandardServer.java :709) at org.apache.catalina.startup.Catalina.start(Catalina.java: 551) 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 org.apache.catalina.startup.Bootstrap.start (Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java: 432) Caused by: org.apache.openjpa.lib.util.ParseException: ConnectionDriverName: [EMAIL PROTECTED] at org.apache.openjpa.lib.conf.Value.setObject(Value.java:298) at org.apache.openjpa.lib.conf.ConfigurationImpl.fromProperties( ConfigurationImpl.java:627) at org.apache.openjpa.lib.conf.MapConfigurationProvider.setInto( MapConfigurationProvider.java:82) at org.apache.openjpa.persistence.PersistenceProductDerivation $ConfigurationProviderImpl.setInto (PersistenceProductDerivation.java:406) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newInstance( JDBCBrokerFactory.java:56
Re: Configuration: either / or ?
Hi, I've just tried your fix after compiling the OpenJPA trunk. I'm getting a ClassCastException as the openjpa.ConnectionDriverName is set as a StringValue. Should I use another property instead? My code: propMap.put(openjpa.jdbc.DBDictionary, org.apache.openjpa.jdbc.sql.DerbyDictionary); propMap.put(openjpa.ManagedRuntime, new TxMgrProvider()); propMap.put(openjpa.ConnectionDriverName, _datasource); propMap.put(openjpa.Log, DefaultLevel=TRACE); EntityManagerFactory emf = Persistence.createEntityManagerFactory(ode-dao, propMap); EntityManager em = emf.createEntityManager(); The exception: 0|true|0.9.7-incubating-SNAPSHOT org.apache.openjpa.persistence.PersistenceException: There was an error when invoking the static newInstance method on the named factory class org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory. See the nested exception for details. at org.apache.openjpa.kernel.Bootstrap.newBrokerFactory( Bootstrap.java:62) at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory (PersistenceProviderImpl.java:70) at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory (PersistenceProviderImpl.java:78) at javax.persistence.Persistence.createEntityManagerFactory( Persistence.java:83) at org.apache.ode.axis2.ODEServerJPA.initJPA(ODEServerJPA.java:345) at org.apache.ode.axis2.ODEServerJPA.init(ODEServerJPA.java:96) at org.apache.ode.axis2.hooks.ODEAxisServlet.init( ODEAxisServlet.java:50) at org.apache.catalina.core.StandardWrapper.loadServlet( StandardWrapper.java:1105) at org.apache.catalina.core.StandardWrapper.load( StandardWrapper.java:932) at org.apache.catalina.core.StandardContext.loadOnStartup( StandardContext.java:3917) at org.apache.catalina.core.StandardContext.start( StandardContext.java:4201) at org.apache.catalina.core.ContainerBase.addChildInternal( ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild( ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java :524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java :809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java :698) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java :472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java :1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent( HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent( LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java :1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java :718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java :1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java :442) at org.apache.catalina.core.StandardService.start( StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java :709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) 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 org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) Caused by: org.apache.openjpa.lib.util.ParseException: ConnectionDriverName: [EMAIL PROTECTED] at org.apache.openjpa.lib.conf.Value.setObject(Value.java:298) at org.apache.openjpa.lib.conf.ConfigurationImpl.fromProperties( ConfigurationImpl.java:627) at org.apache.openjpa.lib.conf.MapConfigurationProvider.setInto( MapConfigurationProvider.java:82) at org.apache.openjpa.persistence.PersistenceProductDerivation$ConfigurationProviderImpl.setInto (PersistenceProductDerivation.java:406) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newInstance( JDBCBrokerFactory.java:56) 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 org.apache.openjpa.kernel.Bootstrap.invokeFactory(Bootstrap.java :117) at org.apache.openjpa.kernel.Bootstrap.newBrokerFactory( Bootstrap.java:57) ... 32 more Caused by: java.lang.ClassCastException: org.opentools.minerva.connector.jdbc.JDBCDataSource at org.apache.openjpa.lib.conf.StringValue.setInternalObject( StringValue.java:63)
Configuration: either / or ?
Hi all, I've been fighting for some time now with my OpenJPA configuration and just discovered why. It seems that you *either* consider the persistence.xml file *or* the map passed as parameter of Persistence.createEntityManagerFactory. If you look at PersistenceProductDerivation.load(String rsrc, String name, Map m) (line 151), if the configuration provider can find a configuration file then the configuration is returned as is and the provided configuration Map doesn't even gets considered. My expectations would have been to have both the xml file and the map being used. One or the other can prevail if a property is defined twice but I think the map shouldn't be plainly ignored when provided. What do you think? Would that be a bug or is it the desired behavior? Thanks! Matthieu
Re: Configuration: either / or ?
Sorry I've jumped too quickly to conclusions. The mistake was mine. However I'm trying to initialize OpenJPA programmatically using the following code: HashMap propMap = new HashMap(); propMap.put(openjpa.ManagedRuntime, new TxMgrProvider(_txMgr)); propMap.put(openjpa.ConnectionDriverName, org.apache.derby.jdbc.EmbeddedDriver.class.getName()); propMap.put(openjpa.ConnectionFactory, _datasource); EntityManagerFactory emf = Persistence.createEntityManagerFactory(ode-dao, propMap); EntityManager em = emf.createEntityManager(propMap); The TxMgrProvider implements the ManagedRuntime interface. When execute, for each of the Map key I'm passing I'm getting: 4|false|0.9.6-incubating-SNAPSHOT org.apache.openjpa.persistence.ArgumentException: Missing getter for property ConnectionDriverName in type class org.apache.openjpa.persistence.EntityManagerImpl. With the NoSuchMethodException that comes together. As I'm passing configuration properties I don't get why it tries to set of get them on the entity manager. I guess I'm doing something wrong, do you have an idea of what could that be? Thanks! Matthieu On 1/3/07, Abe White [EMAIL PROTECTED] wrote: I've been fighting for some time now with my OpenJPA configuration and just discovered why. It seems that you *either* consider the persistence.xml file *or* the map passed as parameter of Persistence.createEntityManagerFactory. If you look at PersistenceProductDerivation.load(String rsrc, String name, Map m) (line 151), if the configuration provider can find a configuration file then the configuration is returned as is and the provided configuration Map doesn't even gets considered. I don't see this. The Map is passed along to the method that loads the configuration file, which passes it along to the configuration parser, which sets its entries over the properties it parses. ___ 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: Configuration: either / or ?
But if I don't provide openjpa.ConnectionDriverName the call to createEntityManager fails with an exception saying that ConnectionDriverName should be provided (coming from DataSourceFactory): 4|true|0.9.6-incubating-SNAPSHOT org.apache.openjpa.persistence.ArgumentException: A JDBC Driver or DataSource class name must be specified in the ConnectionDriverName property. at org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource( DataSourceFactory.java:67) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.createConnectionFactory( JDBCConfigurationImpl.java:797) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDBDictionaryInstance( JDBCConfigurationImpl.java:563) at org.apache.openjpa.jdbc.meta.MappingRepository.endConfiguration( MappingRepository.java:1167) at org.apache.openjpa.lib.conf.Configurations.configureInstance( Configurations.java:355) at org.apache.openjpa.lib.conf.Configurations.configureInstance( Configurations.java:280) at org.apache.openjpa.lib.conf.PluginValue.instantiate( PluginValue.java:99) at org.apache.openjpa.lib.conf.ObjectValue.instantiate( ObjectValue.java:70) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.newMetaDataRepositoryInstance (OpenJPAConfigurationImpl.java:834) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.getMetaDataRepositoryInstance (OpenJPAConfigurationImpl.java:829) at org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly( AbstractBrokerFactory.java:526) at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker( AbstractBrokerFactory.java:147) at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker( DelegatingBrokerFactory.java:139) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager( EntityManagerFactoryImpl.java:187) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager( EntityManagerFactoryImpl.java:52) at org.apache.ode.axis2.ODEServerJPA.initJPA(ODEServerJPA.java:344) On 1/3/07, Abe White [EMAIL PROTECTED] wrote: When execute, for each of the Map key I'm passing I'm getting: 4|false|0.9.6-incubating-SNAPSHOT org.apache.openjpa.persistence.ArgumentException: Missing getter for property ConnectionDriverName in type class org.apache.openjpa.persistence.EntityManagerImpl. Because you shouldn't be passing your property map to the createEntityManager call. That call takes EntityManager properties, not EntityManagerFactory settings. ___ 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: Configuration: either / or ?
Right. Sorry about that. Even though my ConnectionDriverName is still not properly picked up: ERROR - ApplicationContext.log(675) | StandardWrapper.Throwable 4|true|0.9.6-incubating-SNAPSHOT org.apache.openjpa.persistence.ArgumentException: A JDBC Driver or DataSource class name must be specified in the ConnectionDriverName property. at org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource( DataSourceFactory.java:67) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.createConnectionFactory( JDBCConfigurationImpl.java:797) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDBDictionaryInstance( JDBCConfigurationImpl.java:563) at org.apache.openjpa.jdbc.meta.MappingRepository.endConfiguration( MappingRepository.java:1167) at org.apache.openjpa.lib.conf.Configurations.configureInstance( Configurations.java:355) at org.apache.openjpa.lib.conf.Configurations.configureInstance( Configurations.java:280) at org.apache.openjpa.lib.conf.PluginValue.instantiate( PluginValue.java:99) at org.apache.openjpa.lib.conf.ObjectValue.instantiate( ObjectValue.java:70) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.newMetaDataRepositoryInstance (OpenJPAConfigurationImpl.java:834) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.getMetaDataRepositoryInstance (OpenJPAConfigurationImpl.java:829) at org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly( AbstractBrokerFactory.java:526) at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker( AbstractBrokerFactory.java:147) at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker( DelegatingBrokerFactory.java:139) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager( EntityManagerFactoryImpl.java:187) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager( EntityManagerFactoryImpl.java:52) at org.apache.ode.axis2.ODEServerJPA.initJPA(ODEServerJPA.java:344) On 1/3/07, Abe White [EMAIL PROTECTED] wrote: But if I don't provide openjpa.ConnectionDriverName the call to createEntityManager fails with an exception saying that ConnectionDriverName should be provided (coming from DataSourceFactory): You need to provide it to createEntityManagerFactory. Not to createEntityManager. You shouldn't be passing anything to createEntityManager. Use the no-args version. ___ 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: Configuration: either / or ?
My ultimate goal is to provide directly an instance of DataSource that OpenJPA would use instead of trying to lookup or create one. It seems that it's possible by setting ConnectionFactory to the datasource instance but OpenJPA fails before that if no ConnectionDriverName is specified. Abe is right when saying that I should provide the properties to createEntityManager insteand of createEntityManagerFactory but I still can't find to way to initialize everything property. Thanks, Matthieu On 1/3/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Matthieu- Can you send the complete stack trace? Also, I don't think this is the cause of the problem, but why are you specifying both ConnectionDriverName and ConnectionFactory? With ConnectionFactory specified, you shouldn't need to specify the ConnectionDriverName. On Jan 3, 2007, at 5:01 PM, Matthieu Riou wrote: Sorry I've jumped too quickly to conclusions. The mistake was mine. However I'm trying to initialize OpenJPA programmatically using the following code: HashMap propMap = new HashMap(); propMap.put(openjpa.ManagedRuntime, new TxMgrProvider (_txMgr)); propMap.put(openjpa.ConnectionDriverName, org.apache.derby.jdbc.EmbeddedDriver.class.getName()); propMap.put(openjpa.ConnectionFactory, _datasource); EntityManagerFactory emf = Persistence.createEntityManagerFactory(ode-dao, propMap); EntityManager em = emf.createEntityManager(propMap); The TxMgrProvider implements the ManagedRuntime interface. When execute, for each of the Map key I'm passing I'm getting: 4|false|0.9.6-incubating-SNAPSHOT org.apache.openjpa.persistence.ArgumentException: Missing getter for property ConnectionDriverName in type class org.apache.openjpa.persistence.EntityManagerImpl. With the NoSuchMethodException that comes together. As I'm passing configuration properties I don't get why it tries to set of get them on the entity manager. I guess I'm doing something wrong, do you have an idea of what could that be? Thanks! Matthieu On 1/3/07, Abe White [EMAIL PROTECTED] wrote: I've been fighting for some time now with my OpenJPA configuration and just discovered why. It seems that you *either* consider the persistence.xml file *or* the map passed as parameter of Persistence.createEntityManagerFactory. If you look at PersistenceProductDerivation.load(String rsrc, String name, Map m) (line 151), if the configuration provider can find a configuration file then the configuration is returned as is and the provided configuration Map doesn't even gets considered. I don't see this. The Map is passed along to the method that loads the configuration file, which passes it along to the configuration parser, which sets its entries over the properties it parses. _ __ 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: Configuration: either / or ?
Cool! I've tried to set openjpa.Log but like all other properties it doesn't get considered by the entity manager. It's just like my whole Map gets ignored. I'm also setting the DBDictionary but it also gets ignored as I get the dictionary auto-detection message... Something else I can do to debug this? I'm able to do a step-by-step into the code but it seems that the properties on configuration classes are set through introspection so it's hard to track down. On 1/3/07, Abe White [EMAIL PROTECTED] wrote: I'm able to reproduce the ConnectionDriverName problem. I'll have more info in a bit. ___ 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: Configuration: either / or ?
I'm still having the same problem (it can't find my ConnectionDriverName property). Now my code looks like: HashMap propMap = new HashMap(); propMap.put(openjpa.jdbc.DBDictionary, org.apache.openjpa.jdbc.sql.DerbyDictionary); propMap.put(openjpa.ManagedRuntime, TxMgrProvider.class.getName ()); propMap.put(openjpa.ConnectionDriverName, org.apache.derby.jdbc.EmbeddedDriver.class.getName()); propMap.put(javax.persistence.nonJtaDataSource, _datasource); propMap.put(openjpa.Log, DefaultLevel=TRACE); EntityManagerFactory emf = Persistence.createEntityManagerFactory (ode-dao); EntityManager em = emf.createEntityManager(propMap); As you can see everything is a string exception javax.persistence.nonJtaDataSource. I even tried to comment out this property to only have string properties and I still got the same error. I have 2 questions thought: 1. If the loading of one property fails, no property gets loaded? 2. I keep on looking at the code in EntityManagerFactoryImpl.createEntityManager. The error appears on the call to _factory.newBroker and it seems to me that nothing much is done with the provided Map before that. When does the Map gets used exactly? Thanks a lot for your help! On 1/3/07, Abe White [EMAIL PROTECTED] wrote: OK, the problem is that we're only paying attention to openjpa.* property keys with String values when you bootstrap through Persistence. I have no idea why, and I'll change it momentarily. But for now, you can work around the problem for your DataSource using the javax.persistence.nonJtaDataSource key instead of openjpa.ConnectionFactory. Unfortunately no such workaround exists for the ManagedRuntime. ___ 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.
Setting a datasource and a transaction manager
Hi JPA guys, In the Apache Ode podling we're currently working on replacing Hibernate with OpenJPA. It's been working great so far but I have a couple of questions. I'd need to set the transaction manager and the datasource manually using the OpenJPA API and I've been unable to find the right class and the right setters so far. Is there an easy way to do that? The use case is we need to run both in containers with their own tx manager (like Geronimo) and lightweight containers (like Tomcat). In the lightweight case we instantiate our own transaction manager (JOTM) and our own datasource (Minerva) and we don't need any JNDI (unnecessary painful). I've been looking around and haven't found an easy way. I could have a look at the sources but I figured that asking you directly would be quicker. Thanks! Matthieu
Re: Setting a datasource and a transaction manager
Sorry to be a pain but the thing is, we don't want to use any JNDI to register our datasource. We just create our own so that would mean creating a whole JNDI registry just to pass a datasource to Kodo. So my question was whether there was the same type of interface I could implement to return our custom datasource. Thanks, Matthieu On 12/13/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Matthieu- If you set the openjpa.ConnectionFactoryName to the JNDI name of a DataSource, then Kodo will use that. See: http://incubator.apache.org/openjpa/docs/latest/manual/ manual.html#ref_guide_dbsetup On Dec 13, 2006, at 4:21 PM, Matthieu Riou wrote: Thanks Marc! And what about the datasource? Is there another equivalent interface and property to use? On 12/13/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Matthieu- If you have a custom TransactionManager, you can tell Kodo to access it using a ManagedRuntime implementation (see http:// incubator.apache.org/openjpa/docs/latest/javadoc/org/apache/openjpa/ ee/ManagedRuntime.html ). For example, if your TransactionManager is accessible via the JNDI name comp/env/MyTransactionManager, then you could tell OpenJPA to access it by setting the openjpa.ManagedRuntime property to the value: org.apache.openjpa.ee.JNDIManagedRuntime (TransactionManagerName=comp/env/MyTransactionManager). For more exotic mechanisms of accessing the TransactionManager, you can just make a custom implementation of the ManagedRuntime class. In the future, we intent to make this more standard by utilizing the new javax.transaction.TransactionSynchronizationRegistry mechanism, but for now, we have custom implementations for each of our known and supported application servers (see the code at http://svn.apache.org/ viewvc/incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/ apache/openjpa/ee/AutomaticManagedRuntime.java? view=markuppathrev=468504 ). See also: http://incubator.apache.org/openjpa/docs/latest/manual/ manual.html#ref_guide_enterprise_trans On Dec 13, 2006, at 1:13 PM, Matthieu Riou wrote: Hi JPA guys, In the Apache Ode podling we're currently working on replacing Hibernate with OpenJPA. It's been working great so far but I have a couple of questions. I'd need to set the transaction manager and the datasource manually using the OpenJPA API and I've been unable to find the right class and the right setters so far. Is there an easy way to do that? The use case is we need to run both in containers with their own tx manager (like Geronimo) and lightweight containers (like Tomcat). In the lightweight case we instantiate our own transaction manager (JOTM) and our own datasource (Minerva) and we don't need any JNDI (unnecessary painful). I've been looking around and haven't found an easy way. I could have a look at the sources but I figured that asking you directly would be quicker. Thanks! Matthieu
Re: Setting a datasource and a transaction manager
But I can't use that. In the same way that I have to provide the transaction
manager to Kodo, I have to provide this transaction manager to the
datasource as well. To create the datasource we're doing something like:
MinervaPool minervaPool = new MinervaPool();
minervaPool.setTransactionManager(_txMgr);
minervaPool.getConnectionFactory().setConnectionURL(url);
minervaPool.getConnectionFactory().setUserName(sa);
minervaPool.getConnectionFactory().setDriver(
org.apache.derby.jdbc.EmbeddedDriver.class.getName());
minervaPool.getPoolParams().maxSize = _odeConfig.getPoolMaxSize();
minervaPool.getPoolParams().minSize = _odeConfig.getPoolMinSize();
minervaPool.getPoolParams().blocking = false;
minervaPool.setType(MinervaPool.PoolType.MANAGED);
try {
minervaPool.start();
} catch (Exception ex) {
String errmsg = __msgs.msgOdeDbPoolStartupFailed(url);
__log.error(errmsg, ex);
throw new ServletException(errmsg, ex);
}
_datasource = minervaPool.createDataSource();
The most important things are to set the tx mgr and the type of the pool to
'managed'. So if I use the openjpa.ConnectionDriverName, would Kodo
configure Miverva properly?
Thanks,
Matthieu
On 12/13/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Matthieu-
You can specify the full class name of your DataSource in the
openjpa.ConnectionDriverName property. This too is discussed at
http://incubator.apache.org/openjpa/docs/latest/manual/
manual.html#ref_guide_dbsetup
On Dec 13, 2006, at 4:42 PM, Matthieu Riou wrote:
Sorry to be a pain but the thing is, we don't want to use any JNDI to
register our datasource. We just create our own so that would mean
creating
a whole JNDI registry just to pass a datasource to Kodo. So my
question was
whether there was the same type of interface I could implement to
return our
custom datasource.
Thanks,
Matthieu
On 12/13/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Matthieu-
If you set the openjpa.ConnectionFactoryName to the JNDI name of a
DataSource, then Kodo will use that.
See: http://incubator.apache.org/openjpa/docs/latest/manual/
manual.html#ref_guide_dbsetup
On Dec 13, 2006, at 4:21 PM, Matthieu Riou wrote:
Thanks Marc! And what about the datasource? Is there another
equivalent
interface and property to use?
On 12/13/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Matthieu-
If you have a custom TransactionManager, you can tell Kodo to
access
it using a ManagedRuntime implementation (see http://
incubator.apache.org/openjpa/docs/latest/javadoc/org/apache/
openjpa/
ee/ManagedRuntime.html ).
For example, if your TransactionManager is accessible via the JNDI
name comp/env/MyTransactionManager, then you could tell
OpenJPA to
access it by setting the openjpa.ManagedRuntime property to the
value: org.apache.openjpa.ee.JNDIManagedRuntime
(TransactionManagerName=comp/env/MyTransactionManager). For more
exotic mechanisms of accessing the TransactionManager, you can
just
make a custom implementation of the ManagedRuntime class.
In the future, we intent to make this more standard by
utilizing the
new javax.transaction.TransactionSynchronizationRegistry
mechanism,
but for now, we have custom implementations for each of our
known and
supported application servers (see the code at http://
svn.apache.org/
viewvc/incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/
apache/openjpa/ee/AutomaticManagedRuntime.java?
view=markuppathrev=468504 ).
See also: http://incubator.apache.org/openjpa/docs/latest/manual/
manual.html#ref_guide_enterprise_trans
On Dec 13, 2006, at 1:13 PM, Matthieu Riou wrote:
Hi JPA guys,
In the Apache Ode podling we're currently working on replacing
Hibernate
with OpenJPA. It's been working great so far but I have a
couple of
questions. I'd need to set the transaction manager and the
datasource
manually using the OpenJPA API and I've been unable to find the
right class
and the right setters so far. Is there an easy way to do that?
The use case is we need to run both in containers with their
own tx
manager
(like Geronimo) and lightweight containers (like Tomcat). In the
lightweight
case we instantiate our own transaction manager (JOTM) and
our own
datasource (Minerva) and we don't need any JNDI (unnecessary
painful).
I've been looking around and haven't found an easy way. I could
have a look
at the sources but I figured that asking you directly would be
quicker.
Thanks!
Matthieu
Re: Setting a datasource and a transaction manager
Ok I'll try that. Thanks!
On 12/13/06, Patrick Linskey [EMAIL PROTECTED] wrote:
I believe that you can set openjpa.ConnectionDriver property to the
actua DataSource to use, and OpenJPA will use it. Of course, you can
only do this in code, and if you use a Map (not a Properties object).
-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: Wednesday, December 13, 2006 5:07 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Setting a datasource and a transaction manager
But I can't use that. In the same way that I have to provide
the transaction
manager to Kodo, I have to provide this transaction manager to the
datasource as well. To create the datasource we're doing
something like:
MinervaPool minervaPool = new MinervaPool();
minervaPool.setTransactionManager(_txMgr);
minervaPool.getConnectionFactory().setConnectionURL(url);
minervaPool.getConnectionFactory().setUserName(sa);
minervaPool.getConnectionFactory().setDriver(
org.apache.derby.jdbc.EmbeddedDriver.class.getName());
minervaPool.getPoolParams().maxSize =
_odeConfig.getPoolMaxSize();
minervaPool.getPoolParams().minSize =
_odeConfig.getPoolMinSize();
minervaPool.getPoolParams().blocking = false;
minervaPool.setType(MinervaPool.PoolType.MANAGED);
try {
minervaPool.start();
} catch (Exception ex) {
String errmsg = __msgs.msgOdeDbPoolStartupFailed(url);
__log.error(errmsg, ex);
throw new ServletException(errmsg, ex);
}
_datasource = minervaPool.createDataSource();
The most important things are to set the tx mgr and the type
of the pool to
'managed'. So if I use the openjpa.ConnectionDriverName, would Kodo
configure Miverva properly?
Thanks,
Matthieu
On 12/13/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Matthieu-
You can specify the full class name of your DataSource in the
openjpa.ConnectionDriverName property. This too is discussed at
http://incubator.apache.org/openjpa/docs/latest/manual/
manual.html#ref_guide_dbsetup
On Dec 13, 2006, at 4:42 PM, Matthieu Riou wrote:
Sorry to be a pain but the thing is, we don't want to use
any JNDI to
register our datasource. We just create our own so that would mean
creating
a whole JNDI registry just to pass a datasource to Kodo. So my
question was
whether there was the same type of interface I could implement to
return our
custom datasource.
Thanks,
Matthieu
On 12/13/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Matthieu-
If you set the openjpa.ConnectionFactoryName to the JNDI
name of a
DataSource, then Kodo will use that.
See: http://incubator.apache.org/openjpa/docs/latest/manual/
manual.html#ref_guide_dbsetup
On Dec 13, 2006, at 4:21 PM, Matthieu Riou wrote:
Thanks Marc! And what about the datasource? Is there another
equivalent
interface and property to use?
On 12/13/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Matthieu-
If you have a custom TransactionManager, you can tell Kodo to
access
it using a ManagedRuntime implementation (see http://
incubator.apache.org/openjpa/docs/latest/javadoc/org/apache/
openjpa/
ee/ManagedRuntime.html ).
For example, if your TransactionManager is accessible
via the JNDI
name comp/env/MyTransactionManager, then you could tell
OpenJPA to
access it by setting the openjpa.ManagedRuntime
property to the
value: org.apache.openjpa.ee.JNDIManagedRuntime
(TransactionManagerName=comp/env/MyTransactionManager). For more
exotic mechanisms of accessing the TransactionManager, you can
just
make a custom implementation of the ManagedRuntime class.
In the future, we intent to make this more standard by
utilizing the
new javax.transaction.TransactionSynchronizationRegistry
mechanism,
but for now, we have custom implementations for each of our
known and
supported application servers (see the code at http://
svn.apache.org/
viewvc/incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/
apache/openjpa/ee/AutomaticManagedRuntime.java?
view=markuppathrev=468504 ).
See also:
http://incubator.apache.org/openjpa/docs/latest
