Skip to main content
A quick note on something that's been bugging me while using SpringSource STS with the GWT-plugin on my MacBook Pro...

Sometimes, when shutting down the internal devmode server I get an error dialog saying it wasn't able to shut down the process fully (even though it looks shut down in the console window).

When starting it again, it reports port 9997 to be in use already - and consequently fails to start up again. I haven't found a way to find the process within SpringSource STS, even though there are probably several ways of doing it (which I do not know about). Anyhow - I solved it using the "lsof" package (List Open Files).

To find the PID of the process using port 9997, type "lsof -i :9997" in a Terminal window. A simple "kill -9 <pid>" will take care of the rest.

I'm not sure if this happens on other platforms etc, but at least, now you know how to handle it if it hits you!


Popular posts from this blog

Getting filters to play nicely with Spring

After having some struggle with getting filters to integrate well with my Spring context, I decided to write down a small tutorial for it...

To begin with, filters are defined in web.xml and are therefore not automatically part of the Spring application context, which is normally set up using the DispatcherServlet. A good way to abstract away all this is to use the DelegatingFilterProxy, which is a Spring utility class that acts as a filter, but will delegate the doFilter-method to a Spring-managed bean - normally a class extending GenericFilterBean.

As a filter is defined in web.xml and looks for the bean defined in the Spring context in applicationContext.xml, it's not really the set up that I want. Filters are part of a web application and should have access to what's usually defined in webmvc-config.xml, as part of the DispatcherServlet set up. To be able to use, e.g. request scoped beans in applicationContext.xml, you need to defined them as proxied objects in order to have…

GWT and Spring Security

Update! - Based on the post below, and my other post regarding Spring Security and OpenID, I have added Open-ID support to the sample application below. For those interested, here's the write-up of changes.

I've spent quite some time digging into ways of integrating GWT and Spring Security. It all started by reading the following post in the GWT Forum - Best practices/ideas for GWT with Spring Security (or equivalent), and then checking out this blog - GWT and Spring Security. To make matters worse, I started reading Security for GWT Applications and specifically about the "Cross-Site Request Forging"-attacks.

Now, what could I do about it?

Well, starting by setting up my own project (Maven-based) with all updated dependencies (GWT 2.0.3 etc) and started reading the Spring Security Reference Documentation (puh!).

Instead of See Wah Cheng's approach of implementing a custom authentication service, I decided to rely on standard namespace configuration (with some ex…

Using SmartGWT with Jersey RESTful backend on Spring Roo

I decided to give SmartGWT a run, and specifically the RestDataSource functionality using Jersey. To make things easier, I'm using Spring Roo to set up my project and scaffold much of the boilerplate code, configurations etc.

My approach is to have my domain objects exposed as RESTful web services and create a matching SmartGWT DataSource in order to show them in a GUI.

Let's get started, shall we?

First of all, you'll need Spring Roo (unless you just download the project source code and want to run it directly). I'm using the following Roo script to start things off:

project --topLevelPackage com.technowobble persistence setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY entity --class ~.domain.Message field string --fieldName value controller class --class --preferredMapping rest dependency add --groupId com.sun.jersey --artifactId jersey-server --version 1.3 dependency add --groupId com.sun.jersey.contribs --artifactId jersey-spring --…