Super Simple GWT Spring Integration

Last week I introduced the gwtrpc-spring project with an example application. Even though it was simple enough I wanted to reduce the configuration to a bare minimum. So this is example app number 2. By using auto configuration of annotated beans in spring and a naming convention for our services we can reduce the setup for a new rpc service.

To begin with when creating a new service we want to append an extension to our RemoteServiceRelativePath. So now instead of “greet” we want “greet.rpc”.

Here is our new GreetingService interface:

package org.gwtrpcspring.example.client;

import com.google.gwt.user.client.rpc.RemoteService;
import com.google.gwt.user.client.rpc.RemoteServiceRelativePath;

/**
 * The client side stub for the RPC service.
 */
@RemoteServiceRelativePath("greet.rpc")
public interface GreetingService extends RemoteService {
	String greetServer(String name);
}

Now we can change the servlet mapping in our web.xml to redirect all requests ending in .rpc to our dispatcher servlet. This means when we add a new service we don’t have to add a new mapping.

Here is our new web.xml:

<web-app>

	<!-- Default page to serve -->
	<welcome-file-list>
		<welcome-file>GwtRpcSpringExample.html</welcome-file>
	</welcome-file-list>

	<servlet>
		<servlet-name>dispatcher</servlet-name>
		<servlet-class>
			org.gwtrpcspring.RemoteServiceDispatcher
		</servlet-class>
	</servlet>

	<servlet-mapping>
		<servlet-name>dispatcher</servlet-name>
		<url-pattern>*.rpc</url-pattern>
	</servlet-mapping>

	<listener>
		<listener-class>
			org.springframework.web.context.ContextLoaderListener
		</listener-class>
	</listener>
</web-app>

We need to add annotation scanning to our spring application context. This involves adding the context: name space and adding a component-scan configuration. Here we tell spring to look in the org.gwtrpcspring.example.server package for classes that have a spring annotation. The annotation is one of the types that extend @Component, we used @Service. What this does is tell spring to automatically wire up and instantiate any classes with the annotation. In a production application I would use a package where I want all of the services i.e. org.gwtrpcspring.example.server.services so that I can be more choosy about which classes get automatically instantiated.

Here is our new applicationContext.xml notice how we no longer have to define our service bean:


<beans xmlns="http://www.springframework.org/schema/beans"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:context="http://www.springframework.org/schema/context"
         xsi:schemalocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans.xsd


http://www.springframework.org/schema/context

	 http://www.springframework.org/schema/context/spring-context.xsd">

	<context:annotation-config>

	<!-- Auto Config annotated classes in these directories -->
	<context:component-scan base-package="org.gwtrpcspring.example.server">
</context:component-scan>
</context:annotation-config></beans>

Finally, we add the annotation to the service implementation:

package org.gwtrpcspring.example.server;

import org.gwtrpcspring.RemoteServiceUtil;
import org.gwtrpcspring.example.client.GreetingService;
import org.springframework.stereotype.Service;

/**
 * The server side implementation of the RPC service.
 */
@Service
public class GreetingServiceImpl implements GreetingService {

	public String greetServer(String input) {
		String serverInfo = RemoteServiceUtil
				.getThreadLocalContext().getServerInfo();
		String userAgent = RemoteServiceUtil
				.getThreadLocalRequest().getHeader(
						"User-Agent");

		return "Hello, "
				+ input
				+ "!<br><br>I am running "
				+ serverInfo
				+ ".<br><br>It looks like you are using:<br>"
				+ userAgent;
	}
}

That’s all there is to it. Annotation driven configuration is not for everyone, some like to have all the wiring explicitly defined. But if you want simplicity then this is the simplest Spring/GWT configuration can get. You can get the source at: SimpleGwtRpcSpringExample.zip

Reblog this post [with Zemanta]

GWT and Spring – Introducing GwtRpc-Spring Project

