Return-Path: Delivered-To: apmail-ws-axis-c-dev-archive@www.apache.org Received: (qmail 74394 invoked from network); 18 Aug 2008 12:46:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Aug 2008 12:46:22 -0000 Received: (qmail 69143 invoked by uid 500); 18 Aug 2008 12:46:21 -0000 Delivered-To: apmail-ws-axis-c-dev-archive@ws.apache.org Received: (qmail 68959 invoked by uid 500); 18 Aug 2008 12:46:21 -0000 Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: "Apache AXIS C Developers List" Reply-To: "Apache AXIS C Developers List" Delivered-To: mailing list axis-c-dev@ws.apache.org Received: (qmail 68948 invoked by uid 99); 18 Aug 2008 12:46:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Aug 2008 05:46:21 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of supun06@gmail.com designates 209.85.198.243 as permitted sender) Received: from [209.85.198.243] (HELO rv-out-0708.google.com) (209.85.198.243) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Aug 2008 12:45:21 +0000 Received: by rv-out-0708.google.com with SMTP id c5so1648914rvf.28 for ; Mon, 18 Aug 2008 05:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=6pjpaq91tcsVhxeQUsWLB55jOb238/f+h1SQ8wAvp0E=; b=RJnj3D7qXtkvys7tMLoGl0Kn/hhrvNeys/yHCX3xlOldU+4X+mTb3zB8jEKnitMGto wkq/vHjqpXxBmStHLbjuiMddxrNw/aSi2yZhzpyaxAMhFv6RJUIMnWKqUt/kWhKdNNSA uhhn00v+xC+SAHepqTWVptATysyWG1u9AEc30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=CQd+nL9NWve9q11BYI26PAzE9e5FsD6F0CxMRH7E+zIz/EH2dVGJ/FFCBw8NK8c0ja EFCUWqZvLzp9qil5vsTsaGpg/LDZrYgUi7UpNRC3xJNec4b3yCPjZZ2As/CpfI2K4YND y6jIrpiVzsYPekpAFpVQNKR6vVMKHWx1ZTia4= Received: by 10.140.171.18 with SMTP id t18mr3163624rve.249.1219063540804; Mon, 18 Aug 2008 05:45:40 -0700 (PDT) Received: by 10.140.163.17 with HTTP; Mon, 18 Aug 2008 05:45:40 -0700 (PDT) Message-ID: Date: Mon, 18 Aug 2008 17:45:40 +0500 From: "Supun Kamburugamuva" To: "Apache AXIS C Developers List" Subject: =?WINDOWS-1252?Q?Re:_Processing_of_=93parameter=94_configuration_values?= In-Reply-To: <48A930A3.9080406@wso2.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_120521_4825587.1219063540813" References: <48A8F961.2090407@wso2.com> <48A930A3.9080406@wso2.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_120521_4825587.1219063540813 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This will break the backward compatibility if some module is using the xml elements for specifying parameter values. But AFAIK there aren't any. Supun.. On Mon, Aug 18, 2008 at 1:19 PM, Samisa Abeysinghe wrote: > Supun Kamburugamuva wrote: > >> If the parameter value is specified as a text value the current behavior >> won't be changed. AFAIK all the modules specify their parameter >> configurations as text values. >> > > So it is backward compatible. > > Samisa... > > >> Supun. >> >> >> On Mon, Aug 18, 2008 at 9:24 AM, Samisa Abeysinghe > samisa@wso2.com>> wrote: >> >> Supun Kamburugamuva wrote: >> >> Hi all, >> >> As we all know, with Axis2/C we can specify a configuration >> value as a parameter i.e. in services.xml. >> >> echo >> >> These are usefull for specifying custom configuraions i.e >> module configurations. >> >> When we specify a xml element as the parameter value the >> behaviour is little bit confusing. I'm reffering to the code >> in desc_builder.c: 611-641. From the code it seems that it >> tries to create a new parameter for every child xml element >> recursively. Then it store these new parameters in an array >> list of the original parameter. Ultimately it tries to capture >> the xml configuration in a tree like structure. In this tree >> structure we have axutil_param_t to represent nodes instead of >> axiom_node_t. > locked="xsd:false">> myattribute:"value">10 >> >> For the above configuration we will have a parameter named >> ServiceClass and in its internal arraylist we will have >> another parameter with the name myconfig. The problem with >> this approach is that it cannot capture the entire XML >> configuration. i.e xml namespaces. >> >> AFAIK the most logical thing would be to store the element as >> an axiom node in the configuration and return it when >> requested. It is up to the entity which defines the parameter >> to process the axiom node and retrieve values from it. This >> approach is much cleaner and gives the maximum control. AFAIK >> Java implementation works in this way. So how about changing >> the processing to store the axiom node? >> >> >> If this is done, what will happen to current way of processing >> parameters, specially those done in modules such as addressing, >> Rampart and Sandesha? >> >> Samisa... >> >> >> Thanks, >> Supun.. >> >> Software Engineer, WSO2 Inc >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus >> Database: 270.6.4/1615 - Release Date: 8/16/2008 7:11 AM >> >> >> >> -- Samisa Abeysinghe Director, Engineering; WSO2 Inc. >> >> http://www.wso2.com/ - "The Open Source SOA Company" >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org >> >> For additional commands, e-mail: axis-c-dev-help@ws.apache.org >> >> >> >> >> >> -- >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: >> 270.6.4/1615 - Release Date: 8/16/2008 7:11 AM >> >> > > > -- > Samisa Abeysinghe Director, Engineering; WSO2 Inc. > > http://www.wso2.com/ - "The Open Source SOA Company" > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org > For additional commands, e-mail: axis-c-dev-help@ws.apache.org > > -- Software Engineer, WSO2 Inc ------=_Part_120521_4825587.1219063540813 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
This will break the backward compatibility if some module is using the xml elements for specifying parameter values. But AFAIK there aren't any.

