Hi Nadeeshan,
On Tue, Jun 14, 2016 at 12:38 AM, Nadeeshaan Gunasinghe <[email protected] > wrote: > 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* > *"/> * > > IMO this is not an elegant solution. Intension of introducing context variables is to make things simpler, which is not address in this solution. I think we should try do a better implementation. Thanks. > > - > > - 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 > <#m_6820348976097291375_> > <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_6820348976097291375_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/ >> > > -- *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
