I don’t think that would work for me. I have a set of IT that will test services running in a Sling Start Maven Plugin instance. In order to make sure that my tests can succeed and do not fail because of unsatisfied references I want to check the references before starting the tests (I had multiple occasions where I was debugging my code just to figure out that my bundles were active but some services were not accessible because of these unsatisfied references).
- Andy > On Feb 14, 2020, at 12:18 AM, Stefan Seifert <sseif...@pro-vision.de> wrote: > > did you try to use > https://sling.apache.org/documentation/development/osgi-mock.html > > it can be used standalone or as part of sling mocks. > > stefan > >> -----Original Message----- >> From: Andreas Schaefer [mailto:schaef...@me.com.INVALID] >> Sent: Thursday, February 13, 2020 10:34 PM >> To: dev >> Subject: Enhancing Testing Client OSGi package >> >> Hi >> >> I am working on a project with many backend OSGi services that have many >> references between them and I ran into many issues when the services were >> not fully workable due to unsatisfied references. >> >> The Testing Clients’ OsgiConsoleClient has a few methods to introspect the >> state of the OSGi bundles, components and services but they are not easy to >> use. >> >> In my case I need to find the ‘Declarative Service Components’, then get >> their Service Info and check that any reference of these components are >> satisfied. After some back and forth I was able to implement these tests >> but I could not use the OsgiConsoleClient which makes for a lot of heavy >> handed JsonNode parsing. >> >> So I was wondering if this is of interest for Sling to have a better way to >> inspect the OSGi system. This is what I have in mind: >> - Add additional data from the bundles into the BundleInfo class (like the >> Declarative Service Components) >> - Add additional data from the components into the ComponentInfo >> (references etc) >> - Add a method to call the OSGi Console from the OsgiConsoleClient directly >> (it does not support depths so the SlingClient’s doGet() does not work) >> >> Let me know if you think this would be valuable for Sling Testing Clients. >> >> - Andy
