Using shared state how to send com.vaadin.ui.Component to client

In Vaadin 6 I was sending com.vaadin.ui.Component from the SERVER to the CLIENT using paintTarget mechanism.

How can I send this component using shared state or server->client RPC on Vaadin 7 beta 10?

When I add com.vaadin.ui.Component as a member variable in my state class the widget does not compile and gives error saying this class is not in the class path?

thanks for your help.

Component is a server side class which means you cannot use it in the state or in RPC calls. The Connector class, which Component extends, is what you should use instead as it is shared between the server and the client. As a rule of thumb, you can only use com.vaadin.shared.* packages in your state classes and rpc interfaces.

But please note that as the framework handles the hierarchy you will get a null reference on the client side if you try to send a connector which is not attached to the hierarchy.

Thanks Arthur. So the connector that is extended by Component is ClientConnector. So lets say I put this ClientConnector in shared state class. Now on the client side, I need the access to the Widget instance of this (Component/ClientConnector) that I added in shared state. However, there is no method called getWidget() in ClientConnector class, so how would I get hold of Widget instance on the client side from this ClientConnector instance that I made it available to client using shared state?


I don’t know what you are trying to accomplish here, and i’m not a vaadin guru, and not even a developper, let’s say i’m just a Hobbist with a techi-minded thinking, who have fun playing with java and vaadin (love it) in particular. but enought about me. all this to say take what i’m saying with a grain of salt.

here is the général step involved in client server communication in Vaadin 7, assuming you have server side component talking (mapping) to a client widget counterpart :

  • server side component : the server Component must extend com.vaadin.ui.AbstractComponent for example MyButton extend AbstractComponent

  • client side widget : you can extend any type of widget you want. my WidgetButton can extend as an exemple. or even com.github.gwtbootstrap.client.ui.Button ( from gwt-bootstrap widget Library, it’s awesome , you should try it)

  • Connector : to link the serverSide component to the clientSide widget you need a special class, in vaadin semantic that class is where things happen,and it’s called a Connector. for example WidgetbuttonConnector extend com.vaadin.client.ui.AbstractComponentConnector

  • State : then happens a time when you would want to share some state between serverSide Component and clientSide Widget, this is where your componentState class come into play, for example WidgetButtonState which must extend com.vaadin.shared.AbstractComponentState

if you’re still following me then we should have :

Mybutton (server side component )
WidgetButton ( client side widget )

One thing to note is that shared state class is exactly what it means a placeholder for both server component and client widget to share the same information and “maintain some sort of synchronization”

So you can put some getter and setter in it to retrieve the field state between client/server . getText, setText to set a Label text component for example.

Another thing to note is that The Connector Class can be seen has a Listener for state change event, meaning it react as change happen, so you usualy have a onStateChange Method in the connector class of your widget to implement a particular behavior that you want.

It will also have a getState() method that you will have to Override from in the server Side component for example, my server side component “Mybutton” class has this :

@Override WidgetbuttonState getState() {
return (WidgetbuttonState) super.getState();

Finaly if you’re still with me , To send update to the client widget you must request it explicitly like this for example :

public void setText(String text ) {



The markAsDirty() method is the Vaadin 7 way to requestRepaint() i think so, in my understanding, So that the client get updated automatically.

Vaadin 7 has gone through a lot of change , many API break regarding vaadin 6, so it might be a good idea to go through example in the wiki to get a practical feel of all the new client/server communication, most of what i said come from the wiki.

hope it helps , sorry for being verbose .

reference : Very Good example of Hybrid application with server side component with client side widget.

The Book of vaadin has a good chapter ( maybe not complete) on the subject

Following this i managed to get some nice looking component from GWT-BootStrap Library talking to my serverside component …it’s a lot of boilter plate code /connector/rpc/state …etc but it’s more easy than the UIDL Cérémony that the vaadin old timers are familiar with. since even a non developper can tackle it …hum almost :wink:


If modifying the state e.g. with getState().setText(text), it is no longer necessary to explicitly call markAsDirty() - the framework now takes care of this.

If the component to communicate is a sub-component of your component, use the HasComponents/Abstract(Single)ComponentContainer… mechanisms and, if possible, a hierarchy change event to manage it.

If your component refers to a component that is not its subcomponent but elsewhere in hierarchy, just communicate it in state. If the component is a subcomponent but you just want to refer to it (e.g. “focus this subcomponent” based on information on server), you can refer to it in the state in addition to having it in the hierarchy.

The tutorials and examples will probably help clarify how this is used in practice.

Hello Henri,

Thanks you for shedding some light around that topic, that is very much appreciated of you taking the time to answer. 

"markAsDirty"  after a getState()  call:   Ok the framework taking care of this is  cool !  

Regarding hierarchy change event :   i'm not sure how to implement  in practice, for the application i'm working on right now i've been investigation the possibility of using 
some kind "  Even Bus "  just  for wide spread event deep in a hierarchy of component   and  Loose coupling  between component . 

What i'm playing with right now 
vaadin for backend logic and non custom ui component ( very few)
gwt  using uibinder for theUI a lot of custom component ( with mostly GWT-Bootstrap library)
Custom theme : just  learning about Sass but  i like it so far realy powerful. 
Rpc and state for  comunication
now starting to investigate the possibility/benefit of using a Event Bus :  maybe Google guava, or jboss Errai ...

A lot of fun, since i use vaadin , i keep on letting my co-worker with the Wow Effect on their face   :-) 

Thanks Henri


Hi, every sample i found is with basic types inside, but if I want to use a custom class inside the state class? any limitation? i’m tryind doing it but I receive a client side exception that says y class doesn’t have a constructor (ofcourse there’s the empty constructor) suggestions?

There are some limitations, but many custom classes should work as long as they and all the classes they refer to are available both to GWT compiler and to the server side (for instance in the same place as the state class itself). The classes used can contain other similar classes, basic collections (same types as directly in state) etc.

One significant limitation is that polymorphism within state is not supported - e.g. a field with declared type A cannot be used to pass an instance of a subclass of A. This is mostly because the system does not generate serializers and deserializers for types that are not declared in the state classes, but also makes it possible to optimize the representation a bit better. Also note that cyclic references in state are not allowed.

Henri, any known issue using interfaces inside the class passed in the state? I have List objects;

and the implementation of IMyInterface is in another project/package of the widget and state class, is in the consumer of the server component.
Could be an issue? in case any standard pattern to follow?

I believe this is a problem as the deserializer uses the declared type to pick the class to create and the deserializer to use, and cannot create instances of IMyInterface.

Thanks Henri, at the end the rule is easy: forget about interfaces and any other cool style, use basic POJO