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 instead).
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.
