Die Konferenz für Java, Enterprise Architekturen & SOA

Die W-JAX ist die Konferenz für ganzheitliches technisches Know-how im Enterprise- und Webumfeld. Hier kommen die besten Experten Europas zusammen, um ihr Wissen und ihre Erfahrung an die Teilnehmer weiterzugeben. Durch ihren einzigartigen Mix an Themen verleiht die W-JAX alljährlich der Java Enterprise [...]]]>
W-JAX 2009

Die Konferenz für Java, Enterprise Architekturen & SOA

Die W-JAX ist die Konferenz für ganzheitliches technisches Know-how im Enterprise- und Webumfeld. Hier kommen die besten Experten Europas zusammen, um ihr Wissen und ihre Erfahrung an die Teilnehmer weiterzugeben. Durch ihren einzigartigen Mix an Themen verleiht die W-JAX alljährlich der Java Enterprise Community die entscheidenden Impulse.

Google Web Toolkit – Making a Better Web 2.0
Speaker: Papick G. Taboada

Mit Adwords und Google Wave sind die ersten großen GWT basierten Anwendungen von Google erschienen. Mit einem optimierenden Kompiler und pfiffige Codegeneratoren werden mit GWT maßgeschneiderte JavaScript Anwendungen erstellt, die Entwicklung findet allerdings in Java statt. In dem Vortrag werden Konzepte, Neuigkeiten aus 2.0 und die aus Adwords gewonnenen Architektur “Best Practices” vorgestellt.

SpringSource dm Server: Fitness für die Webanwendungen
Speaker: Agim Emruli, Papick G. Taboada

Java-EE-Webanwendungen tragen Deployment-bedingt eine große Menge an Bibliotheken mit sich. Mit OSGi werden dank einem standardisierten Modularisierungskonzept neue Wege gegangen. Lernen Sie in der Session die Möglichkeiten der Modularisierung in Java-EE-Webanwendungen auf dem OSS SpringSource dm Server kennen, damit schwergewichtige und monolithische Deployments der Vergangenheit angehören.

EDA in der Businessintegration
Speaker: Christian Dedek, Papick G. Taboada

Integrationsszenarien mit ereignisgesteuerten Architekturansätzen in Java umsetzen? Dieser Vortrag bietet Ihnen eine Einführung in EDA und Complex Event Processing (CEP) und stellt den Zusammenhang zwischen EDA und SOA her. Darüber hinaus veranschaulicht er die Architektur und den Aufbau von Esper und zeigt CEP-Einsatzszenarien.

Google Web Toolkit Architecture: Best Practices for Architecting your GWT App

A common question people ask is how to architect a GWT app. Ray Ryan discusses real-world learnings and patterns from the Google AdWords team and [...]]]> Just in case you haven’t seen it yet: there is very interesting talk from Ray Ryan available online:

Google Web Toolkit Architecture: Best Practices for Architecting your GWT App

A common question people ask is how to architect a GWT app. Ray Ryan discusses real-world learnings and patterns from the Google AdWords team and elsewhere which you can use in your apps.

While dependency injection on the client side in general is nothing new, having it on a GWT application (I mean on the client) is something a little harder to setup. Since we don’t have reflection and dynamic proxies… But GWT provides an alternative called deferred binding, and there is a project called Gin providing the Guice DI approach for GWT apps.

There are some other projects like gwt-dispatch and gwt-presenter that where created inspired by Ray Ryans talk.

So if you are doing or planning GWT development, have a look at the video and the following projects:

• gwt-dispatch: Inspired by Ray Ryan’s Best Practices For Architecting Your GWT App session at Google I/O 2009, this is an implementation of the ‘command pattern’ discussed at the beginning of the video.
• gwt-presenter: Inspired by Ray Ryan’s Best Practices For Architecting Your GWT App session at Google I/O 2009, this is an implementation of the ‘Presenter’ part of the Model-View-Presenter (MVP) design pattern discussed in the video.
• google-gin: GIN (GWT INjection) brings automatic dependency injection to Google Web Toolkit client-side code. GIN is built on top of Guice and uses (a subset of) Guice’s binding language. By using GWT’s compile-time Generator support, GIN has little-to-no runtime overhead compared to manual DI.

If you are looking for an easy approach to use Spring in the backend with the gwt-dispatch project have a look at this posting:

• Use Spring with GWT dispatch

