support lazy, fail-fast and background initialization of asyncapi

[tvahrst]

This PR adresses issue #292 (provide option to create asyncapi lazy).

It introduces a new Property springwolf.loading-mode with three possible values:

• FAIL_FAST (AsyncAPI init during spring context creation, same behavior as before)
• LAZY (AsyncAPI init on first invocation of AsyncApiService.getAsyncApi().
• BACKGROUND (Same as LAZY, but first invocation is triggered by background thread after 'applicationReay'.

The default value ist LAZY

Some points that might be worth discussing:

• I was not sure about the term 'loading-mode', another possible name could be 'initializing-mode' ?
• DefaultChannelService is stateless now, it does not cache the detected ChannelItems. I changed the service's method from getChannels() to findChannels() to avoid 'getter' semantics, which could be interpreted as cheap 'get' operations. findChannels always invokes the scanners to aquire the available channels.
  • additionally, invoking the DefaultChannelService has a sideeffect on SchemasService. SchemasService is a kind of registry, invoked by scanners and caching all detetected schemas. Repeated findChannels() calls replaces the schemas in SchemaService. This is currently no problem, because findChannels() is only called once and SchemasService can handle multiple registrations of the same schema. If that seems to be a risk, DefaultChannelService should assure to call all scanners only once.
  • Exceptions during AsyncAPI detection are cached and thrown (wrapped by a root Exception) on every getAsyncApi call.

[netlify]

✅ Deploy Preview for springwolf-ui canceled.

Name	Link
🔨 Latest commit	74a38de
🔍 Latest deploy log	https://app.netlify.com/sites/springwolf-ui/deploys/64c39c4909b8ac000812cfb5

[timonback]

As mentioned before, I like the change.

It may look like a lot of comments, but it is mostly nitpicking of details.

1. I like the 3 options and view failFast and background as essential. lazy comes for free, but I wonder if we need it. I am thinking from the point of view of maintaining it. When it is out there, we cannot change/remove it. Is there a benefit to have lazy in comparison on background?
2. Personally, I view the feature as an expert/optimization setting. Therefore I would go with failFast as the default and opt in to other modes (and documented it on the website).
   Where am I coming from? As a first time user, I want to quickly see if I have configured everything right. When the spring application starts, that's my indicator that everything is fine (I might not even view logs by default). Delaying it could create user frustration as it is not visible why the application is starting (and the ui showing), but the document is empty and/or has a REST endpoint exception.
3. Good question regarding the naming. I can imagine also startUpMode and probably prefer init-mode / initMode out of the 3 options.
4. A stateless ChannelsService is great, as well as the improved naming of the methods. Yes, there is a side-effect, but I do not view it as a risk at this point.
5. Caching the getAsyncApi result is great, including the behaviour to rethrow the cached exception.
6. The word detect indicates to me that some is found/discovered (like the channels). For the AsyncApi document, I think it is rather build/constructed/generated.

I might be in the wrong, so feel free to ask questions and/or explain why another way/your suggestions is better.

Thanks again for the contribution.

[tvahrst]

Good points. I will try to apply the suggested modifications...

[tvahrst]

I changed 'LoadingMode' into 'InitMode'. Removed 'lazy', so there are two options left: 'background' and 'fail_fast'. Default is 'fail_fast'. Moved the initialization completely into the AsyncApiInitApplicationListener, removed afterPropertiesSet in DefaultAsyncApiService.

Cleaned up some tests.

[timonback]

The changes look good to me.

I made some changes so that initMode=lazy actually fails the start of the spring boot application: https://github.com/LVM-IT/springwolf-core/pull/1
What do you think, shall we merge it? Or do you want to avoid the InitializingBean interface?

[timonback]

Documentation: springwolf/springwolf.github.io#49