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
Hi all,
so I have done some more testing and found out that during first
startup, it's not only the configs that become active very late:
1. Bundles of feature :boot become active at start level 1
2. All other bundles become active at start level 30 (and not what is
configured in
On Tue, 2019-04-16 at 08:19 +0200, Georg Henzler wrote:
> My proposal: We change the provisioning model in a way that all
> mentioned configurations become active exactly with the start level
> of
> org.apache.felix.configadmin. As this is the case from second startup
> on
> anyway, I suppose
Hi,
On Tue, Apr 16, 2019 at 8:19 AM Georg Henzler wrote:
> ...My proposal: We change the provisioning model in a way that all
> mentioned configurations become active exactly with the start level of
> org.apache.felix.configadmin
Makes sense to me, I can't think of a good reason to activate
Hi Robert,
thanks for the reference, SLING-6305 is partly this problem (but not
only as it seems). I fully agree with Felix's comment "I suggest to
attack the problem at the right place" [1] though.
My proposal: We change the provisioning model in a way that all
mentioned configurations
Hi Georg,
On Fri, 2019-04-12 at 00:47 +0200, Georg Henzler wrote:
> Hi all,
>
> I'm trying to add a config to the provisioning model [1] that is
> active
> during first startup at startlevel 5. Looking at [2] this does not
> seem
> to be possible (or it's not documented). On second startup
Hi all,
I'm trying to add a config to the provisioning model [1] that is active
during first startup at startlevel 5. Looking at [2] this does not seem
to be possible (or it's not documented). On second startup it's fine
since the config is there, but on first startup, the config is only
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 :
> Hi Jörg,
>
> there is the option "autoDisableFilter" [1] in the
> ServiceUnavailableFilter - if true the filter automatically unregisters
>
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
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
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
11 matches
Mail list logo