If you are looking for a simple and concise approach to use autowire your Gwt-RPC servlets with components from the Spring application context, have a look at this posting:

• Non invasive GWT and Spring integration (reloaded)

[update]

• mvp4g: all-in-one approach providing annotation based Event Bus, Dependency Injection, Model View Presenter, Place Service

[/update]

Inspired by Ray Ryan’s Best Practices For Architecting Your GWT App session at Google I/O 2009, “gwt dispatch” is an implementation of the ‘command pattern’ discussed at the beginning of the video.

The project uses Gin in the frontend and Guice in the backend. Guice defines a very [...]]]> From the GWT dispatch site:

Inspired by Ray Ryan’s Best Practices For Architecting Your GWT App session at Google I/O 2009, “gwt dispatch” is an implementation of the ‘command pattern’ discussed at the beginning of the video.

The project uses Gin in the frontend and Guice in the backend. Guice defines a very nice dependency injection framework, and as such, competes partially with the Springframework. But the Springframework is by far more than dependency injection, and I don’t want to miss any of its features in the backend.

So I took a look at the gwt dispatch sources, and decided to use Spring to setup the server side of the dispatch service. GWT dispatch extensively uses constructor injection. This works perfectly with Spring, but not with plain servlets. So I needed to rewrite the DispatchServiceServlet a little…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

public class StandardDispatchServiceServlet extends RemoteServiceServlet
		implements DispatchService {
 
	private Dispatch dispatch;
 
	@Override
	public void init(ServletConfig config) throws ServletException {
		super.init(config);
		WebApplicationContext ctx = WebApplicationContextUtils
				.getRequiredWebApplicationContext(config.getServletContext());
		AutowireCapableBeanFactory beanFactory = ctx
				.getAutowireCapableBeanFactory();
		beanFactory.autowireBean(this);
	}
 
	public Result execute(Action<?> action) throws ActionException {
		try {
			return dispatch.execute(action);
		} catch (RuntimeException e) {
			log("Exception while executing " + action.getClass().getName()
					+ ": " + e.getMessage(), e);
			throw e;
		}
	}
 
	@Autowired
	@Required
	public void setDispatch(Dispatch dispatch) {
		this.dispatch = dispatch;
	}
}

Instead of using constructor injection, I use setter injection. This way the servlet can be simply added to the web.xml. The servlet lifecycle initializes servlets before they are service-ready. I use the initialization callback method to autowire the servlet instance.

Here is my web.xml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

<web-app>
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/spring-conf.xml</param-value>
	</context-param>
	<context-param>
		<param-name>log4jConfigLocation</param-name>
		<param-value>/WEB-INF/log4j.xml</param-value>
	</context-param>
	<listener>
		<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
	</listener>
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>
 
 
	<!-- Servlets -->
	<servlet>
		<servlet-name>dispatchServlet</servlet-name>
		<servlet-class>x.y.gwt.hellospringdispatch.server.support.StandardDispatchServiceServlet</servlet-class>
	</servlet>
 
	<servlet-mapping>
		<servlet-name>dispatchServlet</servlet-name>
		<url-pattern>/hellospringdispatch/dispatch</url-pattern>
	</servlet-mapping>
 
	<!-- Default page to serve -->
	<welcome-file-list>
		<welcome-file>HelloSpringDispatch.html</welcome-file>
	</welcome-file-list>
 
</web-app>

I am using annotation based configuration in my project, so the spring configuration file is very concise:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?xml version="1.0" encoding="UTF-8"?>
<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-2.5.xsd
         http://www.springframework.org/schema/context  http://www.springframework.org/schema/context/spring-context-2.5.xsd
    "
	>
 
	<context:annotation-config />
	<context:component-scan base-package="x.y.gwt.hellospringdispatch.server" />
 
</beans>

The component scan will add any properly annotated class to the spring application context. Obviously, the classes in the GWT dispatch project are not properly annotated. So I created the classes in my projects that are needed by the DispatchService implementation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import net.customware.gwt.dispatch.server.ActionHandlerRegistry;
import net.customware.gwt.dispatch.server.DefaultDispatch;
 
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
 
@Component
public class DispatchBean extends DefaultDispatch {
 
	@Autowired
	public DispatchBean(ActionHandlerRegistry handlerRegistry) {
		super(handlerRegistry);
	}
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

import java.util.List;
 
import net.customware.gwt.dispatch.server.ActionHandler;
import net.customware.gwt.dispatch.server.DefaultActionHandlerRegistry;
 
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
 
@Component
public class ActionHandlerRegistryBean extends DefaultActionHandlerRegistry {
 
