IllegalStateException: Cannot remove from parent when the session is not lo

Greetings, all.

We’ve a Vaadin 8 application for which we’ve developed a custom component that encapsulates a JavaScript video player (

Beside that JS video player, we’ve developed components for other ones that support different video encodings.

Whenever we want to switch the video source we create a new video component of the appropriate class and use setContent on our video container (a Panel). The old component is simply not referenced anymore, we’d expect it eventually gets garbage-collected.

This works fine in a single browser use case, but whenever we open another browser (i.e., Firefox and then Chrome) to the same view we get the IllegalStateException mentioned.

Any references to this exception we’ve found in a web search are related to Spring, and annotations like @ViewScope are suggested as a solution. However, our application doesn’t use Spring at all.

Admittedly, the more-than-one-browser scenario is unrealistic and only happens during testing, but it’d be nice to plug that hole.

We’d be grateful for any insight on the issue the community has to offer. Thanks in advance!

You have a flaw in your application code. The error is triggered since you have defined a Vaadin component in some way that it is shared by multiple sessions in your application. The most typical case is that you have defined it in static field, but there could be also other types of singleton pattern there. You should check your code and verify that the same object instance is not shred by multiple sessions.

You probably have found the references to Spring, since with it one flaw is to define the component to be ApplicationScope or something like that, when it again becomes shared by multiple sessions.

Hi, thanks for answering.

At first glance I can’t find any explicit static component declaration in our code, nor do we aim intentionally to have any components shared between sessions anywhere. We just assumed every connection to our servlet created its own UI and components by default, but we must have overlooked something about Vaadin’s application model somewhere.

Any common pitfalls we should know better to avoid?