What do you think about setting the
"includeExecutionResult" service configuration property to false to
suppress that report injection?
The sling starter is more for demo purposes, and for that reason I think
includeExecutionResult=true is good. Also for many enterprise
deployments the 503 result never reaches the internet (but a LB takes
care of it, and then it's nice to have this information in the result
for analysis). So I think the default includeExecutionResult=true is
good, but whenever needed for security reasons it can be set to false.
-Georg
For example, this html comment was being injected into the starting up
page:
<!--
--------------------------------------------------------------------------------------------------------------------------------------------
Overall Health Result:
TEMPORARILY_UNAVAILABLE
--------------------------------------------------------------------------------------------------------------------------------------------
Name Result Timing
Logs
--------------------------------------------------------------------------------------------------------------------------------------------
Services Ready Check TEMPORARILY_UNAVAILABLE
[19:26:28.575|2ms]
TEMPORARILY_UNAVAILABLE Not all required services are available
(4 are missing)
OSGi Framework Ready Check OK
[19:26:28.573|0ms]
Framework started (state: ACTIVE) Current Start Level: 30
(Target: 30; Beginning: 30)
--------------------------------------------------------------------------------------------------------------------------------------------
-->
Regards,
Eric
On Wed, May 22, 2019 at 7:00 PM Eric Norman <eric.d.nor...@gmail.com>
wrote:
Hi Georg,
I'm trying to digest what has been done here. It looks like this
makes
the solution that was done for
https://issues.apache.org/jira/browse/SLING-7764 obsolete and breaks
compatibility for any customization done via a fragment attached to
the
previous o.a.sling.starter.startup snapshot bundle?
Have you provided any documentation on the expected technique for
customizing the content of the page that is displayed when starting up
or
some guidance on how people would migrate from the old way to the new
solution?
Also what should happen for custom builds that don't include
the org.apache.sling.starter.content artifact and still want a default
"starting up" page to be displayed?
Regards,
Eric
On Wed, May 22, 2019 at 3:35 PM Georg Henzler <ghenz...@apache.org>
wrote:
Hi all,
I finished this, mostly with commit [1]. I moved some bundles into
different start levels for better startup behaviour (that way I got
could finish this without fixing SLING-8355 first).
-Georg
[1]
https://github.com/apache/sling-org-apache-sling-starter/commit/a16fb43f1d0333f74b066844e0377d93ca1e1e08
On 2019-05-14 11:05, Georg Henzler wrote:
> So I'll move forward with this and I created [1] to track this change.
>
> -Georg
>
> [1] https://issues.apache.org/jira/browse/SLING-8418
>
> On 2019-04-08 10:49, Jörg Hoh wrote:
>> Hi Georg,
>>
>> ok, wasn't aware of the "100% compatibility mode" :-) So +1 from my
>> side.
>>
>> Jörg
>>
>> Am Mo., 8. Apr. 2019 um 00:28 Uhr schrieb Georg Henzler
>> <ghenz...@apache.org
>>> :
>>
>>> Hi Jörg,
>>>
>>> there is the option "autoDisableFilter" [1] in the
>>> ServiceUnavailableFilter - if true the filter automatically
>>> unregisters
>>> itself upon first non-503 result. Once unregistered it listens to
>>> FrameworkEvent.STARTLEVEL_CHANGED events to reregister once needed
>>> (the
>>> shutdown case). During normal operations (that includes deployments
>>> that
>>> might cause the selected "systemalive" checks to be temporarily
>>> unavailable) the filter is not active (which is also good from a
>>> performance perspective).
>>>
>>> So really, all that would be needed to replace oas-startupfilter +
>>> -disabler and oas-starter-startup is the simple config [2] in the
>>> oas-starter provisioning model.
>>>
>>> -Georg
>>>
>>> [1]
>>>
>>>
https://github.com/apache/felix/blob/d5245ba3ba306b57b83c4d5c6cfe499d955b0acb/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java#L98
>>>
>>> [2]
>>>
>>> org.apache.felix.hc.core.impl.filter.ServiceUnavailableFilter
>>> tags=["systemalive]
>>>
>>> osgi.http.whiteboard.context.select="(&(
osgi.http.whiteboard.context.name
>>> \=*)(!(osgi.http.whiteboard.context.name\=org.osgi.service.http)))"
>>> osgi.http.whiteboard.filter.regex=".*"
>>> autoDisableFilter=B"true"
>>>
>>>
>>> On 2019-04-07 19:49, Jörg Hoh wrote:
>>> > Hi Georg,
>>> >
>>> > Merging the 2 implementations oas-startupfilter + -disabler and
>>> > oas-starter-startup makes fully sense to me, although I am bit
hesitant
>>> > by
>>> > replacing the basic approach.
>>> >
>>> > these 2 have a rather static assumption, when the application is up,
>>> > and
>>> > their sole purpose is to indicate that. And once the system is up,
it's
>>> > up
>>> > and this state remains unchanged until the startupfilterDisabler is
>>> > deactivated. A healthcheck based implementation can changed its mind
>>> > based
>>> > on many factors, you already mentioned the fact that key services
>>> > should be
>>> > available. If these services go down during runtime, the status of
this
>>> > check changes.
>>> >
>>> > If I understand you correctly, then the semantic of the startup
itself
>>> > might not change, but it's more likely, that the unavailability of
such
>>> > a
>>> > key service would cause the Filter to kick again, changing
>>> > runtime-behavior; currently it does not.
>>> >
>>> > Is this intended?
>>> >
>>> > Jörg
>>> >
>>> >
>>> > Am Sa., 6. Apr. 2019 um 00:24 Uhr schrieb Georg Henzler
>>> > <ghenz...@apache.org
>>> >> :
>>> >
>>> >> Hi all,
>>> >>
>>> >> we have currently two mechanisms in Sling to wait for startup:
>>> >>
>>> >> * sling-org-apache-sling-startupfilter +
>>> >> sling-org-apache-sling-startupfilter-disabler
>>> >> * sling-org-apache-sling-starter-startup (only used for the starter
>>> >> application AFAIK)
>>> >>
>>> >> Now that systemready in Felix is fully migrated to Felix Health
Checks
>>> >> I
>>> >> would like to rely on ServiceUnavailableFilter [1] instead. The
>>> >> advantage is that this filter can be configured in a declarative
>>> >> fashion
>>> >> (what is required to be alive can be configured, e.g. for a
customer
>>> >> project it's easy to wait for additional custom services) and 503
is
>>> >> also correctly sent upon shutdown.
>>> >>
>>> >> Is this approach something everyone is ok with?
>>> >>
>>> >> -Georg
>>> >>
>>> >> [1]
>>> >>
>>> >>
>>>
https://github.com/apache/felix/blob/trunk/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java
>>> >>
>>>
