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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]<mailto: >> [EMAIL PROTECTED]>> 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: [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> >> >> >> >> -- >> >> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Software Engineer, WSO2 Inc
