Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SCION Platform Lifecycle after Activator Initialization #6

Closed
efux opened this issue Jun 25, 2020 · 0 comments
Closed

SCION Platform Lifecycle after Activator Initialization #6

efux opened this issue Jun 25, 2020 · 0 comments
Assignees
Labels

Comments

@efux
Copy link
Contributor

efux commented Jun 25, 2020

Is your feature request related to a problem?

We are using multiple micro-frontends. As soon as the application is started, we send an intent to a micro-frontend, which is handled by the Activator of the micro-frontend. The activator then uses the OutletRouter to display a page.

Currently the host application does not know, if there is somebody listening to the capabilities described in the client's manifest.json. This leads to sent intents being lost, when the intents are sent to early.

Describe alternatives you've considered

Currently we are send a topic message per micro-frontend after the activator is completely initialized. E.g.

Beans.get(MessageClient)
                .publish('activated/casa-angebot-web', null, {retain: true});

And the host application waits until it has received activated/* messages from every necessary micro-frontend before triggering the intent for navigation.

Describe the solution you'd like

There are multiple possible solutions:

  • Maybe some of the work (or all?) done by the workaround can be handled by the SCION platform.
  • Maybe there is even a possiblity to know if somebody is really handling a capability, so sent intents are not lost.
@danielwiehl danielwiehl self-assigned this Jun 25, 2020
danielwiehl added a commit that referenced this issue Jul 8, 2020
Starting an activator may take some time. In order not to miss any messages or intents,
an activator can instruct the platform host to wait to enter started state until signaling ready.

To implement this feature, we have introduced runlevels to control the execution time of initializers.
Initializers bound to lower runlevels execute before initializers of higher runlevels. Initializers of the
same runlevel may execute in parallel.

closes #6
@danielwiehl danielwiehl mentioned this issue Jul 10, 2020
16 tasks
danielwiehl added a commit that referenced this issue Jul 10, 2020
Starting an activator may take some time. In order not to miss any messages or intents,
an activator can instruct the platform host to wait to enter started state until signaling ready.

To implement this feature, we have introduced runlevels to control the execution time of initializers.
Initializers bound to lower runlevels execute before initializers of higher runlevels. Initializers of the
same runlevel may execute in parallel.

closes #6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants