sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Munteanu <romb...@apache.org>
Subject Re: [Done] Consolidate starter-startup and startupfilter/startupfilter-disabler to use Apache Felix HC ServiceUnavailableFilter
Date Thu, 23 May 2019 16:09:16 GMT
+1

On Thu, 2019-05-23 at 06:15 -0500, Carsten Ziegeler wrote:
> 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.ServiceUnavailable
> > > > > > > > Filter
> > > > > > > >       tags=["systemalive]
> > > > > > > > 
> > > > > > > > osgi.http.whiteboard.context.select="(&(
> > > > > osgi.http.whiteboard.context.name
> > > > > > > > \=*)(!(osgi.http.whiteboard.context.name\=org.osgi.serv
> > > > > > > > ice.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