Consider adding interfaces to listen to session and UI initializations, and to session destructions

Describe your motivation

Many use cases require applying some logic to all sessions or to all UIs. For example, to implement a custom error handler, one needs to listen to session initialization events and add the custom handler to each session. Similarly, certain use cases require listening to all UI initializations (for example, to check user’s credentials) and all session destructions (for example, to free up some resources).

Currently, one can listen to those three events via VaadinService’s addUIInitListener, addSessionInitListener, and addSessionDestroyListener methods. However, it might not be obvious to developers that VaadinService is the way to access these three events. Moreover, listening to these three events currently requires some boilerplate to listen to init events of the VaadinService itself.

Describe the solution you’d like

Consider providing convenient interfaces to enable listening to UI initializations and session initializations and destructions. Such interfaes would enable one to do something like the following:

public class MySessionListener implements VaadinSessionInitListener {
    
    @Override
    public void sessionInit(SessionInitEvent event) {
        event.getSession().setErrorHandler(new MyErrorHandler());
    }
}

[Legioth]

We are optimizing our designs for the Spring case, where adding @Component is already simple enough and the least surprising (and most versatile) way for seasoned Spring users.

For CDI users, there’s (iirc) already the option of using @Observes to get those events, so they also wouldn’t need anything simpler.

That mostly leaves the fully manual crowd that doesn’t use any DI framework, which is probably because they prefer to do things manually even if that requires slightly more explicit code. Also for them, a fully automatic approach would probably not be appreciated.

[knoobie]

Doing something automatically is, to my mind, simpler than manually doing so.

From the end-user perspective totally valid! I was more worried about the flow team 😉 Because I think this could break “easily” with different servlet container, OSGI, Portlets and all the other crazy implementation details the guys have to manage. So using either @Component support for spring or the standard way of Java to hook things up (META-INF) sounds better to maintain in the long run.

I would call this a breaking change, not a regression.

You got me with that, fair point!

But how about if we provide people with the option to disable auto-registering if they need to?

Possible, but probably not something I can answer rightfully 😃