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.

Reply via email to