Over a million developers have joined DZone.

Chicken and Egg Problem With Spring and Vaadin

DZone's Guide to

Chicken and Egg Problem With Spring and Vaadin

· Java Zone
Free Resource

Navigate the Maze of the End-User Experience and pick up this APM Essential guide, brought to you in partnership with CA Technologies

The more I dive into Vaadin, the more I love it: isolation from dirty plumbing, rich components, integration with portlets, Vaadin has it all.

Anyway, the more you explore a technology, the bigger the chances you fall down the proverbial rabbit hole. I found one just yesterday and came up with a solution. The problem is the following: in Vaadin, application objects are tied to the session. Since I’m a Spring fanboy, it does make sense to use Spring to wire all my dependencies. As such, I scoped all application-related beans (application, windows, buttons, resources, …) with session like so:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"






  <context:annotation-config />

  <bean id="application" scope="session">
  <aop:scoped-proxy />

This works nicely, until you happen to use DI to wire further. By wire further, I mean wiring windows into application, button into windows and then resources (icons) into buttons. It is the last  step that cause a circular dependency. Icon resources are implemented in Vaadin by com.vaadin.terminal.ClassResource. This class has two constructors that both needs an application instance.

The dependency cycle is thus: application -> window -> button -> resource -> application. Spring don’t like it and protests energically to it by throwing an exception which is labeled like so Requested bean is currently in creation: Is there an unresolvable circular reference?

. I think, in this case, that the design of the ClassResource is not adapted. That’s whyI designed a class aligned with Spring deferred instantiation: since the application is session-scoped, Spring uses a proxy that defers instantation from application start (Spring normal behaviour) to session use. The point is to implement the ApplicationResource interface, which needs an interface, but to set application only when needed:

public class DeferredClassResource implements ApplicationResource {

private static final long serialVersionUID = 1L;
private int bufferSize = 0;
private long cacheTime = DEFAULT_CACHETIME;
private Class<?> associatedClass;
private final String resourceName;
private Application application;

public DeferredClassResource(String resourceName) {

if (resourceName == null) {

throw new IllegalArgumentException("Resource name cannot be null");

this.resourceName = resourceName;

public DeferredClassResource(Class<?> associatedClass, String resourceName) {


if (associatedClass == null) {

throw new IllegalArgumentException("Associated class cannot be null");

this.associatedClass = associatedClass;

... // standard getters

public String getFilename() {

int index = 0;

int next = 0;

while ((next = resourceName.indexOf('/', index)) > 0
&& next + 1 < resourceName.length()) {
index = next + 1;

return resourceName.substring(index);

public DownloadStream getStream() {

final DownloadStream ds = new DownloadStream(associatedClass
.getResourceAsStream(resourceName), getMIMEType(),



return ds;

public String getMIMEType() {

return FileTypeResolver.getMIMEType(resourceName);

public void setApplication(Application application) {

if (this.application == application) {


if (this.application != null) {

throw new IllegalStateException("Application is already set for this resource");

this.application = application;

associatedClass = application.getClass();


DeferredClassResource is just a copy of ClassResource, but with adaptations that let the application be set later, not only in constructors. My problem is solved, I just need to let application know my resources so it can call setApplication(this) in a @PostConstruct annotated method.

From http://blog.frankel.ch/chicken-and-egg-problem-with-spring-and-vaadin

Thrive in the application economy with an APM model that is strategic. Be E.P.I.C. with CA APM.  Brought to you in partnership with CA Technologies.


Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}