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 Fri, 18 Aug 2006 19:15:11 GMT
>   - You mention in several places about separating away the notion of
>   specs and stores.  In a general sense, I understand what these  
> are.  But,
>   can you elaborate on how these types are used in the  
> ConfigurationProvider
>   and ProductDerivation interfaces?

What I meant was that the ProductDerivation interface has methods and  
constants that imply knowledge of what a "spec" is and what a "store"  
is: afterSepcificationSet(), TYPE_STORE, etc.  These methods and  
constants become meaningless when the interface is moved from kernel  
to lib, because lib is code that is completely ignorant of what's  
built on top of it.  OpenJPA kernel understands that there might be  
different spec facades built on it, and that there might be different  
data stores plugged in, but lib code shouldn't be aware of those  

Actually, I wouldn't mind moving the  
OpenJPAConfiguration.setSpecification() method to the base  
Configuration interface and giving lib the notion of a spec, because  
that's a sufficiently general idea.  But lib certainly shouldn't know  
anything about data stores -- that concept is very persistence- 
specific.  So I believe that at the very least, the TYPE_STORE stuff  
has to be moved out of ProductDerivation and into something in the  
kernel if ProductDerivation itself moves into lib.  As I mentioned in  
my original email, it might seem odd to maintain the strict  
neutrality of lib code given that it's only used for OpenJPA, but we  
do in fact build on that code with some non-persistence-aware Kodo  
stuff, and as long as there is a separation of modules within  
OpenJPA, I'd like to maintain the meaning of lib-as-neutral vs.  

> Now that we need to return a ConfigurationProvider, would you
>   expect that we just new up a ConfigurationProviderImpl and then  
> just call
>   across to the "load" methods on the implementation?  Since we  
> want to keep
>   the ProductDerivations stateless, I'm not sure how else you were  
> expecting
>   to create a ConfigurationProvider to return on these "load" methods.

I would expect the ProductDerivation itself to do most of the load  
work and to populate a new ConfigurationProvider with the parsed  
state.  The ProductDerivation itself would remain stateless, but  
would contain the load logic.  We can probably have just one  
ConfigurationProviderImpl that will work for most derivations (i.e.  
ConfigurationProviderImpl will probably not have to be JPA-specific  
anymore, and can move into lib's conf package or somewhere where it  
can be used by JDO, etc as well).  I bet a slight rework of  
MapConfigurationProvider would do the trick.

>   - Now that ConfigurationProvider is bare, the
>   ConfigurationTestConfigurationProvider doesn't have much  
> function.  I'll
>   need to take a look to see if this is even required any longer.

Yeah, I'm sure tests will need updating.

>   - Can you shed a bit more light on the Configurations class?  It
>   doesn't implement nor extend any interfaces or classes, but it  
> seems to
>   provide many of the same methods as ConfigurationProvider, but as  
> statics.
>   And, it's dependent on having a Provider.  Can you explain the  
> relationship
>   of this class in the bigger picture and how you think it might be  
> affected
>   by thes changes?

It's a utility class.  Aside from the low-level utils it provides,  
it's mainly there so that its static configuration methods can be  
invoked without worrying about what services the system is configured  
with.  Configurations does the work of looking up the right  
ConfigurationProvider using the services framework and applying it.   
Otherwise, each component that used a ConfigurationProvider would  
have to invoke the Services utilities itself to figure out which  
ConfigurationProvider to use.

When ProductDerivation takes over, Configurations will change to use  
ProductDerivations instead, and will subsume the functionality of  
kernel's conf.ProductDerivations utility class.
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.

View raw message