In either case, this needs to be documented in the ErrorHandler javadoc. If yes, then the Vaadin environment should be set properly - the UI.getCurrent() should not return null. A server-driven architecture together with reusable component model is used to simplify programming of applications and for better web application security. It is designed for creating rich and interactive applications that run in the browser, without any plugins. If it doesn’t, this needs to be clearly documented. Vaadin is a Java web application framework. The ErrorHandler does not document whether it’s called in Vaadin UI thread or not. That may happen if you call the method from the custom thread without 'UI::access' or from tests without proper initialization.Īt .(Notification.java:426)Īt .(Notification.java:303)Īt .(Notification.java:227)Īt .(Notification.java:244)Īt .error(Bootstrap.java:20)Īt .UI$1.handleError(UI.java:520)Īt .FutureAccess.handleError(FutureAccess.java:76)Īt .nPendingAccessTasks(VaadinService.java:2045)Īt .VaadinSession.unlock(VaadinSession.java:681)Īt .VaadinService.ensureAccessQueuePurged(VaadinService.java:2005)Īt .VaadinService.accessSession(VaadinService.java:1972)Īt .VaadinSession.access(VaadinSession.java:969)Īt .UI.access(UI.java:506)Īt .UI.access(UI.java:489)Īt $1.run(MainView.java:52) It means that you are calling this method out of a normal workflow where it's always implicitly set.
That may happen if you call the method from the custom thread without 'UI::access' or from tests without proper initialization. That will fail to show any notification from the ErrorHandler with the following stacktrace: ERROR .UI - UI instance is not available. Throwing an exception in the ui.access() block from bg thread will call ErrorHandler.error() with UI.getCurrent() set to null.
0 kommentar(er)
