At the end of this post you will be able to perform an http call to the Google Geocoding API (http://code.google.com/apis/maps/documentation/geocoding) providing an address as a parameter, parse the result with Jackson and retrieve the coordinates of that point. Personally I was surprised how simple Jackson can be.

Jackson provide three alternative methods to get what you want

• Streaming API: reads and writes JSON content as discrete events.
• Tree Model: provides a mutable in-memory tree representation of a JSON document.
• Data Binding: converts JSON to and from POJOs based either on property accessor conventions or annotations.

In my situation I simply needed to parse the JSON response and retrieve the two values for the coordinates. These values are in fixed positions in the JSON. In the beginning I was tempted to go for a Data Binding approach, but at a second glance the needed to create a java object mapping all the json structure did not result very attractive. Needing to retrieve only to values from the whole JSON the Tree Model approach is the one which suits the best. You will see here below how quick it is.

First of all, here below the two dependencies you should put in the pom of your project. Please note that the jackson libraries are very light and have zero dependencies, they rely only on the JDK. Check the Jackson website which is the last version released; in the moment when this blog post was written it was the 1.7.4. The Jackson dependencies are provided with two possible licenses: LGPL and ASL. Choose the one that better suits your project.

<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-core-asl</artifactId>
<version>1.7.4</version>
</dependency>

<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-asl</artifactId>
<version>1.7.4</version>
</dependency>

At this point have a look to an example of google geocode service response at http://code.google.com/apis/maps/documentation/geocoding/#GeocodingResponses. The fields we will retrieve are ‘lat’ and ‘lng’ and they are in the subnode ROOT -> results -> address_components -> geometry -> location.

The code here below will perform an http request to the google geocode service, will feed the resulting InputStreamReader to the Jackson ObjectMapper and will browse the nodes till the one we are interested in. The great thing is we do not need to go through every single node till we reach the node we are interested in. We can simply perform a call rootNode.findValue(“location”) and this will look up the node in the descendents of the root, not only in children. This will free us to specify the complete path and will make our code very flexible. The format of JSON we are computing can change, but our code will keep on working till the location node will be a descendent of the root, no matter where it will be placed exactly.

URL googleMapsUrl = new URL("http://maps.googleapis.com/maps/api/geocode/json?sensor=false&address=" + URLEncoder.encode(address, "UTF-8"));
URLConnection connection = googleMapsUrl.openConnection();
InputStreamReader inputStreamReader = new InputStreamReader(connection.getInputStream(), "UTF-8");

ObjectMapper mapper = new ObjectMapper();
JsonNode rootNode = mapper.readValue(getGoogleInputStream(address), JsonNode.class);
JsonNode locationNode = rootNode.findValue("location");
String latitude = locationNode.findValue("lat").toString();
String longitude = locationNode.findValue("lng").toString();

Please note this is not at all production ready code, it is simply a set of instructions relevant for the example I collected from here and there from different methods, only to give you an idea about the actions to be performed. Make sure all possible exceptions are catched and refactor the code more conveniently in different methods.

A final note: if you are planning to use the Google Geocoding API please note that there are some usage limits. From the google website you can read that the use of the Google Geocoding API is subject to a query limit of 2,500 geolocation requests per day. If you wish to have more requests at your disposal you will have to upgrade to Google Maps API Premier.

The tag I am referring to is the c:catch in the JSTL core library. This permits to simulate the classical try-catch blocks speaking in java terms. When you use in your JSP’s only JSTL tags it is maybe not so likely to incur in exceptions (at least if you do not divide by 0 or something like that …); but if you are using third party tags libraries you might encounter situations where you need to foresee the happening of an exception and prevent this to break the execution of your JSP. Once you know the exception can happen you can simply wrap it in a c:catch block and use the variable generated to perform the

Here below a snippet of the easiest situation you might face. Wrap your ‘dangerous code’ with a c:catch tag (which is the corresponding of the try section in java) and define the variable which will contain the potential Exception. If the variable will result to be null you will know that no exception occurred and you can go ahead with the execution of the standard code. Otherwise you might want to execute the alternative code (the equivalent of the code contained in the catch section in java)

<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>

<c:catch var="signalException">
  Dangerous code
</c:catch>

<c:choose>
  <c:when test="${signalException == null}">
    Exception occurs - Execute code block A
  </c:when>
  <c:otherwise>
    No Exception  - Execute code block B
  </c:otherwise>
</c:choose>

Simply compile and deploy the web application modules to the Tomcat server. When starting up the server use the parameter jpda; by doing that it will be started up in debug mode. The command to launch from the bin directory will be the following:

./catalina.sh jpda start

By doing that all the applications will run as usual but tomcat will have the debug default port 8000 waiting for possible connectors.

When the tomcat is up and running from eclipse:

Run -> Debug Configurations … and in the popup window create a new launcher for a Remote Java Application. Choose the project you want to debug, set the host to ‘localhost’ and Port to 8000 and the trick is done.

I would suggest you to refert to http://tuckey.org/urlrewrite to see how to use the tool, but in short you simply have to define the URLRewriteFilter in your web.xml

   <filter>
      <filter-name>UrlRewriteFilter</filter-name>
      <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
   </filter>
   <filter-mapping>
      <filter-name>UrlRewriteFilter</filter-name>
      <url-pattern>/*</url-pattern>
   </filter-mapping>

At this point download the sample urlrewrite.xml and put in your WEB-INF folder and the trick is done. Every time an HTTP request is performed in the domain of your web application, if the URL matches one of the rule, it will be rewritten.

Make sure of course that the tuckey jar is available in your project libraries. If yours is a Maven project just add the dependency:

   <dependency>
      <groupId>org.tuckey</groupId>
      <artifactId>urlrewritefilter</artifactId>
      <version>3.1.0</version>
   </dependency>

A constraint I found a little annoying is the fact that the filter is always expecting to find the urlrewrite.xml in the WEB-INF folder or your project. This is not very flexible, because it means that file must be in the war you deploy and therefore in order to change one of your redirect rules you will have to redeploy the whole application, or change the file inside the decompressed war in your web server. This does not seem very clear to me.

With the version 3.1.0 the org.tuckey.web.filters.urlrewrite.UrlRewriteFilter is not marked as final anymore and you can therefore extend it and you can therefore extend it and define another location where to load the configuration file from, or even load it from a remote machine. This will give you the possibility to define new rules and make them effective simply restarting the web application. Here below a simple example when you want to load the configuration file from the fixed absolute path /home/myuser/myurlrewrite.xml . In your new filter extending the org.tuckey.web.filters.urlrewrite.UrlRewriteFilter simply override the method loadUrlRewriter:

public void loadUrlRewriter(FilterConfig filterConfig) throws ServletException {
   try {
   InputStream inputStream = new FileInputStream("/home/myuser/myurlrewrite.xml");
   Conf conf1 = new Conf(filterConfig.getServletContext(), inputStream, "myurlrewrite.xml", "systemId");
   urlrewriters.add(new UrlRewriter(conf1));
   } catch (Exception e) {
      throw new ServletException(e);
   }
}

With this plugin you will be able to perform XSLT transformations with Saxon and Xalan processors and using JAXP and Xerces to parse your XML files. The way I see it, this plugin should be simply used to test some XSLT transformation you are working on. A very big constraint of the plugin is that it does not permit you to perform a certain transformation on a number of documents. When configuring a launch configuration you will have be asked to define the source file and you will not be given the possibility to define a folder for that. If you are in a situation where you have to perform XSLT transformations on a number of file I would recommend you to write some java code simply using JAXP.

I just discovered a nice tool called dropbox. It requires to install a client on your machine and permits you to share a folder of your file system. When you drag and drop a file in this particular forlder this would be automatically stored on a remote server and shared with the other machines where you installed the dropbox client.

I installed it in the Ubuntu 8.10 machine I use at work and I will install it in my laptop with Windows Vista I used at home. I still do not know if it is very convenient, but I think the idea of having the possibility of synchronizing files among different machines simply dragging and dropping them is not bad. In order to have it running you must create an account and you will be given 2 gigs available for free, which is probably enough to share the files you cannot do without.