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.


On 8/19/06, Craig L Russell <[EMAIL PROTECTED]> 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.


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 <[EMAIL PROTECTED]> wrote:
>> On 8/16/06, Abe White <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Reply via email to