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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
