openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abe White <awh...@bea.com>
Subject Re: Extending the OpenJPA implementation
Date Tue, 15 Aug 2006 17:35:45 GMT
> 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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message