One of the areas that has been an issue over time is taking an application, say deployed to jboss 3.0 or 3.2.3, and try to upgrade it to jboss 4.0.5. Or tomcat 4 to tomcat 5. Or any upgrades at all.
Real-world experience with struts (1.0/1.1)/JSP sites have several challenges in upgrading. Whether they are container based or implementation base, I have never had success with 'easy' upgrades.
JSF appears to have similar issues. I myself kept running into performance issues everytime I've attempted a JSF implementation, so relying on this post to confirm similar issues: http://jsfunit.blogspot.com/2010/12/jsf-on-jboss-as6-final.html
Now, onto one known savior - GWT is upgrade compatible. I have successfully upgraded 1.3 to 1.5, 1.5 to 2.0, 2.0 to 2.1, and 1.3 to 2.0 (I haven't tried direct to 2.1). The only upgrade issues were 1.3 to higher versions dealing with RPC changes.
Monday, January 24, 2011
Monday, January 17, 2011
Testing GWT-RPC, and why to be careful about jumping to RequestFactory
Just a copy of what I posted on StackOverflow: http://stackoverflow.com/questions/4119867/when-should-i-use-requestfactory-vs-gwt-rpc/4714437#4714437
The only caveat I would put in is that RequestFactory uses the binary data transport (deRPC maybe?) and not the normal GWT-RPC.
This only matters if you are doing heavy testing with SyncProxy, Jmeter, Fiddler, or any similar tool that can read/evaluate the contents of the HTTP request/response (like GWT-RPC), but would be more challenging with deRPC or RequestFactory.
The only caveat I would put in is that RequestFactory uses the binary data transport (deRPC maybe?) and not the normal GWT-RPC.
This only matters if you are doing heavy testing with SyncProxy, Jmeter, Fiddler, or any similar tool that can read/evaluate the contents of the HTTP request/response (like GWT-RPC), but would be more challenging with deRPC or RequestFactory.
Subscribe to:
Posts (Atom)