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