Hi all,
After analyzing the possibility of adding the synapse variable for the
registry scope I could come up with a feasible solution.
- Here, one of the key concern was to preserve the backward
compatibility and the consistency with the current synapse variable
implementation. First solution was the following, adhering to the existing
synapse variable related configurations.
* <property name="registry_value" expression="$reg:conf:Resource/bar@hello"
/> *
- When we try to include this configuration, it throws a jaxen exception
since this is invalid xpath expression.
*class org.jaxen.saxpath.XPathSyntaxException:
$reg:conf:Resource/bar@hello: 9: Unexpected ':' *
- Since we need to include a registry path in the xpath expression we
have to go for a configuration option slightly drifted away from the
current synapse variable related configuration. By following the bellow
configuration we can achieve the expected outcome successfully. As the
first step we need to have a property to keep the registry path as,
* <property name="registry_path" value="conf:Resource/bar@hello"/> *
- Then the registry scope synapse variable configuration is as follows,
*<property name="registry_value" expression="$reg:**registry_path*
*"/> *
- In this case, instead of providing the full registry path in the
synapse expression we use the property name, where we set with the registry
path.
- Adhering to the above configuration, in the implementation we get the
corresponding property name as the *localName *and we can get the
respective registry path as bellow.
else if (SynapseXPathConstants.REGISTRY_VARIABLE_PREFIX.equals(prefix)) {
*String key = (String)synCtx.getProperty(localName);*
String[] regParam = key.split("@");
String regPath = null;
String propName = null;
- As highlighted I'm getting the registry path for processing, through
the synapse context using the property name.
This is the current solution for the new registry scope as a synapse
variable and can we consider this as the viable solution for the registry
scope, because of this is a special case where we consider a registry path?
WDYT?
Thanks,
*Nadeeshaan Gunasinghe*
Software Engineer, WSO2 Inc. http://wso2.com
+94770596754 | [email protected] | Skype: nadeeshaan.gunasinghe <#>
<http://www.facebook.com/nadeeshaan.gunasinghe>
<http://lk.linkedin.com/in/nadeeshaan> <http://twitter.com/Nadeeshaan>
<http://nadeeshaan.blogspot.com/>
Get a signature like this: Click here!
<http://ws-promos.appspot.com/r?rdata=eyJydXJsIjogImh0dHA6Ly93d3cud2lzZXN0YW1wLmNvbS9lbWFpbC1pbnN0YWxsP3dzX25jaWQ9NjcyMjk0MDA4JnV0bV9zb3VyY2U9ZXh0ZW5zaW9uJnV0bV9tZWRpdW09ZW1haWwmdXRtX2NhbXBhaWduPXByb21vXzU3MzI1Njg1NDg3Njk3OTIiLCAiZSI6ICI1NzMyNTY4NTQ4NzY5NzkyIn0=&u=602853038872535>
On Wed, Jun 1, 2016 at 8:05 PM, Isuru Udana <[email protected]> wrote:
> Hi Kasun,
>
> We also need to add system scope.
>
> Are we talking about removing get-property function or just implement what
> ever we can do with get-property() to do with context variables and
> recommending to use variables. I believe we are doing the latter.
> Completely removing it is not an option due to migration issues, need to do
> massive changes in samples, articles, blogs, documentation.
>
> And also regarding the unnecessary registry access, I think we should
> check again whether we can fix it. I will check the possibility doing that.
>
> Thanks.
>
> On Thu, Jun 2, 2016 at 5:27 AM, Nadeeshaan Gunasinghe <[email protected]
> > wrote:
>
>> Hi Kasun,
>>
>> Will go through the aforementioned fact.
>>
>> Thanks,
>>
>> *Nadeeshaan Gunasinghe*
>> Software Engineer, WSO2 Inc. http://wso2.com
>> +94770596754 | [email protected] | Skype: nadeeshaan.gunasinghe
>> <#m_4205543007657424697_m_-6918896767413548059_>
>> <http://www.facebook.com/nadeeshaan.gunasinghe>
>> <http://lk.linkedin.com/in/nadeeshaan> <http://twitter.com/Nadeeshaan>
>> <http://nadeeshaan.blogspot.com/>
>> Get a signature like this: Click here!
>> <http://ws-promos.appspot.com/r?rdata=eyJydXJsIjogImh0dHA6Ly93d3cud2lzZXN0YW1wLmNvbS9lbWFpbC1pbnN0YWxsP3dzX25jaWQ9NjcyMjk0MDA4JnV0bV9zb3VyY2U9ZXh0ZW5zaW9uJnV0bV9tZWRpdW09ZW1haWwmdXRtX2NhbXBhaWduPXByb21vXzU3MzI1Njg1NDg3Njk3OTIiLCAiZSI6ICI1NzMyNTY4NTQ4NzY5NzkyIn0=&u=789400881267119>
>>
>> On Wed, Jun 1, 2016 at 3:08 PM, Kasun Indrasiri <[email protected]> wrote:
>>
>>> We need to add this to ESB 5. (We just came across another perf issue
>>> due to the redundant use of get-property)
>>>
>>> @Nadeeshan : Can you please check the limitations on adding this to
>>> other scopes such as operations/registry?
>>>
>>> On Wed, Jun 17, 2015 at 7:49 PM, Chanaka Fernando <[email protected]>
>>> wrote:
>>>
>>>> Also some customers use the "operation" scope to store and retrieve
>>>> values within the mediation flow. Better if we can add "$operation" also.
>>>>
>>>> On Thu, Jun 18, 2015 at 1:44 AM, Isabelle Mauny <[email protected]>
>>>> wrote:
>>>>
>>>>> Totally +1 to that suggestion.. backward compatibility is key ..
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------------------
>>>>> *Isabelle Mauny*
>>>>> VP, Product Management - WSO2, Inc. - http://wso2.com/
>>>>>
>>>>>
>>>>> On Wed, Jun 17, 2015 at 3:17 PM, Colin Roy-Ehri <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> +1
>>>>>> It would be great to simplify the options available for property
>>>>>> lookup. I think this would increase the usability of our product. I am
>>>>>> also concerned about customers migrating their existing xml code.
>>>>>>
>>>>>> In order to gain performance by moving away from get-property, would
>>>>>> customers need to revise all their use of these mediators? I support
>>>>>> deprecating the get-property from the UI wizard and Dev Studio, but it
>>>>>> would also be great to revise the get-property implementation for future
>>>>>> versions. In other words, would it be possible to change the
>>>>>> get-property
>>>>>> implementation so that proxies, APIs and sequences could be migrated
>>>>>> forward without change, and still use the more efficient scoped-style
>>>>>> efficient implementation? This would prevent the registry performance
>>>>>> hit,
>>>>>> and prevent the necessity for customers to modify all their xml code.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Colin Roy-Ehri
>>>>>> Software Engineer
>>>>>> *WSO2, Inc. : wso2.com <http://wso2.com/>*
>>>>>> *Mobile* : 812-219-6517
>>>>>>
>>>>>> On Wed, Jun 17, 2015 at 2:41 AM, Kasun Indrasiri <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It seems we can get rid of the usage of get-property and stick to
>>>>>>> the usage of scope variable declarations only (the current impl of
>>>>>>> get-property function always triggers a call to ESB registry interface,
>>>>>>> which can be a performance hit).
>>>>>>>
>>>>>>> For example we can use:
>>>>>>>
>>>>>>> $ctx, $trp etc to get required property values from the context.
>>>>>>> @Nadeeshan : we need to include $registry: as well.
>>>>>>>
>>>>>>> Any other use cases that we need to cover?
>>>>>>>
>>>>>>> --
>>>>>>> Kasun Indrasiri
>>>>>>> Software Architect
>>>>>>> WSO2, Inc.; http://wso2.com
>>>>>>> lean.enterprise.middleware
>>>>>>>
>>>>>>> cell: +94 77 556 5206
>>>>>>> Blog : http://kasunpanorama.blogspot.com/
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> [email protected]
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> [email protected]
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> [email protected]
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Chanaka Fernando
>>>> Senior Technical Lead
>>>> WSO2, Inc.; http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> mobile: +94 773337238
>>>> Blog : http://soatutorials.blogspot.com
>>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>>>> Twitter:https://twitter.com/chanakaudaya
>>>> Wordpress:http://chanakaudaya.wordpress.com
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Kasun Indrasiri
>>> Software Architect
>>> WSO2, Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> cell: +94 77 556 5206
>>> Blog : http://kasunpanorama.blogspot.com/
>>>
>>
>>
>
>
> --
> *Isuru Udana*
> Technical Lead
> WSO2 Inc.; http://wso2.com
> email: [email protected] cell: +94 77 3791887
> blog: http://mytecheye.blogspot.com/
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
