openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <>
Subject Re: Extending the OpenJPA implementation
Date Fri, 18 Aug 2006 16:06:38 GMT
Hi Abe,
I've started to look at doing these changes (I should probably open a JIRA
bug for tracking this work), but it looks like I need a bit more

   - 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?

    - I've moved the ProductDerivation interface to the lib and added the
   "load" methods from the ConfigurationProvider (as described in your previous
   notes).  And, I've started to clean up the implementations that depend on
   these interfaces.  But, concerning the implementation of the load
   methods...  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.

    - 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.

    - 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?

That's it to be begin with.  Thanks for any pointers you can provide.


On 8/16/06, Kevin Sutter <> wrote:
> On 8/16/06, Abe White <> wrote:
> >
> >
> > I'm not currently working on those changes.  If no one else
> > implements them I'll end up doing so at some point, but the reason I
> > wrote those emails describing what I had in mind was to encourage
> > some other motivated dev (like one who wants to extend the framework
> > now... hint hint) to maybe take a crack at it.
> I guess you weren't blunt enough in your previous appends...  ;-)  I'll
> have to see if I can motivate this person or not...
> Kevin

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