Once the simplification of the Services API (and implementation) is complete, review for the points raised by @mcollovati below.
This may be contributing v16.0.0.0 of the application not completing startup
Services initialization and VaadinSession
As said during initialization some service raised errors
due to null VaadinSession; this happens because
service initializations is done in multiple threads.
Using ui.access or ui.accessSynchronously does not help because
it causes deadlocks in VaadinSession lock.
The way I managed to make it work is to get a reference to current UI
before submitting the task to the executor and have the callable task
wrapped in a another callable that sets Vaadin stuff
for the running thread.
public V call() {
val old = CurrentInstance.setCurrent(ui);
try {
return executeCall();
} finally {
CurrentInstance.restoreInstances(old);
}
}
This way we don't lock VaadinSession but I think services
are not meant to modify the UI during initialization.
Since the actual services only access VaadinSession to
store attributes I think that not locking
the VaadinSession may not be a problem.
Once the simplification of the Services API (and implementation) is complete, review for the points raised by @mcollovati below.
This may be contributing v16.0.0.0 of the application not completing startup