This would be interpreted by a provisioning agent that uses the OSGi resolver to calculate a requirement closure.
But you know this is not a hard requirement. :) It's an idea we can add at any time. I don't think it should hold up your first release. I, or anyone interested like Christian, can always contribute it at any point. So, please don't let this block you on my account. Cheers, - Ray On Sat, Jan 26, 2019 at 10:03 AM Georg Henzler <fe...@ghenzler.de> wrote: > Hi, > > so I'm more than happy to have a @RequireFelixHealthCheck in... I had a > look at the RequireGogo annotation [1] and usages like [2], I could > follow that pattern but I'm not sure where this is exactly interpreted > at the moment as I'm mostly used to the Apache Sling-based provisioning > mechanism. Is the simple way of starting Felix with "java -jar > bin/felix.jar" taking those annotations into account? The documentation > in [3] does not seem to explicitly mention it... > > > I just also checked where we could put the annotations. We have the > > bundles > > API and annotation. > > This makes me wonder if we could put the annotations into the API > > bundle. > > WDYT? > > At the moment the annotations maven module is not a bundle, as it is > only required at build time by bnd-maven-plugin. To move on with this I > have to understand how/where annotations like @RequireGogo are > interpreted :) > > -Georg > > [1] > > https://github.com/apache/felix/blob/trunk/gogo/runtime/src/main/java/org/apache/felix/service/command/annotations/RequireGogo.java > [2] > > https://github.com/apache/felix/blob/trunk/gogo/itest-jline/src/main/java/org/apache/felix/gogo/itest/jline/package-info.java > [3] > > http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-usage-documentation.html#starting-the-framework > > On 2019-01-26 08:29, Christian Schneider wrote: > > +1 for a @RequireFelixHealthCheck annotation. > > I think we then also need an annotation for requiring the health check > > web > > console plugin, or do you see a way to automate this when web console > > is > > present. > > > > > > > Christian > > > > Am Sa., 26. Jan. 2019 um 00:04 Uhr schrieb Raymond Auge < > > raymond.a...@liferay.com>: > > > >> So, I wasn't suggesting to make an explicit requirement needed for > >> this, > >> but rather a convenience annotation similar to > >> > >> @RequireJaxrsWhiteboard [1] > >> > >> which is an annotation that I can use if I want to assert that the > >> deployment will calculate that I want a JAXRS whiteboard dpeloyed. > >> > >> :) > >> > >> This is a way to build a deployment descriptor into what you might > >> refer to > >> as an "Application bundle" which might be a package-info.java > >> containing: > >> > >> @RequireJaxrsWhiteboard > >> @RequireCDIExtender > >> @RequireGogo > >> @RequireFelixHealthCheck > >> package com.acme.application; > >> > >> This is in place of having to write out some deployment descriptor > >> somewhere in like a bndrun or feature file. The resolver can simple > >> resolve > >> those from some set of repositories with no other input other than > >> your > >> application bundle. > >> > >> Sincerely, > >> - Ray > >> > >> [1] > >> > >> > https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#org.osgi.service.jaxrs.whiteboard.annotations.RequireJaxrsWhiteboard > >> > >> On Fri, Jan 25, 2019 at 4:50 PM Georg Henzler <fe...@ghenzler.de> > >> wrote: > >> > >> > Having thought a bit more about this, for most bundles implementing a > >> > health check it is more of an optional extension. This means > bundle-XYZ > >> > primarily will provide the functionality XYZ with an optional health > >> > check testing state around functionality XYZ in action. Usually you > >> > would even make the package dependency to org.apache.felix.hc.api > >> > optional with the result that > >> > > >> > - if bundle org.apache.sling.hc.api is *not* available, > >> > functionality XYZ is still fully working > >> > - if bundle org.apache.sling.hc.api *is* available, > >> > functionality XYZ is working and can be checked via provided HC(s) > >> > > >> > So I think it's fine to start without an explicitly declared > capability, > >> > we can add this easily later if desired. > >> > > >> > -Georg > >> > > >> > > >> > On 2019-01-21 15:06, Raymond Auge wrote: > >> > > On Mon, Jan 21, 2019 at 2:19 AM Georg Henzler <fe...@ghenzler.de> > >> > > wrote: > >> > > > >> > >> Hi Ray, > >> > >> > >> > >> so your suggestion is more about referring to a capability like > >> > >> "org.apache.felix.healthcheck" by using requirements in other > bundles > >> > >> than writing a health check that ensures the framework provides a > >> > >> certain non-healthcheck-related capability. > >> > >> > >> > > > >> > > Precisely, > >> > > > >> > > - Ray > >> > > > >> > > > >> > >> > >> > >> > I can probably try it out and submit the proper cap&req. > >> > >> > >> > >> that would be great! > >> > >> > >> > >> -Georg > >> > >> > >> > >> > >> > > >> > >> > >> -- > >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > >> (@rotty3000) > >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > >> (@Liferay) > >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > >> (@OSGiAlliance) > >> > > > > > > -- > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
