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 Tue, 15 Aug 2006 17:03:36 GMT
> As to the details of how the ProductDerivation interface would take  
> over for ConfiguraitonProvider: I was thinking we could move  
> ConfigurationProvider's load() methods into ProductDerivation, but  
> change them to return a ConfigurationProvider, which will now  
> consist of just getProperties(), addProperty(ies)(), setInto().   
> This keeps ProductDerivations stateless and therefore cacheable and  
> threadsafe.  So when looking for configuration, instead of  
> instantiating ConfigurationProviders from services and looping  
> through them to find one that loads, we instead use our loop  
> through our list of ProductDerviations in order from most-specific  
> (highest return value from ProductDerivation.getType()) to least,  
> until one returns a non-null ConfigurationProvider.

As this isn't at all clear, let me sum up.  ProductDerivation gains  
the load() methods from ConfigurationProvider:

interface ProductDerivation {
     ConfigurationProvider loadGlobals(ClassLoader);
     ConfigurationProvider load(String, String, ClassLoader);

And ConfigurationProvider is reduced to the methods dealing with  
adding properties and setting into a Configuration.   
ProductDerivation remains stateless, but becomes a factory for  

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.

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