You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Kevin Sutter <kw...@gmail.com> on 2007/02/02 23:10:17 UTC

Re: svn commit: r502751 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/simple/ openjpa-persistence/src/main/java/org/apache/openjpa/persiste

I'm okay with the single line convention.  I'm flexible.  I'll change these
two comment blocks if that's the direction we want to go.

On 2/2/07, Patrick Linskey <pl...@bea.com> wrote:
>
> Hi,
>
> To date, almost all of the OpenJPA code uses single-line-style comments
> inside method blocks, instead of multi-line comments. I prefer sticking
> with this convention; my excuse is that it makes it easier to comment
> out blocks of code during debugging, since you can use /*-style comments
> when debugging with impunity if there are no /*-style comments in the
> code. But really, it's probably just personal bias.
>
> Thoughts?
>
> -Patrick
>
> +                /* Check for null here because _brokers is a
> > weak reference
> > +                collection */
> >                  if ((broker != null) && (!broker.isClosed()))
> >                      broker.close();
>
>
>
> > -            if ((_flags & FLAG_FLUSH_REQUIRED) != 0)
> > +            /* If a flush is desired (based on input parm),
> > then check if the
> > +             * "dirty" flag is set before calling flush().
> > +             */
> > +            if ((flush) && ((_flags & FLAG_FLUSH_REQUIRED) != 0))
> >                  flush();
> >              detachAllInternal(call);
>
> > -        catch(IllegalStateException ise) {
> > -            /*
> > -             * An IllegalStateException is expected. Nothing
> > to do here.
> > -             */
> > -        }
>
> _______________________________________________________________________
> 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.
>