axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <sam...@wso2.com>
Subject Re: Processing of “parameter” configuration values
Date Mon, 18 Aug 2008 08:19:47 GMT
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


Mime
View raw message