On Thu, Feb 18, 2010 at 8:35 PM, Ruwan Linton <[email protected]> wrote:
> +1 > > I think we shouldn't let users store sequences, endpoints and stuff into > the local, It seems most are in favor of not allowing the user to store stuff into the local repo. In that case we can leave it out of the picture. As Senaka also mentioned we can resolve paths like '/foo/bar' to the config registry. > even giving the option to store sequences, endpoints into the > config registry is not useful, because we are anyway saving stuff into > the config registry, but having this enabled for config registry has > only one use case where the user want to store stuff in his/her own > desired location rather than storing them on the synapse repository. > Yes. And we do allow users to save sequences and endpoints to a location of user's choice with the 'Save As' feature in the UI. That's how most users create dynamic entries. So we definitely need to support this for the config registry. Thanks, Hiranya > > Thanks, > Ruwan > > Senaka Fernando wrote: > > > > > > On Thu, Feb 18, 2010 at 5:31 PM, Hiranya Jayathilaka <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Folks, > > > > With registry separation work shaping up we need to rethink how we > > are going to handle dynamic sequences and endpoints in the ESB. > > Earlier users were able to save sequences and endpoints anywhere > > in the registry and refer to them using keys as shown below. > > > > <endpoint key="/foo/bar/endpoint"/> > > <sequence key="/foo/bar/sequence"/> > > > > The WSO2Registry adapter class in the mediation registry component > > mapped the above dynamic entires to resources stored in the > > registry. With Carbon now having three separate registries, things > > become more complicated. We definitely need to rewrite the > > WSO2Registry adapter to be aware of the three registries. Right > > now it's using the System registry (which is deprecated) and we > > should always specify absolute paths in the Synapse config as > follows. > > > > <endpoint key="/_system/config/foo/bar/endpoint"/> > > > > IMO users should be able to store dynamic entries in any of the > > registries depending on the situation. For instance if the > > endpoint/sequence is a simple static one it can be stored in the > > config registry. In situations where such entries need to be > > governed it should go in the governance registry. WSO2Registry > > adapter should be able to load resources from any of the > > registries. The sequence and endpoint UI should be updated to > > reflect these changes as well. Currently they only show dynamic > > entries saved in the config registry. > > > > So all in all we need a mechanism for enabling the mediation > > registry adapter to load resources from all registries. In an > > offline discussion Sumedha proposed the following path format for > > dynamic resources: > > > > gov:foo/bar/endpoint (Points to foo/bar/endpoint in governance > > registry) > > > > > > +1 > > > > > > conf:foo/bar/endpoint (Points to foo/bar/endpoint in config registry) > > > > > > +1 > > > > > > local:foo/bar/endpoint (Points to foo/bar/endpoint in local repo) > > > > > > Users must not store in the server local space. This is exclusive for > > the node's use. However, if this is stored by the components then I'm > > +1 for this. > > > > > > foo/bar/endpoint (Same as local:foo/bar/endpoint - For backward > > compatibility) > > > > > > +0. However, IMO, this should be config:foo/bar/endpoint, since it is > > the config registry that maps most closely to the former system/user > > registries. The local repository is a much more restricted version, > > and should not be used for such purpose. > > > > > > This looks like a fairly good approach to me. Thoughts? > > > > > > +1. It would be great if the other component authors could do a > > similar evaluation of their components, and let us know whether such > > changes should be done to those as well. > > > > Thanks, > > Senaka. > > > > > > Thanks > > -- > > Hiranya Jayathilaka > > Software Engineer; > > WSO2 Inc.; http://wso2.org > > E-mail: [email protected] <mailto:[email protected]>; Mobile: +94 > > 77 633 3491 > > Blog: http://techfeast-hiranya.blogspot.com > > > > _______________________________________________ > > Architecture mailing list > > [email protected] <mailto:[email protected]> > > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > > > > > > > > > -- > > Senaka Fernando > > Software Engineer > > WSO2 Inc. > > E-mail: senaka AT wso2.com <http://wso2.com>; Mobile: +94 77 322 1818 > > > > http://www.wso2.com/ - "Lean . Enterprise . Middleware" > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Architecture mailing list > > [email protected] > > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > > > > -- > Ruwan Linton > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb > WSO2 Inc.; http://wso2.org > email: [email protected]; cell: +94 77 341 3097 > blog: http://blog.ruwan.org > > Lean . Enterprise . Middleware > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Hiranya Jayathilaka Software Engineer; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
_______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
