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 16:37:40 GMT
> This sounds good since I was wondering how these two services fit  
> together.
> Can you shed some more light on how you plan to resolve this?

Well, I haven't thought it through all the way, which is why I  
volunteered to play with the code myself rather than subject someone  
else to my vague ramblings.  But I'll try to describe what I had in  
mind.

First, note that the ConfigurationProvider interface is in lib, and  
is completely general.  It has no notion of specs or persistent  
stores.  The ProductDerivation interface, on the other hand, is in  
kernel, and it does understand specs and stores (not specific ones,  
just that those concepts exist).  So to move ConfigurationProvider  
functionality into ProductDerivation while maintaining the meaning of  
lib vs. kernel, we either have to move the utility methods that  
utilize ConfigurationProviders out of lib and into kernel, or move a  
base ProductDerivation interface without spec and store knowledge  
from kernel into lib.  In the latter case, kernel would then derive  
an OpenJPAProductDerivation interface to add back spec and store  
knowledge.  Granted, OpenJPA (and its extensions) is the only product  
that builds on lib, so having a distinct, non-persistence-aware lib  
is of questionable value now, but while it exists I intend to  
maintain its meaning.  Plus, Kodo does have some internal services  
that use lib without being persistence-specific (and for that reason,  
it'd be nice to use the latter approach in which ProductDerivation is  
generalized for use in lib, rather than the former where some current  
functionality is moved from lib into kernel, though I'm sure we could  
live with either).

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.

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.
_______________________________________________________________________
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
View raw message