	@Autowired
	public void setHandlers(List<ActionHandler<?, ?>> handlers) {
		for (ActionHandler<?, ?> actionHandler : handlers) {
			addHandler(actionHandler);
		}
	}
}

The action handler registry is the place where the ActionHandlers are kept. I used the collection autowire feature to get a list of all handlers registered in the Spring application context.

The last step is to add ActionHandlers to the Spring context. For obvious reasons I prefer to keep my action handlers “Spring free” – that’s why I created my own annotation to identify action handlers:

1
2
3
4
5
6
7
8
9
10

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
 
import org.springframework.stereotype.Component;
 
@Component
@Retention(RetentionPolicy.RUNTIME)
public @interface ActionHandlerBean {
 
}

I am not sure if I need to setup the retention policy – I should have a look at that…

All I need to do now is to add handlers to any package below the server package. The Spring component scan will automatically find the handlers and add them to the Spring application context and further inject them to the handler registry.

Here is a simple ActionHandler:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

import net.customware.gwt.dispatch.server.ActionHandler;
import net.customware.gwt.dispatch.server.ExecutionContext;
import net.customware.gwt.dispatch.shared.ActionException;
 
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Required;
 
import x.y.gwt.hellospringdispatch.server.support.ActionHandlerBean;
import x.y.gwt.hellospringdispatch.shared.SendGreeting;
import x.y.gwt.hellospringdispatch.shared.SendGreetingResult;
 
@ActionHandlerBean
public class SendGreetingHandler implements
		ActionHandler<SendGreeting, SendGreetingResult> {
 
	public SendGreetingHandler() {
	}
 
	public SendGreetingResult execute(final SendGreeting action,
			final ExecutionContext context) throws ActionException {
		final String name = action.getName();
		try {
			return new SendGreetingResult(name, "Hello from the server");
		} catch (Exception cause) {
			throw new ActionException(cause);
		}
	}
 
	public void rollback(final SendGreeting action,
			final SendGreetingResult result, final ExecutionContext context)
			throws ActionException {
		// Nothing to do here
	}
 
	public Class<SendGreeting> getActionType() {
		return SendGreeting.class;
	}
 
//	
//	@Autowired
//	@Required
//	public void setCustomerService(CustomerService gibher) {
//
//	}
//
 
}

I am very happy with this approach as it allows me to add new action (command) handlers without any configuration overhead. Simply dropping the implementation somewhere in the server package will do all the magic.

Here is my overdue update to my Non invasive GWT and Spring integration blog post from early 2008. Since then we have had the GWT 1.6 and GWT 1.7 releases: One of the biggest changes to GWT 1.6 is a new project structure. The old output format has been replaced [...]]]>

New project layout

Here is my overdue update to my Non invasive GWT and Spring integration blog post from early 2008. Since then we have had the GWT 1.6 and GWT 1.7 releases:

