openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Extending the OpenJPA implementation
Date Sat, 19 Aug 2006 05:58:34 GMT
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
View raw message