sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [Done] Consolidate starter-startup and startupfilter/startupfilter-disabler to use Apache Felix HC ServiceUnavailableFilter
Date Thu, 23 May 2019 11:15:56 GMT
I prefer security enabled by default. The more switches users have to 
flip to get a secure application, the more likely it becomes that they 
forget one.


Carsten


Georg Henzler wrote
> 
> 
>> 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.norman@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 <ghenzler@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
>>>> >> <ghenzler@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
>>>> >>> > <ghenzler@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

>>>>
>>>> >>> >>
>>>> >>>
>>>>
>>>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Mime
View raw message