Supun..

On Mon, Aug 18, 2008 at 1:19 PM, Samisa Abeysinghe <samisa@wso2.com> wrote:
Supun Kamburugamuva wrote:
If the parameter value is specified as a text value the current behavior won't be changed. AFAIK all the modules specify their parameter configurations as text values.

So it is backward compatible.

Samisa...


Supun.    


On Mon, Aug 18, 2008 at 9:24 AM, Samisa Abeysinghe <samisa@wso2.com <mailto:samisa@wso2.com>> wrote:

   Supun Kamburugamuva wrote:

       Hi all,

       As we all know, with Axis2/C we can specify a configuration
       value as a parameter i.e. in services.xml.

       <parameter name="ServiceClass" locked="xsd:false">echo</parameter>

       These are usefull for specifying custom configuraions i.e
       module configurations.

       When we specify a xml element as the parameter value the
       behaviour is little bit confusing.  I'm reffering  to the code
       in desc_builder.c: 611-641. From the code it seems that it
       tries to create a new parameter for every child xml element
       recursively. Then it store these new parameters in an array
       list of the original parameter. Ultimately it tries to capture
       the xml configuration in a tree like structure. In this tree
       structure we have axutil_param_t to represent nodes instead of
       axiom_node_t.          <parameter name="ServiceClass" locked="xsd:false"><myconfig
       myattribute:"value">10</myconfig ></parameter>

       For the above configuration we will have a parameter named
       ServiceClass and in its internal arraylist we will have
       another parameter with the name myconfig. The problem with
       this approach is that it cannot capture the entire XML
       configuration. i.e xml namespaces.

       AFAIK the most logical thing would be to store the element as
       an axiom node in the configuration and return it when
       requested. It is up to the entity which defines the parameter
       to process the axiom node and retrieve values from it. This
       approach is much cleaner and gives the maximum control. AFAIK
       Java implementation works in this way. So how about changing
       the processing to store the axiom node?


   If this is done, what will happen to current way of processing
   parameters, specially those done in modules such as addressing,
   Rampart and Sandesha?

   Samisa...


       Thanks,
       Supun..

       Software Engineer, WSO2 Inc

       No virus found in this incoming message.
       Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus
       Database: 270.6.4/1615 - Release Date: 8/16/2008 7:11 AM
       


   --    Samisa Abeysinghe Director, Engineering; WSO2 Inc.

   http://www.wso2.com/ - "The Open Source SOA Company"


   ---------------------------------------------------------------------
   To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
   <mailto:axis-c-dev-unsubscribe@ws.apache.org>

   For additional commands, e-mail: axis-c-dev-help@ws.apache.org
   <mailto:axis-c-dev-help@ws.apache.org>




--

No virus found in this incoming message.
Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.4/1615 - Release Date: 8/16/2008 7:11 AM
 


--
Samisa Abeysinghe Director, Engineering; WSO2 Inc.

http://www.wso2.com/ - "The Open Source SOA Company"


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




--
Software Engineer, WSO2 Inc
------=_Part_120521_4825587.1219063540813--