> 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.
I agree that this is something that we should work out, and is the reason that I mentioned earlier that we might want a Kodo-specific PersistenceProvider at the end of the day. Seems like it's in everyone's best interests for multiple systems with different OpenJPA derivatives to behave deterministically. -Patrick _______________________________________________________________________ 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.
