Hi Pinaki, Thanks for your comments. We will add JavaDoc to newly introduced protected methods. We don't need the patch to ProductDerivations, so there will be no change to ProductDerivations. A new patch will be attached to OPENJPA-477 as soon as we have the JavaDoc added.
Catalina On Jan 21, 2008 12:52 PM, Pinaki Poddar <[EMAIL PROTECTED]> wrote: > Hi, > 1. the new changes are more compact. > 2. newly introduced protected methods will benefit from some JavaDoc > documentaion as their primary purpose is someone extending them. > 3. The motivation for changes in configuration/Product derivations is > not obvious. What is the plug-in point for this SQLJ extension in the > object management layer: at EMF or at BrokerFactory? > > -----Original Message----- > From: catalina wei [mailto:[EMAIL PROTECTED] > Sent: Monday, January 21, 2008 2:29 PM > To: [email protected] > Subject: Re: [jira] Commented: (OPENJPA-477) making StoreManager more > flexible and extensible. > > Hi Pinaki, > You must be looking at the older patch, could you please take a look at > the latest attached patch: OPENJPA-477-trunk612523.patch > > This patch should not have any "private" field to protected field > changes. > > Thanks > > Catalina > > On Jan 21, 2008 12:08 PM, Pinaki Poddar (JIRA) <[EMAIL PROTECTED]> wrote: > > > > > [ > > https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.j > > ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=125 > > 61111#action_12561111] > > > > Pinaki Poddar commented on OPENJPA-477: > > --------------------------------------- > > > > 1. Some changes are making a private instance variables protected. A > > better pattern will be to retain the variables as private and add > > corresponding getter. That way the base class can exert more control > > in the getter (for example, providing an unmodifiable copy in some > > cases) especially when changing the the instance variable below the > > hood can have adverse impact on the base class. > > > > 2. Some changes are redundant. For example, in JDBCStoreManager > > > > - private void connect(boolean ref) { > > + protected void connect(boolean ref) { > > > > This class already provides for such extension. See the following the > > > same class > > /** > > * Connect to the database. This method is separated out so that it > > * can be overridden. > > */ > > protected RefCountConnection connectInternal() throws SQLException > { > > return new RefCountConnection(_ds.getConnection()); > > } > > > > or this one in TableJDBCSeq > > - private transient JDBCConfiguration _conf = null; > > + protected transient JDBCConfiguration _conf = null; > > > > when this class already has > > public JDBCConfiguration getConfiguration() { > > return _conf; > > } > > > > > > > > > > > making StoreManager more flexible and extensible. > > > ------------------------------------------------- > > > > > > Key: OPENJPA-477 > > > URL: > https://issues.apache.org/jira/browse/OPENJPA-477 > > > Project: OpenJPA > > > Issue Type: Improvement > > > Components: kernel > > > Affects Versions: 1.0.2 > > > Reporter: Daniel Lee > > > Fix For: 1.0.2, 1.1.0 > > > > > > Attachments: OPENJPA-477-trunk612523.patch, > > > OPENJPA-477.patch > > > > > > > > > The OpenJPA StoreManager needs some modifications to make it more > > flexible and extensible. For example, some private methods and > > attributes need to made either public or protected. The attached > > patch identifies the areas that have been identified thus far. Please > > > let me know if there are any concerns. Many thanks in advance. > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual or > entity named in this message. If you are not the intended recipient, and > have received this message in error, please immediately return this by email > and then delete it. >
