openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abe White <>
Subject Re: Extending the OpenJPA implementation
Date Mon, 14 Aug 2006 22:14:31 GMT
> ConfigurationProviders don't know anything about PersistenceProviders,
> of course, and need to be constructible via a no-args constructor. But
> maybe the PersistenceProviderImpl could populate the
> ConfigurationProvdierImpl with information about which subclass of
> PersistenceProviderImpl it should succeed for.

That's not going to work with cmd-line tools, for which we use  
ConfigurationProviders to load configuration without going through  
the PersistenceProvider (obviously, as the tools aren't aware of JPA  
specifics).  It also wouldn't work at runtime if the user uses  
OpenJPA-native APIs to get a BrokerFactory, then uses the static  
OpenJPAPersistence.toEntityManagerFactory(BrokerFactory) helper.   
Same with the other OpenJPAPersistence.toXXX methods.  Though I  
imagine the OpenJPAPersistence methods aren't that big a concern (you  
can always have a MyProductPersistence helper your users can use  

We're also going to have to solve this problem for Kodo if we want to  
extend the OpenJPA EMF to implement the backwards-compatible  
KodoEntityManagerFactory, KodoEntityManager, etc interfaces for  
users.  Right now it's easy to use ProductDerivations to add new  
behind-the-scenes features, but extending the APIs is another matter.
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

View raw message