Random error with widgetset?

Hello everyone,

I got a little problem. This error appear randomly when i refresh a page (if i refresh again error not always repeat):

Widgetset ‘com.vaadin.DefaultWidgetSet’ does not contain implementation for com.sun.proxy.$Proxy139. Check its component connector’s @Connect mapping, widgetsets GWT module description file and re-compile your widgetset. In case you have downloaded a vaadin add-on package, you might want to refer to add-on instructions.

Has somebody got an idea?

Thanks in advance.

Apparently you are trying to map a proxy instance instead of a Component instance; what environment are you running in, and are you using any libraries that create proxies?

We’re using gradle and this is what we use:


I don’t think any of these libs use proxies.
The strange fact is that this error append randomly on refresh.

I have a suspicion that Spring uses proxies. Do you inject any components? how do you create the UI?

You should be able to find out what that component should be: the error is placed in the same place the component would be. So, check which component is misbehaving, and check how the component is created.

We are using Spring Vaadin Integration. We also use Aspect. We are getting below error.
com.vaadin.DefaultWidgetSet’ does not contain implementation for com.sun.proxy.$Proxy270 Check its component connector’s @Connect mapping, widgetsets GWT module description file and re-compile your widgetset.

For Widgets proxies are not getting created may the reason. This was working till we introduced Spring Aspect. We have custom Widget generated by Maven but it inherits DefaultWidgetSet which do not have the Proxy.

Any suggestions

The fundamental issue here is that Vaadin uses the runtime class of a component object to determine what widget to place on the client. This works well when using real objects; a Button object maps to a ButtonConnector object. But when using proxies, there is no way for Vaadin to know what the ‘real’ class should be. It can’t map a Proxy object to a ButtonConnector even if it wanted to.

As I have never used Aspect, I can’t give you any better advice. But as I mentioned in my previous post, start by determining which component should have been rendered. Find the place where that object is created in code. That is where the error happens, one way or the other.

Thank you Thomas. Currently we disabled the Aspect (Exception and logging) to the Vaadin UI package. Hope further releases of Vaading will support AOP (Spring) in much better way.

Unfortunately, Spring Aspects create proxies of classes at runtime, and, as it was explained above, such a setup can’t work with Vaadin. The only option is to make sure that the aspects are actually included in the original classes and not in proxies. AspectJ allows this with its concept of weaving – I’d suggest trying it out, since AspectJ can be integrated with Spring. Further reading: http://docs.spring.io/autorepo/docs/spring/4.0.6.RELEASE/spring-framework-reference/html/aop.html#aop-aj-ltw

In case you’re using SpringVaadinIntegration:

I had faced the same problem with Views annotated


Adding ProxyMode helped:

@Scope(value = “prototype” , proxyMode = ScopedProxyMode.TARGET_CLASS).

The problem may lay in different mutual injections of short-lived and long-lived scoped beans. See spring documentation:
Section 5.5, “Bean scopes” - Scoped beans as dependencies
I guess some bean is created with long-lived scope, and injects View beans with short-lived scope. In such cases we should provide some Proxies for these beans. Since we proxy Classes, not Interfaces, the

should be specified in



Also you may consider applying




It some how works. But yet I couldn’t have made head or tail of this magic. There are some cases when it doesn’t.[code]
public ServletRegistrationBean servletRegistrationBean()
ServletRegistrationBean registration = new ServletRegistrationBean(new SpringVaadinServlet());
// Servlet. init-param
Map<String, String> params = new HashMap<String, String>();
params.put(“beanName”, “ui”);

return registration;
[/code]In conclusion, I would suggest to use



I have the same problem. In my case it was fixed with proxyTargetClass = true param in @EnableGlobalMethodSecurity annotation.
My SecurityConfig class looks like this:

@EnableGlobalMethodSecurity(securedEnabled = true, proxyTargetClass = true)
public class SecurityConfig extends WebSecurityConfigurerAdapter {
//Class body