So that's basically it for combining ConfigurationProviders and ProductDerivations into a single service. In a followup email I'll address how we can give ProductDerivations the ability to extend the EMF, etc.
Adding the ability to extend EMFs though a ProductDerivation is actually easy. Only the OpenJPAPersistence.toEntityManagerFactory helper creates EMFs. So all we need to do is use our PersistenceProductDerivation to add a lib.conf.PluginValue (or maybe a custom Value if you want to continue to pass the delegate BrokerFactory into the EMF's constructor rather than create a setter for it) to the Configuration in beforeConfigurationLoad. This Value determines what class of EMF to create. The default will be our EntityManagerFactoryImpl, but a later ProductDerivation for a specific extended product could change the default to some extended type. Then we modify OpenJPAPersistence.toEMF to use this Value to instantiate the right EMF type. While we're at it, we change OpenJPAPersistence.toEM to create the EM through the EMF so that the EMF can generate its own EM subclass, rather than constructing an EM directly as it does now.
Given the ability to specify a custom EMF type above, I doubt you'd need to create a custom PersistenceProviderImpl +ConfgurationProviderImpl pair. However, if you wanted to do this, you could. The PersistenceProviderImpl extension is obviously easy, as the persistence.xml file specifies it. But recall that that wouldn't cover cases where the user invokes a cmd-line tool and we still have to load specialized configuration. According to my last email, though, we'll now loop over the ProductDerivations when loading conf from most to least derived (based on the derivations getType() return value). So the ProductDerivation for your extended product will be invoked before the standard PersistenceProductDerivation when looking for conf, and you can therefore return your own ConfigurationProvider type (or do as Patrick mentioned and modify the standard one to accept the expected provider class as a parameter).
There's one last problem, and that is systems with multiple OpenJPA extended products available. If you've got Kodo and ExtendedOpenJPAProductX in your classpath, chances are they'll attempt to overwrite each other's configuration defaults and so forth. That's the case now, and what I've proposed thus far does nothing to alleviate it. I think we could probably figure something out where the extended product looks for its own PersistenceProvider type in persistence.xml when attempting to load() conf, (this is a good reason to extend PersistenceProviderImpl even when not necessary), and the resulting ConfigurationProvider somehow records this info in the Configuration such that other product extensions can check to see if they're compatible with whatever originally loaded the Configuration in their beforeConfigurationLoad, etc callbacks. I don't think this is critical right now and I obviously haven't worked out any details, but it might be something we'll want to tackle eventually.
- _______________________________________________________________________ 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.