One of the biggest changes to GWT 1.6 is a new project structure. The old output format has been replaced by the standard Java web app "expanded war" format, and the actual directory name does default to "/war". Note that the war directory is not only for compiler output; it is also intended to contain handwritten static resources that you want to be included in your webapp alongside GWT modules (that is, things you'd want to version control).

As a matter of fact, now we finally can (must) manage the web.xml file ourselves:

Projects with server-side code (GWT RPC) must configure a web.xml file at /war/WEB-INF/web.xml. This web.xml file must define and publish any servlets associated with the web application.

This is a little pain for really much gain, and that's why I am writing this post after all...

Starting a Springframework ApplicationContext in a Java EE compiient web-application is well known and documented in the Springframework reference:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">
 
<web-app>
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/spring-conf.xml</param-value>
	</context-param>
	<context-param>
		<param-name>log4jConfigLocation</param-name>
		<param-value>/WEB-INF/log4j.xml</param-value>
	</context-param>
	<listener>
		<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
	</listener>
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>
 
	<!-- Servlets... -->
 
	<!-- Default page to serve.. -->
 
 
</web-app>

There aren't many beans in my spring configuration files as I am using annotation based configuration in my apps. Here a sample spring confuguration taken from one of my sample projects:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?xml version="1.0" encoding="UTF-8"?>
<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-2.5.xsd
         http://www.springframework.org/schema/context  http://www.springframework.org/schema/context/spring-context-2.5.xsd
    "
	>
 
	<context:annotation-config />
	<context:component-scan base-package="x.y.gwt.hellospring.server" />
 
	<bean id="basicTextEncryptor" class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
		<property name="algorithm" value="PBEWithMD5AndDES" />
		<property name="keyObtentionIterations" value="1000" />
		<property name="password" value="s0990w8eh0c8hf08aefh8hGf9egf9aefea8f" />
	</bean>
 
</beans>

So this is (despite of the missing log4j.xml config) the configuration setup I am using on GWT 1.6 and GWT 1.7 projects in order to bootstrap an application context.

The next step is to implement the dependency injection of spring managed beans into my GWT RPC serverside implementation. I will be using the annotation based config provided by the Springframework.

This is how the dependency injection in my GWT RPC services looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

/**
 * The server side implementation of the RPC service.
 */
@SuppressWarnings("serial")
public class EncodingServiceImpl 
extends AutoinjectingRemoteServiceServlet
implements EncodingService {
 
	private IEncodingService encodingService;
 
	@Autowired
	@Required
	public void setEncodingService(IEncodingService encodingService) {
		this.encodingService = encodingService;
	}
 
	// Service implementation ommited here...
 
}

EncodingServiceImpl is the server side GWt RPC implementation, while EncodingService is the GWT service I am setting up. The managed bean in my spring configuration implements IEncodingService (and uses the great jasypt lib). I am using the annotations to configure the dependency injection.

All I have to do now, is "autowire" my RPC servlet during initialization. Since this is not going to be the only GWT RPC service needing dependency injection I introduced the AutoinjectingRemoteServiceServlet class:

1
2
3
4
5
6
7
8
9
10
11
12
13

public class AutoinjectingRemoteServiceServlet extends RemoteServiceServlet {
 
	@Override
	public void init(ServletConfig config) throws ServletException {
		super.init(config);
		WebApplicationContext ctx = WebApplicationContextUtils
				.getRequiredWebApplicationContext(config.getServletContext());
		AutowireCapableBeanFactory beanFactory = ctx
				.getAutowireCapableBeanFactory();
		beanFactory.autowireBean(this);
	}
 
}

There is not much to say about this class. During the initializiation of the RPC Servlet (remember: GWT uses servlets as the foundation technology on the server side implementation of GWT RPC. Being so, the GWT RPC service implementation "lives" in the same lifecycle as any other servlet. I am using the initialization step to get a reference to the ApplicationContext. After that I use the autowire bean method to autowire the servlet automatically.

If you prefer to directly expose spring beans, you should have a look at http://code.google.com/p/spring4gwt/. ]]> http://pgt.de/2009/07/17/non-invasive-gwt-and-spring-integration-reloaded/feed/ 15 http://pgt.de/2009/05/12/multichannel-communication-and-social-networking/ http://pgt.de/2009/05/12/multichannel-communication-and-social-networking/#comments Tue, 12 May 2009 13:17:35 +0000 P.G.Taboada http://pgt.de/?p=344 networking #rulez

es ging bei Skype los:

[12.05.09 12:19:46] Falk Sippach: hast du eine idee, wie ich die komplette springide als zip runterladen kann
[12.05.09 12:20:07] Falk Sippach: ich finde nur den link auf die update-site

Ich Google mich also auf folgenden Blog-Posting:

http://blog.springsource.com/2009/05/07/springsource-tool-suite-now-free/

wo ich folgende Stelle finde:

Speaking about interaction with the team, I’d like to encourage every Spring developer and Tomcat user out there to download STS, give it a try and get involved in the community through our forums, JIRA, Twitter (#STS) and email (sts AT springsource DOT com). As a user you can now actively influence where STS is heading and what would be of value to you. Furthermore you don’t need to spend time figuring where to get certain tooling features or what the differences between Spring IDE and STS are.

Da ich Christian Dupuis ja nur “ein bisschen” kenne (#speakerslounge #jax09), habe ich keinen #Skype Kontakt von ihm.

Tja, aber Christian ist ja auf dem Weg zu Juergen Hoeller

https://twitter.com/cdupuis/status/1770496144

Juergen habe ich in meiner Kontaktliste in Skype, ist aber leider offline, social-network-Sackgasse…

Also habe ich ihn @cdupius “angeTwittert”:

https://twitter.com/pgtaboada/statuses/1772196266

woraufhin ich auch prompt eine Antwort bekommen habe:

https://twitter.com/cdupuis/statuses/1772514228

Natürlich habe ich mich gleich bedankt und dabei auch Jürgen gegrüsst #networking

http://twitter.com/pgtaboada/status/1772918127

Und die wertvolle Info gleich per Skype an Falk weitergegeben:

[12.05.09 14:42:51] Papick G. Taboada: https://twitter.com/cdupuis/statuses/1772514228
[12.05.09 14:42:53] Papick G. Taboada: here we go
[12.05.09 14:42:54] Papick G. Taboada: :-)
[12.05.09 14:43:16] Falk Sippach: danke
[12.05.09 14:43:23] Falk Sippach: habs bereits runtergeladen
[12.05.09 14:43:36] Papick G. Taboada: :-)

Ist nicht nur ein Spielzeug…

:-)

That’s why I do not agree entirely with the label “parasites”. It is not easy to offer support, [...]]]>

