If you read the blog, you’ll see I’m new to Vaadin (but have been with Java EE since it began). I plan on using Vaadin as the front end for my projects going forward though. Some of them are open-source, so when I have something interesting I’m happy to share.
One interesting note on Vaadin with the EE 6 reference implementation (GlassFish v3). The GlassFish server has an option to preserve sessions during redeployment, which is very handy if you need to work on something that requires a few steps to reproduce (e.g., logging in). But with this turned on, Vaadin keeps the entire state in memory, including text of labels, buttons, etc., so changes to text in these cases doesn’t change unless I start a new session. This feature is so new that I don’t think it’s a problem, especially since it’s not the default. Hopefully I’ll know enough about the Vaadin source code to be able to suggest an enhancement once Java EE 6 becomes widespread.
Interesting post. Getting rid of web.xml is really tempting.
As Vaadin stores UI state in HttpSession, the whole application state is saved. This is designed to be a feature, not a bug.
Did you mean by “changes to text in these cases doesn’t change” that the modification you did to application does not get set to the label contents/text field captions/etc? In order to force application reload, add ?restartApplication to the URL.
Yes, I think it’s a very nice feature (I don’t see how Vaadin could work without it). I may not have explained it very well: this is a new case where I can maintain session even though I’m recompiling my classes. So, for lack of a better way to put it, Vaadin could save some of the application state but not all of it. In practice, I’m not even sure how it would work (and it would certainly be slower).
The more I think about it, the more I think it’s unworkable, if not downright ridiculous. The text (or graphic) of any component could have been set dynamically through some action of the user – my own blog example shows this. So when a page reloads, you’d have to query each component to see whether or not its current value matches the default/original value and, if so, go reload it. Ugh.
Yep, that’s what I mean. Adding the ?restartApplication restarts the session, which defeats the purpose of the new “preserve sessions across redeployment” feature. The simpler solution is for me to turn off this server behavior!
So, in summary, I
should have written that Vaadin developers should stay away from this server feature, but that’s probably obvious to the whole Vaadin community except me.
