Wednesday, July 10, 2013

Vaadin error: A connector with id 7 is already registered!

This post describes a short analysis and possible solution when getting the error java.lang.RuntimeException: A connector with id 7 is already registered!


  • Vaadin 7.0.4 with Spring using the SpringVaadinIntegration plugin 1.6.5 and Shiro 1.2.1
  • The UI class has @Component en @Scope("prototype") as annotations
  • All components extend CustomComponent
  • All components but one component also have the @Scope("prototype") annotation
  • One component, let's call that the HelpWindow, it extends Window, has no @Scope annotation, and thus is a Spring singleton. The reason for it being a singleton is that it seemed the only solution to always have a sub-window on top of another sub-window (using UI.addWindow()). At least one situation in the project made the sub-window appear beneath another sub-window sometimes...
  • No @VaadinView used anywhere.
  • Spring 3.1.2
  • Tomcat 7 as application server.


This is the reproducible scenario that causes the A connector with id 7 is already registered! error to appear: 
  1. Log in for first time, so authentication is via Shiro: all fine, the HelpWindow is shown.
  2. Log out.
  3. Log in again. I can see the UI constructor and its init() getting invoked.
  4. Exception in the logfile:

    java.lang.RuntimeException: A connector with id 7 is already registered!
    ....... stuff deleted.....

    java.lang.RuntimeException: A connector with id 7 is already registered!
    at com.vaadin.ui.ConnectorTracker.registerConnector(
    at com.vaadin.server.AbstractClientConnector.attach(
    at com.vaadin.ui.AbstractComponent.attach(
    at com.vaadin.ui.Label.attach(
    at com.vaadin.server.AbstractClientConnector.setParent(
    at com.vaadin.ui.AbstractComponent.setParent(
    at com.vaadin.ui.Table.registerComponent(
    at com.vaadin.ui.Table.parseItemIdToCells(
    at com.vaadin.ui.Table.getVisibleCellsNoCache(
    at com.vaadin.ui.Table.refreshRenderedCells(
    at com.vaadin.ui.Table.getVisibleCells(
    at com.vaadin.ui.Table.beforeClientResponse(
    at com.vaadin.server.AbstractCommunicationManager.writeUidlResponse(
    at com.vaadin.server.AbstractCommunicationManager.paintAfterVariableChanges(
    at com.vaadin.server.AbstractCommunicationManager.handleUidlRequest(
    at com.vaadin.server.VaadinServlet.service(
    at com.vaadin.server.VaadinServlet.service(
    at javax.servlet.http.HttpServlet.service(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(
    at org.apache.shiro.web.servlet.AbstractShiroFilter$
    at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(
    at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(
    at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(
    at org.springframework.web.filter.DelegatingFilterProxy.doFilter(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.apache.catalina.core.StandardWrapperValve.invoke(
    at org.apache.catalina.core.StandardContextValve.invoke(
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
    at org.apache.catalina.core.StandardHostValve.invoke(
    at org.apache.catalina.valves.ErrorReportValve.invoke(
    at org.apache.catalina.valves.AccessLogValve.invoke(
    at org.apache.catalina.core.StandardEngineValve.invoke(
    at org.apache.catalina.connector.CoyoteAdapter.service(
    at org.apache.coyote.http11.AbstractHttp11Processor.process(
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(
    at java.util.concurrent.ThreadPoolExecutor.runWorker(
    at java.util.concurrent.ThreadPoolExecutor$

    The exception occurs at the moment UI.addWindow(helpWindow) is invoked (not included in this exception-dump).
  5. After this, even appending ?restartApplication to the URL won't save you anymore. Only a full restart of the application server (Tomcat) fixes the problem.
  6. BUT: if after the log out I press ctrl-F5 (so full browser refresh) once, the problem still occurs after logging in again.
  7. BUT: if after the log out I press ctrl-F5 twice, the problem does not occur! All works fine. 

Investigation and Solution

So very strange that Vaadin's ConnectorTracker thinks/sees the HelpWindow's connectorId already registered, because the user logged out and the UI's constructor and its init() method were invoked, so a completely new UI is created.
After pressing ctrl-F5 twice, I did see that the HelpWindow's connectorId is cleared (null).
Also changing the HelpWindow's scope to prototype fixed the problem, no exception; but prototype isn't an option for the project for above mentioned reason.

So something somewhere doesn't get fully cleared at logout time. Potentially the reasoning could be: since the HelpWindow is a singleton, Spring won't re-instantiate it (it's a singleton), Vaadin won't clear its connectorId either for some reason, so the ConnectorTracker (see the stacktrace) detects that it is already registered --> exception!

Several posts on the Vaadin forum indicated that the singleton vs prototype might be the problem. Like this one which indicates a potential problem right there. And in this one another caching-like problem is mentioned.

Also not "everything" getting cleared at logout was pointed out as a potential problem. So for that, the code invoked when logging out I changed from only doing currentUser.logout() and the setLocation() to:

// currentUser.logout() might also clear the Vaadin session, but better safe than sorry...

Subject currentUser = SecurityUtils.getSubject(); // Shiro
currentUser.logout(); // Shiro

// It's apparently essential to do the redirect too

For readability, the try/catch around each statement is omitted. And, as mentioned in the first comment, currentUser.logout() might already be sufficient to clear the session, did not further investigate this.

Together with a colleague another solution came to mind: try @Scope("request")! Using that as scope, within an HTTP request the HelpWindow bean exists only once, but a new one is created for each new HTTP request.
And yes, that did it! And it also keeps the 'sub-window on top of a sub-window' problem away.

Sufficient work-around for now!

PS: note that there might be something not 100% ok regarding scope in the SpringVaadinIntegration add-on; see this discussion on what the scope of the UI should be. The last comment (from the user pointing out this potential issue) also refers to using this post as a reference to integrating Spring with Vaadin....

Tip: talking about injection/CDI: integration Vaadin with JEE 6? This might be a good one to read.


Anonymous said...

it's strange that prototype scope didn't solve this, but with spring vaadin it's better to define spring beans as @SpringComponent @ViewScope

Tomasz Fruba said...


I have a Vaadin project, but I don't use Spring. However - I've faced exactly the same problem as you and - in my case - there was a problem with App name label in menu. It wasn't static, so I was a bit confused why the problem has happend and (thanks to your post) - the resolution came to me suddenly:

My menu class had a method:
public void attach() {

but there was no 'detach' method :)

After adding:
public void detach() {

everything works lika a charm :)

Thank you very much!!

Techie said...

Good to hear that my post helped a bit too :)

Genchev said...

Thank you very much!
Had the same issue and you solved it :)