Ok, someone is making money with support.
Ok, someone is not contributing to OSS.
But wait – is offering support not exactly that? Contributing to OSS by doing the dirty work no one wants to do?

That’s why I do not agree entirely with the label “parasites”. It is not easy to offer support, IMHO it is a Job that no one likes to do. I don’t know if it is true for everyone – but I am very happy to be a developer and not to be a support guy.

It just happens that it is exactly this job is actually needed, and hence, can be monetized.

• Don’t tell me that those few developers really contributing to an OSS project have time to provide support as it is required today.
• Don’t tell me that somebody not contributing is not capable to offer support. If you really believe that, you don’t understand what it means to offer support.
• Don’t tell me that developers can offer better support.

So even if all OSS developers start working 24h a day (I am sure many already do) – would they be supply enough service to cover the demand? How many people do need support, now many contributors do we have?

I remember reading somewhere on a OSS page:  “great support by the community”. What does this mean? Easy to tell: we can’t or we won’t offer support.

I believe that neither Spring nor any other OSS product would have come that far without the many consultants and supporters we have working very hard today. So someone is monetizing support? Fine! It will open the doors for enterprise OSS acceptance. Is someone offering training for OSS technologies? GREAT!

Does it feel like it is stealing work? No it is not.

Sure – we live in interesting times. Don’t have a working business plan for your successfull OSS product? I tell you what: go offer support for it. But be warned: it is hard work, it is mostly badly payed, it does not scale, and you will stop working with computers and start working with people.

Good luck!

GWT and JSF….

http://www.indeed.com/jobtrends?q=gwt%2C+jsf&l=

http://www.google.com/trends?q=GWT%2C+JSF&ctab=0&geo=all&date=all&sort=0

http://markmail.org/

Unfortunately markmail does not support comparison, you will have to do it by hand.

Obviously I am not the only one looking for a way to integrate my Spring backend into some GWiT application. After searching for a while I didn’t find any suiting solution. There are [...]]]> [update]
If you are working with GWT 1.6, you probably would like to have a look at this here:
http://pgt.de/2009/07/17/non-invasive-gwt-and-spring-integration-reloaded/
[update]

Obviously I am not the only one looking for a way to integrate my Spring backend into some GWiT application. After searching for a while I didn’t find any suiting solution. There are some interesting approaches (like GWT Widget Library SL and using the maven plugin), but being new to GWiT I did not want to give up the GWiT Development Shell neither the embeded Tomcat. I wanted the integration to be less invasive as possible.

So here is what I did…

First problem I had to solve was how to get my configuration elements into the tomcat configuration. I needed to add some listeners to the web.xml (e.g. to start the Spring container and Acegi security):

Here is a snippet from my web.xml showing how to use the listeners provided by the Spring Framework to start an application context and to configure log4j properly:

(...)
...)
 
log4jConfigLocation
/WEB-INF/log4j.xml
 
contextConfigLocation
classpath:/META-INF/spring-conf.xml
 
			org.springframework.web.util.Log4jConfigListener
 
			org.springframework.web.context.ContextLoaderListener
 
			org.springframework.web.context.request.RequestContextListener
 
(...)

GWiT does not provide any extension point for custom configuration, so I had to add the configuration elements directly to the provided Tomcat web.xml. I cannot make changes to the web.xml in the ROOT web application, since this web.xml is re-generated by GWiT every time the Development Shell is started. Fortunately, the default web.xml stored in the “conf” directory of the embedded Tomcat is generated only one. So I found some place to add my configuration elements. Unfortunately the configuration there is not reusable, so I am having double configuration here: configuration for the development and configuration for the deployment.

