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)
--
