openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: Extending the OpenJPA implementation
Date Mon, 21 Aug 2006 13:33:58 GMT
Hi,
I've created JIRA OPENJPA-24 report for tracking this problem (
http://issues.apache.org/jira/browse/OPENJPA-24).  Any discussion related to
the problem of extending the OpenJPA implementation should be directed to
OPENJPA-24.  Thanks.

Kevin

On 8/19/06, Craig L Russell <Craig.Russell@sun.com> wrote:
>
> Hi Kevin,
>
> I think it's great that you can contribute here. I'd definitely
> suggest filing a JIRA with as much detail as you know about
> describing your work, and assigning it to yourself (now that you have
> god-like JIRA powers).
>
> And discussions on the details of ProductDerivation and
> ConfigurationProvider can be tied directly to the JIRA along with any
> patches-in-progress so it's easy to track.
>
> Craig
>
> On Aug 18, 2006, at 9:06 AM, Kevin Sutter wrote:
>
> > 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
> > education...
> >
> >   - 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.
> >
> > Kevin
> >
> > On 8/16/06, Kevin Sutter <kwsutter@gmail.com> wrote:
> >>
> >>
> >>
> >> On 8/16/06, Abe White <awhite@bea.com> 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
> >>
> >>
> >>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
>

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