Next, I wanted to easily have access to my Spring beans. JSF developers have a variable resolver and have access to their Spring beans for free. I wanted that too. Again, being new to GWiT, I didn’t want to loose the features provided by the IDE (Eclipse + GWT-Designer in this case). It is nice to simply say “add new remote service” in the IDE and get everything wired out of the box. For different reasons I do want to expose my Spring beans automatically to the GWiT application. JSF developers have the services for free at the SERVER SIDE: the services do not get exposed via RPC automatically. I wanted something similar: my GWiT remote service implementation should have access to the Spring backend for free without exposing anything automatically.

I wanted some sort of dependency injection. Since the servlets are managed by the servlet container and the servlet container does not know anything about dependeny injection of Spring beans into servlets I had to do it myself.

First, I needed some sort of markup to identify what to inject. I was using JDK 5 syntax on none client sources, so I used an annotation. I could also have used some marker interface for my services, but I found this to be to invasive, I did not touch my backend files.

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
 
/**
 * Annotation used to flag auto injection.
 */
@Retention(RetentionPolicy.RUNTIME)
@Target(value = ElementType.METHOD)
public @interface AutoInject {
 
}

All I wanted to do is to add this annotation to my setter methods in my GWiT remote service implementations. So I extended the RemoteServiceServlet provided by GWiT and implemented the auto injection.

import java.lang.reflect.Method;
 
import javax.servlet.ServletException;
 
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.context.WebApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;
 
import com.google.gwt.user.server.rpc.RemoteServiceServlet;
 
/**
 * Provides automatic injection into GWT services. Only setter methods with exactly one parameter and
 * annotated with AutoInject will be considered for auto injection.
 *
 */
public abstract class AutoInjectingRemoteServiceServlet extends RemoteServiceServlet {
 
    /**
     * Logger.
     */
    private static final Logger LOG = LoggerFactory.getLogger(AutoInjectingRemoteServiceServlet.class);
 
    /** Reference for the WebApplicationContext. */
    private WebApplicationContext ctx;
 
    /**
     * {@inheritDoc}
     */
    @Override
    public void init() throws ServletException {
        LOG.debug("Initializing servlet");
        super.init();
        LOG.debug("Get reference to the Spring Application Context");
        ctx = WebApplicationContextUtils.getWebApplicationContext(this.getServletContext());
        System.out.println(ctx);
        LOG.debug("Spring ctx with: {} beans.", ctx.getBeanDefinitionCount());
        this.populateVariables();
    }
 
    /**
     * Performs auto injection on this servlet instance.
     */
    @SuppressWarnings("unchecked")
    private void populateVariables() {
        LOG.debug("Start servlet auto injection");
        Method[] methods = this.getClass().getMethods();
        for (int i = 0; i < methods.length; i++) {
            Method method = methods[i];
 
            if (method.getName().startsWith("set") && method.isAnnotationPresent(AutoInject.class)
                    && method.getParameterTypes().length == 1) {
                Class type = method.getParameterTypes()[0];
                LOG.debug("Looking for: {}", type);
                String[] beanNamesForType = ctx.getBeanNamesForType(type, false, true);
                LOG.debug("Got {} with {} elements", beanNamesForType, beanNamesForType.length);
                if (beanNamesForType.length != 1) {
                    LOG.error("There is no bean of type {} for autoinjection", type.toString());
                } else {
                    try {
                        method.invoke(this, ctx.getBean(beanNamesForType[0]));
                        LOG.info("Injected bean: {} on field {} ", beanNamesForType[0], this.getClass().getName());
                    } catch (Throwable e) {
                        LOG.error("Error: could not inject into " + "protected variable {}, cause: {}", method.getName(), e
                                .getMessage());
                        if (LOG.isDebugEnabled()) {
                            e.printStackTrace();
                        }
                    }
                }
            }
        }
    }
}

In short: in the initialization of the servlet I pickup the Spring application context and do the injection for all setter methods annotated.

In the following GWiT remote service implementation I use this injection to get access to my Spring login service (that itself uses acegi, the user DAO and a session scoped bean):

public class GwtLoginServiceImpl extends AutoInjectingRemoteServiceServlet implements GwtLoginService {
 
	private ILoginService loginService;
 
