Hi
What is in your opinion fastest web container or application server for Vaadin development using Eclipse plugin?
-tommi
I use Tomcat mostly, but built in “J2EE Preview” container is also quite good for some simple tasks…
For really large applications it could be worthwhile to consider Glassfish V3 and use OSGi to split the application in separately loaded pieces:
http://vaadin.com/wiki/-/wiki/Main/Creating%20a%20Modular%20Vaadin%20Application%20with%20OSGi
.
Thank you!
Hi,
I’m using Tomcat and J2EE preview also, but the one that really rips is
Jetty.
It’s set up like our demo launcher in the Vaadin package (one java file) so you can run it via debug/run in eclipse, bypassing ‘run on server’. On my slow laptop the difference is significant: Jetty starts and opens the page in the browser in under 3sec, while even J2EE preview takes,well, forever it seems (a little over 10 sec). It makes it easier and faster to just restart instead of hoping that hotdeploy works and restart if it does not… Also, “run on server” w/ tomcat sometimes (seldom enough so that you forget to watch out for it) does not update resources properly, causing major confusion - Jetty set up like this runs the project ‘in place’, so resource changes are more predictable and immediate.
(of course this method is not suitable for all projects, but for plain Vaadin projects it rocks - IMHO, that is…)
I’ve been lobbying to get a Jetty embedded into the plugin… try it and join the lobbying! 
Best Regards,
Marc
Create a Uservoice feature request and I’ll vote for it 
Argeeing with Marc that jetty is great, but also admitting that I am one of the persons objecting embedding Jetty into our plugin.
Why? Running a J2EE application in Eclipse is clearly WTP:s responsibility. Even if WTP could be better, I think that we should not create (and maintain) our own partial replacement for it. Instead we should use our time to make Vaadin better and let the others develop WTP further.
Have anyone tried out JRebel?
http://www.zeroturnaround.com/jrebel/comparison/
It sounds like it could make restarting server or redeploying application something that would be needed really rarely and thus could make Vaadin application development really fast.
Hi,
I’m using JRebel everyday and it is such a great time-saver. No more container restarts and no more hot-deploy-errors. I’ve used JRebel with Echo and I’m using it now mostly with ZK. I’m currently considering moving to Vaadin and created a simple toy app. JRebel works like a charm with Vaadin. So I would really recommend to give it a try.
Cheers, Maik
Hey!
I just gave it a whirl inspired by this discussion. I have to say that I’m fairly pleased with it so far.
I just did a quick test with it: I started my application and then added to my main window class a new function:
public Label printNewLabel() {
return new Label("Foobebaaar!");
}
and added to the Window constructor a few times
addComponent(printNewLabel());After pressing save I just got into the console:
JRebel: Reloading class 'com.example.quicksearch.QuickSearchWindow'.
and with a mere ?restartApplication the new labels were visible to me.
Fantastic! No reboots required! A shame that JRebel is commercial.
It seems that they promote free license for OSS projects. Maybe we could have one for Vaadin committers…
Note that J2EE Preview in Eclipse IS Jetty.
Some of its configuration is not as good as it could be, making a stand-alone Jetty sometimes nicer with respect to hot code replacement, but I hope it improves in the future.
Of this would not affect the ability to run it in the WTP way, it would just be a quicker way to run your basic Vaadin projects. This would not require much additional maintaining either: we already have the demo/devel launcher AND the visual editor also uses an embedded Jetty.
As Henri pointer out, J2EE is Jetty. Personally I think it’s sluggish to start mainly due to the extra overhead introduced by the WTP - adding it to the ‘Servers’ view, copying the content to a different location (or is that Tomcat specific?). For most of my projects, the WTP way of running servers has not added anything useful, just made it slower and more prone to have resources out of sync - but this depends on the project and your needs.
Also, we’re definitely going to be looking at integrating more closely with the new GWT 2.0 tools (and the Google Eclipse Plugin), so the right way to do this might be to just use the GWT development mode (although that might turn out to be slow starting too, I have not tried configuring the new version with a proper project yet).
Which method is best/fastest also depends on whether you’re developing server-side only, or doing work on the client-side (widgetsets) as well.
Best Regards,
Marc
Oh, BTW: better hot code replace is good for any of these alternatives, regardless of how fast the server starts.
The best would be that WTP started supporting serving directly from the workspace, J2EE Preview Container would work reliably, classes would be loaded directly from Eclipse (like in Sysdeo DevLoader) and we would have JRebel-like hot-code-replacement built into JVM.
Must. Stop. Daydreaming…
My point was that while we could probably create and maintain a better+faster partial replacement for WTP it, we probably should focus on more urgent things in the backlog and let WTP people make WTP better
We’re using NB + Glassfish v2 and v3 and need to say, NetBean’s hot redeploy on code/resources change works as fast as JRebel - Just press “Save” button or drop a new/changed resource file - I did not notice any difference in speed. However, yes, this required adding a bunch of JVM options to get rid of OOM bugs with class reloading, but it now works.
Sometimes, however, NetBeans redeploy mechanism stuck and starts eating CPU. I think I’ll play more with JRebel if I discover more differences
I have been working with maven and jetty plugin. When using mvn jetty:run Eclipse automatic building will propagate your changes to target/classes which in turn will be noticed by jetty and hot code replace will take place. Any code change seems to be instantly visible in the browser.
There is just one thing to take care first: The maven build copies duplicate classes under target/project-name/ and these have to be cleaned away each time full build is done. After this the eclipse generated classes are the ones seen by the class loader and the code changes become visible. I just made simple batch file which executes mvn clean package, deletes the duplicate classes and executes mvn jetty:run. If someone knows how to fix this properly please let me know. Could be that the project is somehow mixed up to have this kind of problem in the first place.
There is also another dependent project in the build containing WebService client generated by wsimport maven plugin. This client is used for data access and everything seems to play together pretty nicely including lazy loading data tables. It would be nice if the containers did not have to provide the table all the item ids in an array but rather use index based paging similar to traditional web page tables. I found some example here which created the ids based on index but that approach breaks done entirely when you start sorting the table. Maybe I am missing something?
The only problem with 6.2.7 I have spotted so far is that Select component value change listener does not seem to get event when the Select value is changed but rather when the arrow in the Select is clicked.
Regards,
Tommi
I guess you guys had no issues getting JRebel to work. I am getting,
com.zeroturnaround.javarebel.ig: java.lang.ClassNotFoundException: com.google.gwt.user.client.ui.Widget
at com.zeroturnaround.javarebel.jM.visit(JRebel:204)
at com.zeroturnaround.javarebel.er.visit(Unknown Source)
at com.zeroturnaround.javarebel.jU.visit(JRebel:20)
at com.zeroturnaround.javarebel.er.visit(Unknown Source)
…
I mesed around with the rebel.xml and tried to add the directory that contains, gwt-user.jar which is where this class actually sits and no luck.
Anyone seen this before?
Thanks
Are you trying to use JRebel for client side code?
I don’t think this class should be required when making modifications to most server side classes. If it is, maybe there is a problematic dependency somewhere from the server to the client.
For client side development, I have not used JRebel; the GWT Development Mode server can recompile the appropriate parts of the client side code when necessary, at least within some limits, and I don’t think JRebel would be able to play nicely with the GWT Development Mode server, especially with embedded native JavaScript in the code.