If you’re developing GWT apps with traditional servlets (other than GWT-RPC) with your web server running as separate process, you can’t really send GWT Ajax messages from hosted mode since the outside process and port are considered to be another domain and GWT won’t send cross domain requests. One clean solution is to use a transparent proxy as hosted mode servlet and let that proxy talk to the real server. Here are the steps I took:
Find following jars are copy them to your GWT project:

{GWT-Project}/war/WEB-INF/lib
        jetty-http-7.1.3.v20100526.jar
        jetty-io-7.1.3.v20100526.jar
        jetty-servlets-7.1.3.v20100526.jar
        jetty-continuation-7.1.3.v20100526.jar
        jetty-util-7.1.3.v20100526.jar
        jetty-client-7.1.3.v20100526.jar
        jetty-jmx-7.1.3.v20100526.jar

Add these jars to Referenced Libraries -> Build Path -> Configure Build Path -> Libraries -> Add Jars.
Don’t forget to make sure these jars are selected in ‘Order and Export’ Tab.

Modify {GWT-Project}/war/WEB-INF/web.xml:

<web-app>
	<filter>
	    <filter-name>JettyContinuationFilter</filter-name>
	    <filter-class>org.eclipse.jetty.continuation.ContinuationFilter</filter-class>
	</filter>
	<filter-mapping>
	    <filter-name>JettyContinuationFilter</filter-name>
	    <url-pattern>/app/*</url-pattern>
	</filter-mapping>
    <servlet>
        <servlet-name>jetty-proxy-servlet</servlet-name>
        <servlet-class>org.eclipse.jetty.servlets.ProxyServlet$Transparent</servlet-class>
        <init-param>
            <param-name>ProxyTo</param-name>
            <param-value>http://localhost:8080/</param-value>
        </init-param>
        <init-param>
            <param-name>Prefix</param-name>
            <param-value>/</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
<servlet-mapping>
        <servlet-name>jetty-proxy-servlet</servlet-name>
        <url-pattern>/app/*</url-pattern>
    </servlet-mapping>   
</web-app>

Now all your URLS in your GWT app starting with ‘/app’ are normally forwarded to your traditional web server at localhost:8080.
BTW, I got these jetty jars from my local maven .m2 repository.

If you’re getting ClassNotFoundException for your GWT server servlets, even though the class exists and is ok, you might want to check out the Build Path in Eclipse and make sure All libraries are selected in

 Java Build Path -> Order and Export.

The error message could be confusing and misleading. Hope this tip saves you some time.

Dependency Injection is supposed to make your life easier when it comes to writing Unit and Integration Tests; assuming you do your homework right and indeed make use of Injection. With Spring 3 annotations like @Autowired and configurations like , there really is no excuse for sloppiness.
Here’s is how to reap the rewards of DI when writing unit tests. You can dependency inject each Test Class using same @Autowired annotation that you use for your normal classes.

import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({"classpath:spring-config.xml"})
public class MyClassTest {
   @Autowired
   private TransferMoneyStrategy strategy = null;
   ....
   @Test
   public void test_transfer() {
          // write Asserts here
   }
}

Key is the annotation @ContextConfiguration – one line is all you need to boot up entire Spring infrastructure!

The Java Virtual Machine debuted around 1995.  People who are old enough to remember Netscape probably remember very first Applets and claims of how embedded Java bytecode was going to change the world order and eradicate world poverty.

Poor applet died with Netscape and died again when Internet Explorer refused to bundle the JVM.

But JVM lived on and after years of optimizations, it’s probably the best Virtual Machine around. Some benchmarks give it an edge over C++  which is not hard to explain since even memory leak free C++ code suffers from memory fragmentation.  But, I’m excited again with the JVM for an entirely different reason.  While Java was better and cleaner and simpler than C++, it was still quite verbose. Dynamic Languages like Perl, Python and Ruby offered terseness and expressiveness unknown to the Java Programmers. CPUs got faster. Good Programmers got more expensive. It made sense to trade CPU time for programming time. Why waste time writing 10 lines of java code when an one liner Perl would do the same thing? Number of bugs is directly proportional to the number of lines of code. Less code is better code.  For years, the Java world (and the Microsoft world) tried to hide behind ever more complex tools like Eclipse, Netbeans and Visual Studio. Tools might be nice but they rot the programmers’ mind. They dumb  them down and provide a false sense of simplicity. Hiding a Language’s complexity behind even more complex tools is a terrible idea.

I know of many highly paid Microsoft programmers who copied Visual Studio generated DCOM code around without understanding what was it doing.  The technology was so darn complex that hardly anyone understood the guts of it.

So, why am I beginning to like Java again?

It’s not really the Java Language itself. It’s the new crop of JVM based higher level languages that have cropped up recently, that make me believe in this Virtual Machine again.  Take a look at Scala, Groovy and JRuby. All based on the JVM and all are modern languages with the same expressiveness that I’ve come to like in Ruby and Perl. Best of all, these langauges conform to the Java bytecode! The entire Java Library is instantly available to these languages. No need to wait for your favorite Java Library to get ported to any of these.  Given the fact that almost every library has already been ported to Java, it means, you can have your cake and eat it too.

Ruby is beautiful and fast moving. But Scala is beautiful, fast moving and is super rich with libraries!

Finally, we can truly start using the right tool for the job.

The pervasiveness of JVM means truly mobile code is now a possibility.  Imagine code snippets written in Plain Old Java and Scala and Groovy and JRuby being shipped over the Internet for remote execution! Netscape and Applets live on!!