That sounds like the right way to do it. So my container would, on startup, instantiate OpenJPA's PersistenceProviderImpl, and invoke createContainerEntityManagerFactory() with a PersistenceUnitInfo that I implement?
Yes. Note that OpenJPA already has an PUInfo implementation that you might want to take advantage of.
I can see that this gives me a great deal of control over classloading, transactions, etc. But it looks like I still need to supply all managed class names up front, and must refer to mapping information as file references?
Not necessarily -- OpenJPA supports dynamically discovering new classes as they are loaded, so you could certainly take advantage of that. Some things cannot be done until after OpenJPA has loaded a class. For example, you cannot use a class's alais in a JPQL query until after the class has been bootstrapped, and any named queries defined on the class will not be visible until the class has been loaded. I can't remember exactly how things work; it's possible that if you list classes, then OpenJPA assumes that that is a complete list and doesn't support lazy discovery of classes.
I am hoping for a way to enhance and register classes as appropriate at ordinary classloading time, or if that isn't possible at least discover the classes dynamically at deployment time. Generally I'm trying to avoid using persistence.xml.
Why? Are you trying to reduce it's complexity, or just eliminate it altogether? How do you propose having your users configure things like OpenJPA logging or tuning options? If you're planning on re-introducing a significant percentage of these things, then you might want to consider just using persistence.xml, but limiting which parts can be used.
Likewise the mapping information should only come from annotations on the managed classes, but ideally through "me" such that certain things can be changed on the fly (such as field value and type conversion etc.)
What degree of control do you want? Control over defaults etc., or the ability to override what the user specified? You can get a pretty complete amount of control by implementing a MappingFactory; presumably your implementation would delegate to the normal mapping factory. -Patrick On 5/16/07, Dennis Thrysøe <[EMAIL PROTECTED]> wrote:
Patrick Linskey wrote: > This means that your container would be responsible for EntityManager > lifecycle and potentially for transaction control. It also means that > you'd interact with OpenJPA via the > PersistenceProvider.createContainerEntityManagerFactory() API. In such > a scenario, you (the container) would be responsible for providing a > PersistenceUnitInfo (you might want to take advantage of OpenJPA's > existing XML-processing support to help out with this). That sounds like the right way to do it. So my container would, on startup, instantiate OpenJPA's PersistenceProviderImpl, and invoke createContainerEntityManagerFactory() with a PersistenceUnitInfo that I implement? I can see that this gives me a great deal of control over classloading, transactions, etc. But it looks like I still need to supply all managed class names up front, and must refer to mapping information as file references? I am hoping for a way to enhance and register classes as appropriate at ordinary classloading time, or if that isn't possible at least discover the classes dynamically at deployment time. Generally I'm trying to avoid using persistence.xml. Likewise the mapping information should only come from annotations on the managed classes, but ideally through "me" such that certain things can be changed on the fly (such as field value and type conversion etc.) Is this possible? Perhaps by providing certain properties in the map when obtaining an EntityManagerFactory? Or am I being too creative here? -dennis --------------------------------------------------------------------------- The information in this email is confidential and may be legally protected.
-- Patrick Linskey 202 669 5907
