bugfix: PostBoot commands now run after server ready event, not durin…

[lprimak]

…g service construction.
fixes #7806

This is due to the fact that previously, deploy would fail due to server not being ready for deployment fixes #7806

Description

Important Info

Blockers

Testing

Testing Performed

Tested CDI app in postboot

[Pandrex247]

I'll need to find some time to review this carefully.
The startup sequence is something we've been poking at for a while now, as the introduction of postboot has caused all sorts of sequencing issues.

I believe the state of the world is currently as such:

• Server Startup = Level 10
  • This would be where the various services of Payara start, of note being the services required to allow variable substitution via TranslatedConfigView (e.g. MicroProfile Config)
• Post-Boot = Level 12
  • This would be where the post-boot commands would run.
    • This would be where a user can configure the DAS and domain
    • This would also be where a user can deploy applications and resource adaptors
    • This would also be where a user can configure their new or existing resource adaptors.
    • The ordering of all of this would be up to the user and their script - we will continue to run the commands in the order defined.
• Deploy Applications = Level 15
  • This would be where predefined applications (those that have been deployed previously) would begin deployment
• Post-Startup = Level 20
  • This would be where applications defined for auto-deployment happen (e.g. those in the deployment dir)

I also recently reordered when exactly that SERVER_READY event gets fired due to a bug with the sequencing WRT to resource adaptors. It now explicitly fires "where it used to", namely after all previous applications have been deployed (after level 15). When we made changes it got fired earlier than it did before.

Done so here: #7576

In that PR I introduced a property as a fallback which should still be present, but that was intended as a "just in case" due to the delicate nature of this sequencing (butterflies and hurricanes): fish.payara.ready-after-applications
Set it to false to go back to the "old" (but not the "original") behaviour.
That being said I would like to review your case when I get some time to see where it should "properly" fall in the sequencing of things once you've published a reproducer

[Pandrex247]

See my other comment regarding sequencing.
This will likely reintroduce race conditions and sequencing issues: the postboot config file would be executed after all but new applications in the deploy dir have been deployed. Tying this service to an event rather than a specific run level will also mean that it races against all other services reacting to that event.

[lprimak]

Thanks for looking at this.
Yes, all of these questions is why I left this draft.

The "Anchor issue" still remains unresolved (#7655) and any help there would be appreciated.
Also, the Tyrus issue is still on the critical path and is priority one. We can take care of these after that is done.
payara/patched-src-tyrus#9