Posts Tagged spring

Presenting spring4speedtracer

One of the biggest “wow” moments for me at Google IO a few weeks back was seeing Google’s Speed Tracer display performance data from the server right alongside the client. I immediately downloaded a copy of Spring’s TC Server to see how they did it, and quickly realized that it’s very container-dependent: custom deployers, configuration, etc. all of which make it a really power tool for simply dropping in any web application and getting their whole performance dashboard, but difficult to use in a broader context. It seemed to me like a simpler solution could give the same great end-to-end snapshot of a request in Speed Tracer without the heavy footprint, not to mention an option for those of us with applications that simply can’t run on TC Server.

A couple days and much caffeine later, I was right! It’s become my newest Google Code project, spring4speedtracer. Not a very inspired name I know but it gets right to the point.

I spent a little time digging into the mostly undocumented Speed Tracer API an quickly learned that the key to displaying server data is just a response header on any request that it traces. If the header is present, Speed Tracer will query that URL for a JSON payload containing the additional data and display it in a tree for the user. Really all an application needs to do is bundle the data in the right format, set the expected headers, and support retrieving it via some URL.

This was enough to convince me that a simple library could be built just to take advantage of the Speed Tracer API and present server trace data without all of the other monitoring and tracking features of TC Server. I decided to drive my approach by that immediate goal: I want to see end-to-end profiles of my GWT applications in Speed Tracer where the server is a Spring application running embedded in Jetty, on JBoss using JEE features, or really anywhere else. Some minor configuration (editing web.xml or a Spring application context, and dropping in an extra jar) would be a fair tradeoff for it working in any container.

The first cut will happily trace any public method invocations on @Service or @Repository beans throughout an HTTP request and show them in Speed Tracer just like Spring Insight does. It does this with three beans and one filter: basically a repository for the trace data, an aspect to perform the trace, a writer to turn it into JSON, and the filter intercepting HTTP requests to enable the traces and publish them to Speed Tracer.

Adding spring4speedtracer to an existing project consists of adding the jar and dependencies (really just Gson since the Spring jars are probably already there!), adding the filter to web.xml, and importing the provided Spring context inside the existing one. Or, for more customization the beans can be wired in directly, possibly using extended versions that have different pointcuts determining what gets traced, integrating with a more long-running tool like Spring Insight, etc.

For some basic safety I’ve added support for toggling traces with both a Java system property and a request header, allowing it to be controlled globally at the server and/or per-client. When traces are disabled the overhead is very trivial (just a boolean check inside the aspect). I was a little worried that adding another proxy to every @Service and @Repository would cause problems, but after trying it out in a couple complex projects it’s been working fine. The main caveat I’ve seen is that it’s important to follow the AoP dynamic proxy vs. weaving conventions: if the bean has at least one interface then it’s going to get a dynamic proxy, so other beans must inject the interface, else if it’s just an implementation then it will get byte woven. But any beans lingering around with multiple interfaces and some beans still injecting the target type will break. Removing the interface or changing everything to use the interfaces fixes the problem.

The result is definitely cool. I can now pull up end-to-end Speed Tracer traces running these applications on any server! When I get time I’m hoping to add support for tracing deeper functions like JDBC operations and somehow reporting work that’s farmed out to multiple threads during a request.

, , , , ,

5 Comments

Spring4gwt, or Spring’s harmony for GWT

I’ve had an idea itching at me for awhile now, which started shortly after building a complex enterprise application using GWT connected to Spring services on the server. There are countless blogs out there describing various ways to wire up Spring with GWT, and Google’s own Gin is quite adequate for client-only dependency injection. But what I’d really like is something that ties this all together, and in the true spirit of GWT, makes it easy for a seasoned Java developer to apply proven, consistent DI practices in both the client and server using the Spring knowledge they likely already have.

My vision is basically this:

@Component
public class SomeGWTComponent {

	// Some other client-side component
	@Autowired
	private MyWidget widget;

	// A remote service proxy to a server-side Spring service
	@Autowired
	private MyService service;

	public void doSomething() {

		widget.doClientStuff();

		...

		service.doServerStuff("data", new AsyncCallback<String>() {

				public void onFailure(Throwable caught) {
					...
				}

				public void onSuccess(String result) {
					...
				}
			});
		}
	}
}

It’s important that MyService is a vanilla Spring service on the server – no extension of RemoteServlet required – and that MyWidget is any other GWT component. Injection should occur when the component is created, potentially with varying scopes just like on the server, and potentially also with @PostConstruct support for code to be executed after injection, leaving the constructor available for any pre-injection initialization. And finally, as much work as possible should be done during GWT compile minimize the run-time cost.

The approaches to GWT lookup/injection I’ve seen out there have at least one the following gaps:

  • They’re client-only (Gin)
  • They’re largely run-time, and slow (MVC helpers in component libraries like GXT)
  • They involve SpringMVC or other unnecessary server-side complexity (most blog guides)

So I’m going to try to bring this altogether in one simple library with the following goals:

  • Simplicity: Access Spring services from the client through a generic exporter; no service-specific mappings in web.xml, forced type hierarchy (services should be existing Spring POJO’s), or dependency on SpringMVC. In other words, when a new Spring service is added to the server it should require zero configuration changes to be accessible in the client if desired.
  • Consistency: Client-side dependency injection with native Spring look and feel; freedom to inject private members, via constructor, or via getters/setters with same Spring annotations and conventions that are already familiar.
  • Performance: Do all the heavy lifting with GWT generators to keep the client lean.

Behold, spring4gwt where I’ll do my best to make this a reality! The initial version captures objective #1, bringing together a generic servlet for exposing Spring services without turning each into its own RemoteServlet mapped in web.xml. Up next: accessing those services with Spring DI in the client!

, , , ,

13 Comments