Re: Improvements to property handling

[Ruwan Linton]

Hi,

Done with the implementation. More changes then expected.......

You can find the patch for this at
https://issues.apache.org/jira/browse/SYNAPSE-25

Thanks,
Ruwan

On 9/26/06, Saminda Abeyruwan <[EMAIL PROTECTED]> wrote:

On 9/26/06, Ruwan Linton < [EMAIL PROTECTED]> wrote:

HI Saminda,

On 9/26/06, Saminda Abeyruwan < [EMAIL PROTECTED]> wrote:

Hi Devs,

Looking at XmlConfigurationBuilder#defineProperty(), IMHO the property handling can be improved as follows,

With the possible combinations  of @name, @value, @src, and @value [or having inline xml only with @name], the property holding map (globleProp) holds different objects. Thus, if someone uses this in a mediator or any specific requirement, one has to see the type (cast according) of the object. This, is IMHO is quite cumbersome.

Yes... Agreed

There also exist another class DynamicPropety, which just hold the info of the registry. IMHO, the above can be merged into one, called PropetyHolder ( good name ??),

How about the name Property rather than PropertyHolder just like Endpoint?

PropertyHolder --> Property . That's fine with me :)

which holds the state depending on the @s combination.

Thus,

public class PropertyHolder {

// Variables to hold @s and type ex: 0 for inline, 1 for @name and @value etc.

private OMElement xmlObject ; // This holds either the inline xml or the xml from (@name && @src)

// variables related to registry.

// setter and getter for varible

public Object getProperty(){ //method gives the right object
}

}

Thus, when a PropetyHolder is set to the SynapseConfiguration with the key as @name, mediator author could get hold to it and get the object depending on the @s combination.

Ok, but in here  mediator auther has to Cast the object returning to a String or to an OMElement depending on the configuration. This is because there can be inline String or String value properties as well as XML fragments as properties. I think we cant gewt hold of this casting (which is obvious),
What do U think?

Ok, there'll be Object class to hold either OMelement or String and let the user cast to the proper one.

Thus, this way the user does not need to know, if the property is dynamic or static.

Please do provide your consensus on prior.

I was looking in to this and I got some good comments in to the improvement of this property holding, I will do this improvement and submit a patch if this is ok..

Cool

Thank you

Saminda 

Thanks,
Ruwan