Senaka/DimuthuG, Have you incorporated all the code review recommendations? If not, please mention which items have been left out and by when the pending items can be completed.
Thanks Azeez On Sun, Feb 28, 2010 at 8:48 AM, Senaka Fernando <[email protected]> wrote: > Sorry, > > I should have mentioned this in detail. > > On Sun, Feb 28, 2010 at 8:00 AM, Ruwan Linton <[email protected]> wrote: > >> Samisa Abeysinghe wrote: >> > >> > 13. Currently RegistryAbstractAdmin only have the >> > getRootRegistry(), >> > Check the posibility whether it should be moved up. To be >> > discussed >> > more. >> > >> > Decided to keep this at the registry level. >> > >> > >> > Rationale??? >> In-general, any code review decision should be discussed on this list to >> be altered. >> > > This was mainly required by the ESB team, where they had some UIs that > wanted to fetch resources from multiple registry paths. Discussed on this > offline with Ruwan and team, and agreed that extending RegistryAbstractAdmin > was sufficient, since, if you use the registry, you will anyway be including > the bundles that expose this class. > > On another thread, I discussed the possibilities of adding this into > AbstractAdmin (the top level entity), with Azeez (offline, and there were a > few others, who I don't recall). The conclusion was that, if we add this > method to AbstractAdmin, component authors may tend to use the RootRegistry > at their convinience, and place resources all over the registry, instead of > constraining themselves to one or two top level registry/repository paths > (ex:- config or config + local). Therefore, adding such a restriction would > make the developer be consious about what he/she does. > > Also, this is a convinience method and the registry can be obtained > directly from the session. But, that is not recommened, unless you are > really in need of it (ex: - in situations where you don't have registry > features added). Since the registry core server feature's components and > dependants (some Governance and ESB-related components), are the only > indentified users of this functionality, this decision shouldn't impact > other components. > > Thanks, > Senaka. > >> >> Thanks, >> Ruwan >> > >> > Samisa... >> > ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Carbon-dev mailing list >> > [email protected] >> > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > >> >> >> -- >> Ruwan Linton >> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb >> WSO2 <http://wso2.org/esb%0AWSO2> Inc.; http://wso2.org >> email: [email protected]; cell: +94 77 341 3097 >> blog: http://blog.ruwan.org >> >> Lean . Enterprise . Middleware >> >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > > > > -- > Senaka Fernando > Software Engineer > WSO2 Inc. > E-mail: senaka AT wso2.com; Mobile: +94 77 322 1818 > > http://www.wso2.com/ - "Lean . Enterprise . Middleware" > > _______________________________________________ > Carbon-dev mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- Afkham Azeez Senior Software Architect & Product Manager, WSO2 WSAS; WSO2, Inc.; http://wso2.com, Lean . Enterprise . Middleware Member; Apache Software Foundation; http://www.apache.org/ email: [email protected] cell: +94 77 3320919 blog: http://blog.afkham.org twitter: http://twitter.com/afkham_azeez linked-in: http://lk.linkedin.com/in/afkhamazeez
_______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
