Hi, On Tue, Apr 5, 2011 at 7:00 AM, Afkham Azeez <[email protected]> wrote:
> Senaka, > Do you have access to the builder machine? Please try to work with AmilaM > and Denis to get this resolved ASAP. > > Azeez > > On Tue, Apr 5, 2011 at 6:44 AM, Senaka Fernando <[email protected]> wrote: > >> Hi Milinda, Dakshitha, >> >> This apparently seems to be caused by a bug. Let's add the expected >> behaviour (the code without workarounds) as a test-case to the Governance >> API tests in the governance component, and fix this. For the moment, we >> might need to exclude this, as it will instantly fail and effort to get the >> build stabilized will be impacted. So, let's add a blocker to the issue >> tracker pointing to this excluded test to ensure that this is fixed. >> >> Thanks, >> Senaka. >> >> On Mon, Apr 4, 2011 at 8:38 PM, Milinda Pathirage <[email protected]>wrote: >> >>> There is a requirement where we need to get the current life-cycle state >>> of a service deployed in governance registry via Governance API. But with >>> the current Governance API this is not straight forward and we have to >>> work-around this via Registry API. For the workaround we need to get the >>> path of the Service and get the life-cycle related properties for that path >>> via Registry API. Dakshitha carried out some tests and figure out >>> that org.wso2.carbon.governance.api.services.dataobjects.Service#getPath >>> returns null >>> >> When were this tests run? Because, this issue is reported at [1] and was resolved by Senaka. Now any GovernanceArtifact should return the correct path when getPath() method is called. [1] https://wso2.org/jira/browse/CARBON-8971 > and following is the workaround to solve that null path issue. >>> >>> // ---------------------------------------------- >>> However there is a workaround to get the path. In the code below, (the >>> text in bold) the property variable gives the resource path. The path inside >>> remoteRegistry.get() should remain as * >>> /_system/governance/repository/components/org.wso2.carbon.governance/artifacts >>> *. >>> >>> Instead of using s.getPath() this method can be used. >>> >>> String registryURL = "https://localhost:9443/registry/";; >>> RemoteRegistry remoteRegistry = null; >>> try { >>> remoteRegistry = new RemoteRegistry(new URL(registryURL), >>> "admin", >>> "admin"); >>> ServiceManager sm = new ServiceManager(remoteRegistry); >>> Service[] services = sm.getAllServices(); >>> for (Service s : services) { >>> * String property = remoteRegistry >>> .get(" >>> /_system/governance/repository/components/org.wso2.carbon.governance/artifacts >>> ") >>> ** .getProperty(s.getId())*; >>> System.out.println(property); >>> } >>> >>> // Resource resource = remoteRegistry.get("/_system"); >>> } catch (MalformedURLException e1) { >>> e1.printStackTrace(); >>> } catch (RegistryException e1) { >>> e1.printStackTrace(); >>> } catch (GovernanceException e) { >>> e.printStackTrace(); >>> } >>> >>> Thanks, >>> -- >>> Dakshitha Ratnayake >>> >>> // ------------------------------------------ >>> >>> >>> I think we need to improve Governance API to support life cycles and >>> other additional features in Governance Registry. As an alternative we >>> can have a custom Web Services API based on Registry API to facilitate these >>> type of requirements. So in our case we can provide Web Services API where >>> we abstract out service life cycle concepts. But because this life-cycles >>> can be customized the API of the Web Service can change depending on the >>> user scenario. So if we provide sample implementation of service life cycle >>> API, users can use that as a reference for there custom extensions. Another >>> main reason for suggesting this is the nature our life-cycle support >>> implementation which is done via Aspects and Registry API for resources and >>> life cycle handling APIs are somewhat generic and implemented on top of >>> Registry API. >>> >>> The above suggestions came up during a offline discussion we(my self, >>> Sanjiva and Samisa) had. Please feel free to comment on this. >>> >>> Thanks >>> Milinda >>> >>> >>> >>> >>> >>> -- >>> Milinda Pathirage >>> Technical Lead and Product Manager, Business Process Server - WSO2 Inc; >>> http://wso2.com >>> Blog: http://blog.mpathirage.com >>> >>> Lean Enterprise Middleware >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Senaka Fernando* >> Product Manager - WSO2 Governance Registry; >> Associate Technical Lead; WSO2, Inc.; http://wso2.com* >> Member; Apache Software Foundation; http://apache.org >> >> E-mail: senaka AT wso2.com >> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 >> Linked-In: http://www.linkedin.com/in/senakafernando >> >> *Lean . Enterprise . Middleware >> >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> > > > -- > *Afkham Azeez* > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, > * > * > *Member; Apache Software Foundation; > **http://www.apache.org/*<http://www.apache.org/> > * > email: **[email protected]* <[email protected]>* cell: +94 77 3320919 > blog: **http://blog.afkham.org* <http://blog.afkham.org>* > twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> > * > linked-in: **http://lk.linkedin.com/in/afkhamazeez* > * > * > *Lean . Enterprise . Middleware* > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sadeep Jayasumana Software Engineer WSO2 Inc. Email - [email protected] Mobile - +94 77 22 66 507
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