	@AutoInject
	public void setLogService(ILoginService loginService) {
		this.loginService = loginService;
	}
 
	@Override
	public LoginResult doLogin(String username, String password) {
		LoginResult result = new LoginResult();
		try {
			result.loggedInUser = loginService.doLogin(username, password);
			result.successFull = true;
		} catch (BadCredentialsException bce) {
			result.successFull = false;
			result.errorMessage = "Bad credentials.";
		} catch (Throwable t) {
			result.successFull = false;
			result.errorMessage = "Server error.";
		}
		return result;
	}
 
	@Override
	public UserDTO isLoggedIn() {
		return loginService.isLoggedIn();
	}
 
	@Override
	public void doLogout() {
		loginService.doLogout();
	}
}

While this leads to a lot of delegation code, I am still happy with the layer separation and the easy usage.

When playing with GWiT 1.5 (build from the trunk) a few weeks ago, I noticed that GWiT started overriding the web.xml in the embeded Tomcat configuration directory. I just thought “oh no!”, but next thing I noticed was that it stopped overriding the application web.xml in the ROOT webapps folder. Let’s see if it stays this way…

GWT changes the way we develop [...]]]> I am on the train to Munique on my way to the OOP 2008. Today I spent some time refactoring a GWT application (we are moving to GWT 1.5 built from the svn trunk) and thought I could use the travel time to post about GWT and Acegi.

GWT changes the way we develop internet applications. The web application is not only rich, but it also runs standalone in the client browser. Shortly spoken, a GWT application is a statically loaded set of html, css and javascript files. No serverside web technology gets touched in this process. The webserver delivering the files does not count here… Once the application starts running on the browser, it will start loading data from the server using http requests. This data will further on be displayed in the browser by the GWT application. An application delivered in Javascript is a security nightmare, since the code on the client side is readable and can be easily manipulated.

There are mainly two aspects in a GWT application scenario that might be secured:

- the GWT application
- the RPC services offered by the server

Securing the GWT application is an impossible task. It is possibe to only give access to the Javascript application after the user has identified itself, but once the Javascript code gets transfered to the client there is nothing that can be done to avoid manipulation.

Securing the RPC services offerend by the server is by far much more easier. Assuming the server is written in Java, there are many ways to secure the services offered: services in the GWT are RPC are implemented by Servlets. Restricting access to the servlets would do the job quite efficiently.

The approach described here does not try to hide the GWT application from the world. The application cannot be secured in the browser and, in many cases, it is the data and the serverside actions that must be secured. A GWT application that cannot connect to its RPC services because of bad credentials is useless. If the application algorithm is worth securing, then hiding the application is the best option available. Unfortunately, this cannot be done with GWT, it would be like a dog trying to bite it’s own tail. After all, the user must identify itself before, and then the application can be dowloaded to the browser. GWT does not known anything about lazy loading parts of an application at runtime. A simple way to implement hiding the application is to host the application in a JSP page ahd have this page secured. Not only the JSP must be secured, but also all static files composing the GWT application. Only after authentication succeeds, the JSP page can be accessed, bootstraping the Javascript application. The JSP should create a server session with the provided credentials, the GWT application would use RPC to gain access to this information and to know who has logged in. This is a server side approach, and here is where I tend to use Acegi.

Acegi is a very interesting Java security framework. It is often used with Spring and with web applications, but it also can be used standalone (without Spring) and to secure any kind of Java application. With AOP techniques its usage can be non invasive to the application code.

In our project we did not hide the GWT application. First, it is an intranet application. Second, the application is useless without the RPC services and the provided data.

The idea on our approach is to download the GWT application to the browser and let the application display a modal login dialog box. The information provided by the user will then be sent to a unsecured login service on the server. The server performs the authentication through acegi, creates a server side session with the appropriate credentials.

Een if some user hacks the Javascript to bypass the login dialog, nothing will happen. The navigation tree is populated by RPC: each user has a different navigation tree, depending on user preferences, stored searches and security roles.

The login RPC call returns the login information required by the GWT application to know that a successful or unsuccessful login has occured. On a successful login, the GWT application starts loading the data needed through the secured services in the server. The server allows this services to be called because the client has created a valid server side session with apropriate credentials. Acegi will secures the services based on this information.

Finally, our GWT application checks regularly if the session has not been invalidated (or if the server is respoding at all) and performs a client-side logout if needed.

Feedback is welcome!