Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
From: Sanjaya Karunasena <sanjayak@wso2.com>
Organization: WSO2
To: axis-dev@ws.apache.org
Subject: Re: [AXIS2] Input Parameter Validation, Error and Exception handling
Date: Thu, 15 Feb 2007 09:06:18 +0530
User-Agent: KMail/1.9.5
Cc: Sanjiva Weerawarana <sanjiva@opensource.lk>
References: <200702131728.07254.sanjayak@wso2.com>
 <4f5c8bd80702140302r3f80b677g8a288e1670fd2550@mail.gmail.com>
 <1171466766.24463.18.camel@localhost.localdomain>
In-Reply-To: <1171466766.24463.18.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200702150906.18631.sanjayak@wso2.com>

I was under the impression there is a code formatting tool which get executed 
as part of the build. Isn't that the case? Since every developer runs a local 
build with the latest from the SVN before committing or submitting a patch, 
the code will be automatically formatted.

Also it will be helpful for newbies, if committers who are using different 
IDEs can export their code formatting settings and have them available to 
download. Then newbies can simply import them to the project they are working 
on.

Sanjaya

On Wednesday 14 February 2007 20:56, Sanjiva Weerawarana wrote:
> Please submit a patch .. along with proper indentation ;-).
>
> Sanjiva.
>
> On Wed, 2007-02-14 at 16:32 +0530, Sameera Madushan wrote:
> > I've also found out some places in axis2 code which can have a
> > negative impact on the performance. For an example consider the
> > following code in the AbstractMessageReceiver class.
> >
> > if (service.getParameter(Constants.SERVICE_OBJECT_SUPPLIER) != null) {
> >                 Parameter serviceObjectParam =
> >                        
> > service.getParameter(Constants.SERVICE_OBJECT_SUPPLIER); Class
> > serviceObjectMaker =
> > Loader.loadClass(classLoader, ((String)
> >                         serviceObjectParam.getValue()).trim());
> > .....
> >
> > This can be refactored as,
> >
> > Parameter serviceObjectParam =
> >                        
> > service.getParameter(Constants.SERVICE_OBJECT_SUPPLIER); if
> > (serviceObjectParam != null) {
> >                       Class serviceObjectMaker =
> > Loader.loadClass(classLoader, ((String)
> >                         serviceObjectParam.getValue()).trim());
> > ..........
> >
> > ASAIK the latter removes the duplicate method invocation. In this
> > instance, invoking "getParameter" method result in searching a
> > HashMap. Duplicating these heavy operations is not a good idea.
> >
> > On 2/14/07, Sanjaya Karunasena <sanjayak@wso2.com> wrote:
> > > Hi David,
> > >
> > > I din't mean to propose some hard constraints or major refactoring
> > > activity. Problems I have noticed are very natural in an open/large
> > > development environment. Having some guidelines, discussions on such
> > > topics will help every one to come to the same page and minimize the
> > > pain in the future (IMO).
> > >
> > > Please find my comments below.
> > >
> > > Regards,
> > > Sanjaya
> > >
> > > Note: BTW, I forgot to put the prefix [AXIS2] in the subject earlier.
> > > Sorry about that.
> > >
> > > On Tuesday 13 February 2007 17:40, David Illsley wrote:
> > > > Hi Sanjaya,
> > > > If you're suggesting a mass change based on a set of rules, I'm not
> > > > enthusiastic (and quite likely to -1 it)... it's quite likely that
> > > > some of the seemingly extraneous checks are there because there have
> > > > been problems in the past.
> > >
> > > Not at all. But when we do defect fixes and other improvements if we
> > > can fix up some of these without having to modify lot of code, is I am
> > > proposing. Last thing you want is some nice looking code with broken
> > > functionality.
> > >
> > > > Please list the methods which you believe are being over-cautious and
> > > > we can address them individually with a little thought.
> > >
> > > I will add the areas I came across as improvements to JIRA and where
> > > possible a patch as well. So that you all can make the call.
> > >
> > > > If you're looking for guidelines for future contributions then I'm
> > > > open to developing them (I'm not aware that they exist now) but don't
> > > > wish to be tightly constrained to them. I tend to write cautious
> > > > code, and unless there's a clear, specific performance problem,
> > > > that's how I'd like to continue.
> > >
> > > I think we are on the same page here.
> > >
> > > > David
> > > >
> > > > On 13/02/07, Sanjaya Karunasena <sanjayak@wso2.com> wrote:
> > > > > Hi All,
> > > > >
> > > > > After going through some of the Axis2 code, I have noticed many
> > > > > instances of duplicate input parameter validations leading to
> > > > > redundant code. This has negative impact on performance as well.
> > > > > Also the error and exception handling policy is not clear, or may
> > > > > be not consistent.
> > > > >
> > > > > What are the typical guidelines followed in the project?
> > > > >
> > > > >
> > > > > Few suggestions on input parameter validation are;
> > > > > * An instance of a class which make use of an input parameter for
> > > > > the first time should validate the parameter
> > > > > * A instance of a interface class (Actor interface) should assume
> > > > > default values for required (mandatory) parameters where possible
> > > > > (Could be due to a flexibility provided in a specification)
> > > > > * If there are optional parameters for an interface, that should be
> > > > > handled through method overloading (not by allowing null inputs)
> > > > > * Any exceptions to this can be discussed and come to some logical
> > > > > agreement based on the specific scenario (80, 20 rule)
> > > > >
> > > > >
> > > > > Thanks
> > > > > Sanjaya
> > > > >
> > > > > -------------------------------------------------------------------
> > > > >-- To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org For
> > > > > additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org