When I started using GWT I really liked the client side javascript generation and the simplicity of the RPC service calls, however I didn?t want to give up using Spring on the server side.If you haven’t used Spring you need to. If you have, you don’t want to let go. Many of the Spring GWT solutions out there involved using Spring MVC routing and/or can be complex to setup not to mention require quite a bit of glue code. But what if you just want your RPC services to be springified? That’s why I created GwtRpcSpring. Now with GWT 1.6 it’s easier than ever. GwtRpcSpring gives you a very simple RPC request dispatcher that routes RPC server requests to your services in a Spring context. Additionally your service doesn’t have to inherit RemoteServiceServlet all it has to do is implement your remote service interface. Now existing Spring Pojo’s can be RPC services by adding an interface! Another benefit is it can be hosted on AppEngine.

To take full advantage of it you need:

You can springify the default gwt app fairly easily.

Here’s how it works:

  1. Create a new GWT Project in Eclipse.
  2. Add the gwtrpc-spring jar to your /war/WEB-INF/lib directory
  3. Add the spring jars to to your /war/WEB-INF/lib directory (i.e. spring-core.jar, spring-beans.jar, spring-context.jar and spring-web.jar)
  4. Edit your web.xml to add:
    1. The dispatcher servlet
    2. The context listener
    3. And servlet-mappings for each service to the dispatcher
  5. Create an applicationContext.xml with your services defined.

Your web.xml should look like:




<web-app>

  <!-- Default page to serve -->
  <welcome-file-list>
    <welcome-file>GwtRpcSpringExample.html</welcome-file>
  </welcome-file-list>
  
	<servlet>
		<servlet-name>dispatcher</servlet-name>
		<servlet-class>
			org.gwtrpcspring.RemoteServiceDispatcher
		</servlet-class>
	</servlet>
  
  <servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/gwtrpcspringexample/greet</url-pattern>
  </servlet-mapping>
  
  	<listener>
		<listener-class>
			org.springframework.web.context.ContextLoaderListener
		</listener-class>
	</listener>
  
</web-app>

Your applicationContext.xml:


<beans xmlns="http://www.springframework.org/schema/beans" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemalocation="http://www.springframework.org/schema/beans
  http://www.springframework.org/schema/beans/spring-beans.xsd">

	<bean id="greetService" class="org.gwtrpcspring.example.server.GreetingServiceImpl">
	</bean>

</beans>

Your Service then looks like:

package org.gwtrpcspring.example.server;

import org.gwtrpcspring.RemoteServiceUtil;
import org.gwtrpcspring.example.client.GreetingService;

/**
 * The server side implementation of the RPC service.
 */
public class GreetingServiceImpl implements GreetingService {

	public String greetServer(String input) {
		String serverInfo = 
                   RemoteServiceUtil.getThreadLocalContext().getServerInfo();
		String userAgent = 
                   RemoteServiceUtil.getThreadLocalRequest()
                        .getHeader("User-Agent");

		return "Hello, " + input + "!<br><br>I am running " 
                   + serverInfo + ".<br><br>It looks like you are using:<br>" 
                   + userAgent;
	}
}

That’s all there is to it. Now any existing spring services can be exposed as Gwt Rpc services.

The code for the example can be found here.

Reblog this post [with Zemanta]

Another Meatball Sundae

I?ve been reading “Meatball Sundae” by Seth Godin. It’s a great read on how the rules of marketing have changed, how traditional marketing groups can fail to realize it’s potential,? or worse no longer be relevant in their marketplace. The Meatball Sundae is a analogy for how organizations who believe they can add new marketing to what they are already doing. Blogging, Twitter and? Social Media are the whip cream and cherry on top. The meatballs are what the company is doing now that supports the old marketing strategy.? Whip cream, cherries and meatballs taste good on their own but together they can be a disaster. Using new marketing techniques demands a paradigm shift in how a company does business that supports and embraces the new marketing.

Agile development changes the rules in how software is delivered.? It demands a paradigm shift to be truly effective.? It means a change in how requirements are gathered, how a project is planned and reported, how design happens and how the product is tested.Like new marketing it’s not something that can be added to what an organization is already doing. An organization that tries Agile without committing to the changes needed to support will not see the true benefit. If they try to add it to a traditional SDLC (software development process) requiring upfront requirements and design, seperate qa testing teams and inflexible planning then all you have is another “Meatball Sundae”.

Reblog this post [with Zemanta]
Easy AdSense by Unreal