images images images

Ceres Logic is proud to announce the follow-up to its first Android application, Tidecast, with Skicast.

Skicast screenshot Sunday River

Skicast is amobile application that allows users to get the latest information on ski resorts in real-time. Through a partnership with SnoCountry.com, Skicast is able to provide the following information on ski areas in North America, Europe, and other ski areas in the southern hemisphere:

  • Open Alpine and Nordic trails
  • Trail conditions
  • Night Grooming
  • Trail Maps
  • Web Cam Views
  • Contact Information and Driving Directions
  • Weather Forecasts and Recent Snowfall totals

Enhancements to geo-locate nearby resorts are already underway, as well as Blackberry and iPhone versions. You can get to the Google Market page for Skicast by following the QR Code below.

qrcode

I’m working on an Android project right now where I plan on using a WebView to display some content, and I need to generate that content dynamically based on the results of a web service request. I wanted an easy-to-use templating language to build the pages with. I’ve worked with both Velocity and Freemarker, and either would’ve been fine. I settled on Velocity because it was a bit easier to set up to work with Android. Here’s how I did it.

Setup Logging

First, I wanted to setup Velocity to use Android’s built-in logging system. To do that, I needed to create my own logging class that implemented the LogChute interface.

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
48
49
50
51
52
53
54
55
56
57
58
59
60
package com.cereslogic.velocity;

import org.apache.velocity.runtime.RuntimeServices;
import org.apache.velocity.runtime.log.LogChute;

import android.util.Log;

public class VelocityLogger implements LogChute {
    private final static String tag = "Velocity";

    @Override
    public void init(RuntimeServices arg0) throws Exception {
    }

    @Override
    public boolean isLevelEnabled(int level) {
        return level > LogChute.DEBUG_ID;
    }

    @Override
    public void log(int level, String msg) {
        switch(level) {
        case LogChute.DEBUG_ID:
            Log.d(tag,msg);
            break;
        case LogChute.ERROR_ID:
            Log.e(tag,msg);
            break;
        case LogChute.INFO_ID:
            Log.i(tag,msg);
            break;
        case LogChute.TRACE_ID:
            Log.d(tag,msg);
            break;
        case LogChute.WARN_ID:
            Log.w(tag,msg);
       }
    }

    @Override
    public void log(int level, String msg, Throwable t) {
        switch(level) {
        case LogChute.DEBUG_ID:
            Log.d(tag,msg,t);
            break;
        case LogChute.ERROR_ID:
            Log.e(tag,msg,t);
            break;
        case LogChute.INFO_ID:
            Log.i(tag,msg,t);
            break;
        case LogChute.TRACE_ID:
            Log.d(tag,msg,t);
            break;
        case LogChute.WARN_ID:
            Log.w(tag,msg,t);
        }
    }

}

You can obviously adjust the isLevelEnabled method for your desired logging level.

Create a ResourceLoader

Next I need to feed my templates to Velocity. I could have read my templates manually as files from the assets directory, then passed the contents of the templates file to Velocity.evaluate as a String. But Velocity has a very configurable way to process templates that, enables it to cache templates internally, so I decided to try that.

When passing Velocity the name of a template file, it delegates the template loading to a ResourceLoader class. When you initialize Velocity, you can configure which ResourceLoaders it should use to find and read your templates.  Later. when you call the getTemplate method of the Velocity helper class, you pass it the name of the template that you’d like to load as a String. Velocity will pass the resource name down to its ResourceLoader(s).

I wanted to store my Velocity templates in the raw subdirectory of the res directory in the Android project, so I needed to build a ResourceLoader that could do that. I decided to extend Velocity’s built-in FileResourceLoader as a starting point. Here’s what I came up with:

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
package com.cereslogic.velocity;

import java.io.InputStream;

import org.apache.commons.collections.ExtendedProperties;
import org.apache.velocity.runtime.RuntimeServices;
import org.apache.velocity.runtime.resource.Resource;
import org.apache.velocity.runtime.resource.loader.FileResourceLoader;

import android.content.res.Resources;

public class AndroidResourceLoader extends FileResourceLoader {
    private Resources resources;
    private String packageName;

    public void commonInit(RuntimeServices rs, ExtendedProperties configuration) {
        super.commonInit(rs,configuration);
        this.resources = (Resources)rs.getProperty("android.content.res.Resources");
        this.packageName = (String)rs.getProperty("packageName");
    }

    public long getLastModified(Resource resource) {
        return ;
    }

    public InputStream getResourceStream(String templateName) {
        int id = resources.getIdentifier(templateName, "raw", this.packageName);
        return resources.openRawResource(id);
    }

    public boolean  isSourceModified(Resource resource) {
        return false;
    }

    public boolean  resourceExists(String templateName) {
        return resources.getIdentifier(templateName, "raw", this.packageName) != ;
    }
}

Because the templates are statically bundled with the .apk file, we can assume that Velocity’s caches don’t need to concern themselves with modification times on the templates, which is why getLastModified and isSourceModified don’t really do anything.  The getResourceStream and resourceExists methods lookup the resource ID by name. The commonInit method is called when the ResourceManager initializes the ResourceLoader. You’ll notice that this is where we stash the package name for the resources as well as an instance of the Resource class.

Use It

So to use what we just created, we need to do some configuration before we call Velocity.init(), which will look something like this:

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
public class MyActivity extends Activity {
  private void setupVelocity() throws Exception {
        Velocity.setProperty(Velocity.RUNTIME_LOG_LOGSYSTEM_CLASS, "com.cereslogic.velocity.VelocityLogger");
        Velocity.setProperty("resource.loader", "android");
        Velocity.setProperty("android.resource.loader.class", "com.cereslogic.velocity.AndroidResourceLoader");
        Velocity.setProperty("android.content.res.Resources",getResources());
        Velocity.setProperty("packageName", "com.cereslogic.myapplication");
        Velocity.init();
  }
.
.
.
//
// Somewhere where we want to use velocity:
//
    WebView engine = (WebView) findViewById(R.id.web_engine);
    Template template = null;
    try {
        setupVelocity();
        VelocityContext context = new VelocityContext();
        // add stuff to your context.
        template = Velocity.getTemplate("mytemplate");
        StringWriter sw = new StringWriter();
        template.merge(context, sw);
        engine.loadData(sw.toString(), "text/html", "UTF-8");
    } catch (Exception e) {
        // deal with it.
    }

In the setupVelocity method, we need to configure Velocity to use our new ResourceLoader and Logging classes, and configure the package name for our resources, just before calling Velocity init. Note that, if you name your template mytemplate.vm, you’ll only pass mytemplate to the Velocity getTemplate method. This is because of the idiosyncratic way that Android’s named resource lookup stuff works.

Now you’re ready to use Velocity in your Android project!

My old, temporary Ceres Logic website is gone, and I’ve replaced it with this new WordPress-based site.  I’ve also pulled over any blog posts from my personal blog that were more technically minded.  I’ve gone with a very minimalistic look for this new site, which is very intentional.  It’s also a bit more difficult than I expected – resisting the urge to pile in tons of widgets, sidebars, and elaborate colors takes some work.  It also takes some work to make the site look like I’ve done all this on purpose, and the plain look isn’t due to a lack of incentive.

Anyway, hope you like the new digs!

I’m sure that I’m not the person to make this connection, but it occurred to me the other day that being on a small team of coders is a lot like being in a band.  I’ve been in a couple bands that never went far beyond the garage (I’m allegedly a bass player), so perhaps I’m not the foremost authority on this topic.  However, I think there are a few parallels between building, e.g., a small MVC web application, and writing and performing the next standard verse-chorus-verse rock anthem.

Man Playing Bass guitar

In particular, I think there are parallels between the specific members of a prototypical Rock band, and the members of a team who create MVC applications:

  • Drummer – The Anchor.  Provides the foundation for the music, onto which the other layers are stacked and woven.  In an MVC app, this is your database guy/gal.  The person modeling your data and managing the schematic underpinnings of your application is your drummer.  And if you’re using a weird schema-less database like CouchDB, then you have yourself a sloppy jazz drummer, which means more work for the Bassist.
  • Bass Player – The Bass Player sets the groove for the song, and maps the primal beats that the drummer is hammering out into something melodic for the rest of the band to work with.  The bassist is also crucial for carrying the beat for the rest of the band when the drummer is screwing around (see note about jazz drummers, above).  In our web application, this is the domain layer, where your ORM, caching, and validation all chill out.  And like the bass player, this is rarely the sexiest or most glamorous part of the application.
  • Guitarist(s) – This is your business logic developer.  Some bands choose to break this up into your traditional Angus/Malcom roles of “rhythm” and “lead” guitar.  Likewise, you may choose to have separate model and controller layers in your app (particularly if you’re a three-tier app: the web tier controller is your Angus and the middle tier model is your Malcom).  Bass players can sometimes get by as guitarists in a pinch, and vice versa.  Likewise, you’ll see business logic guys doing domain work and vice versa.  Just don’t let them try to play their parts on the wrong instrument – you’ve gotta separate your concerns, dude.  Aside from the lyrics, this is the part of the song that your listeners are the most likely to hear.
  • Lead Singer – This is your AJAXy, CSS laden, poetic presentation of your band’s message.  It’s what your listeners hear (and see) first.  And the singer gets all flustered when the rest of the band screws up (the singer is a real primadonna, very sensitive). Changing your lead singer will almost certainly alieniate your fans (think Facebook redesign – the Sammy Hagar of UI decisions).

I tend to get carried away with analogies, and this one is no different – I could keep going (your roadies are your project managers, your label is the marketing and executives who make all the money) but I’ll try to show some restraint.  But given this analogy, I find it interesting that the role I play on software teams is often similar to the role I play in a band.  I like bass.

Photo Credit: Ian Matthew Soper

I used to use soapUI back when I was creating a SOAP API for a national wireless carrier.  Thankfully, I’ve been working primarily with REST APIs since then.  I noticed that soapUI had added REST support to their product, and recently I decided to try it out.

The REST API that I’m developing is in Rails (this is my first foray into Rails; I’m usually a Java guy with some occasional dabbling in Django and Grails), so the URLs don’t follow the traditional query-string format for passing parameters.  E.g., instead of GETting http://server:port/resource?id=123** to retrieve the resource with ID 123, it’s http://server:port/resource/123**.

For some reason (admittedly, I was being pretty dense at the time), it took me a long time to figure out how to do this in soapUI, but if you’ve stumbled into my blog by Googling for how it’s done, here’s the trick: first, set your resource URL to /resource/{id} (note that id is in curly braces).  Then, when defining your parameters, instead of leaving the STYLE parameter at its default value of QUERY, set it to TEMPLATE, being careful to name your parameter as it is named in the resource URL (in this case, id).  When soapUI generates the request, it’ll replace the {id} with the parameter’s value.

Last night I spoke at TechMaine’s Java Users Group about Maven.  I’ve made the slides available on Slideshare, although Slideshare botched some of the formatting a bit.  You will get the proper format if you download it and view it locally.

Demystifying Maven

Enjoy!  Here is the abstract for the presentation if you want to know what it’s about before diving in:

“Why do we need another build tool when we already have Ant? By focusing on convention over configuration, Maven allows you to declaratively define how your project is built, which reduces a lot of the procedural code that you’d need to implement in every build file if you were using Ant. This, along with Maven’s built-in management of repositories for project dependencies, allows you to streamline your build process. Ultimately Maven can reduce the amount of time that would otherwise be wasted hunting down jar files and fiddling with boilerplate build scripts.

This presentation covers Maven’s core concepts. It introduces the Plugin architecture, and explain how the most popular plugins are used. It also covers the POM concept and how it relates to dependency tracking and repositories.”

Private property sign

In a project I’m currently working on, I need to make some parameters configurable, and they need to be outside the .war file that I’m deploying. For example, let’s say I’m creating a service which reads data from some other RESTful service. And let’s say that the other RESTful service has two URLs, one for test and one for production. I’d like to be able to deploy my .war, and then edit a file outside of that .war file to configure which URL my service should be using.

My first inclination was to try to do this with a JNDI Environment Entry, so I began researching that approach. However, while the EJB spec states in 20.2.4 that the container must “provide a deployment tool that allows the Deployer to set and modify the values of the enterprise bean’s environment entries” (thanks for finding that one, ipage), JBoss does not seem to have such a facility.

Soon I started to wonder if JNDI wasn’t a bit overkill for what I needed to do, anyway.  I didn’t want to specify my parameters on the command-line; I wanted to simplify deployment and wanted to be able to change these values at runtime without restarting the server. But perhaps a System Property was all I needed.

As it turns out, JBoss has the System Properties Management Service for such things.  Here’s what you need to do:

  1. Make sure properties-plugin.jar is in your ${JBOSS_HOME}/server//lib directory.
  2. Make sure the properties-service.xml is in your deploy directory (you can find a copy in the “default” server directory)
  3. You now have two options, either edit the URLList to have a comma-separated list of locations of properties files, or you can specify your properties directly in properties-service.xml in the element.

Now, to access your property, all you need to do is call the venerable System.getProperty() method.

Photo Credit: Shelley Gibb

Tachometer

Sometimes it’s helpful to do some performance benchmarks on your EJBs. There are a few different ways to do this, but I’ve found that Apache’s JMeter is an excellent tool for benchmarking. Unfortunately, JMeter doesn’t come with a general-purpose sampler for testing arbitrary EJBs. Luckily, it isn’t very difficult to create one.

For this article, I’m using the JBoss application server to host my EJBs. The process for using other containers should be quite similar.

1.) Create a factory to lookup your EJBs.

The first thing that you’ll probably want to do is create a simple singleton factory class to create instances of your EJB client for your test. I use something like the following:

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
public class MyServiceFactory {
  private static final Log log = LogFactory.getLog(MyServiceFactory.class);
  private static MyService service;
  private static MyServiceFactory me;

  private MyServiceFactory() { }

  static {
    MyServiceFactory.me = new MyServiceFactory();
  }

  public static MyServiceFactory getInstance() {
    return MyServiceFactory.me;
  }

  public MyService getService() {
    if (MyService.service == null) {
      // Get the remote interface of the music search service
      try {
        log.info("Loading the service...");

        // JNDI the old-fashioned way:
        Context ctx = new InitialContext();
        service = (MyService)ctx.lookup("MyAction/remote");
        if (service == null) {
          log.error("Didn't get the service!");
        }
      } catch (NamingException e) {
        log.error("Error looking up the remote service", e);
        return null;
      }
    }
    return service;
  }
}

2.) Write the test

Next, we’ll need to write the test itself. To do this, we’ll extend the AbstractJavaSamplerClient class in JMeter’s org.apache.jmeter.protocol.java.sampler package. This abstract class has a runTest method that we will override, and this method implements the actual test. We will also override the getDefaultParameters method to provide some reasonable defaults values which will be displayed in JMeter’s GUI application.

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
package us.mikedesjardins.demo.jmeter;

import org.apache.jmeter.config.Arguments;
import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient;
import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext;
import org.apache.jmeter.samplers.SampleResult;

public class DigitalContentServiceEJBTestSampler extends AbstractJavaSamplerClient {
  public SampleResult runTest(JavaSamplerContext context) {
    SampleResult results = new SampleResult();
    MyService service = MyServiceFactory.getInstance().getService();

    results.sampleStart();
    Long param1 = context.getLongParameter("PARAM_1");
    String param2 = context.getStringParameter("PARAM_2");

    MyResult result = service.myMethod(param1, param2);
    if (result != null) {
       results.setSuccessful(true);
       results.setResponseCodeOK();
       results.setResponseMessage("'myResult:" + myResult);
    } else {
       results.setSuccessful(false);
    }
    results.sampleEnd();
    return results;
  }

  @Override
  public Arguments getDefaultParameters() {
    Arguments args = new Arguments();
    args.addArgument("PARAM_1", "4815162342");
    args.addArgument("PARAM_2", "Iculus");
    return args;
  }
}

3.) Setup JMeter

JMeter’s extra libs directory is ${JMETER_INSTALL_LIB}/lib/ext. Into that directory you will need to copy any jars that your EJB client will need. In you’re using JBoss, you will want to copy the jbossall-client.jar into that directory as well (for the JNDI client and other remoting goodies) – presumably other application servers have similar client jar files available.

When you fire up JMeter, your new sampler should appear in the Samplers menu. Enjoy!

Photo Credit: Bill Jacobus

Okay,I admit that this one should have totally been obvious to me long ago. But I’m still a bit of a JEE newcomer (been doing it for almost five years), so perhaps I can be forgiven.

If you do a lot of ORM or EJB remoting, you probably deal with a lot of Serializable classes. And you’re probably used to the annoying warning message that you see all the time in your IDE when you’re working with Serializable classes:

The serializable class BlaBlaBla does not declare a static final serialVersionUID field of type long BlaBlaBla.java myProject/src/main/java/us/mikedesjardins/foo/domain/entity line 44

If you’re like me, you roll your eyes and politely add a @SuppressWarnings(“serial”) to the top of the class definition (or, worse, you just shut the warning message off in your IDE altogether. Even I don’t do that!). You reason with yourself that current versions of Java conveniently and automatically compute the serialVersionUID at run-time, so there’s no need to bother with the formality of a version number on your class – it’s just a nuisance holdover from days of Java yore.

IT’S A TRAP!
Now that I’ve found myself well into a new project with this lazy philosophy, I’m starting to run into problems. I have a client of my EJB that uses one of these Serializable objects, and I’m finding that when I make the most trivial changes to my shared classes, I need to compile both the server and the client components. The two components that were supposed to be loosely coupled are now hopelessly intertwined. So I did some further research on how the JVM computes the ad-hoc serialVersionUID at runtime when it isn’t provided.

This article over at JavaWorld does a far better and more thorough job of explaining it than I will. In a nutshell, backward-compatability with respect to serialization and de-serialization is a lot less fragile than the cases that the serialVersionUID generation is protecting you against. That version generation algorithm computes an SHA hash based on the class name, sorted member variables, modifiers, and interfaces.

In reality, serialization and de-serialization generally only breaks when one of the following things happens to your class (from the aforementioned article at JavaWorld): * Delete fields * Change class hierarchy * Change non-static to static * Change non-transient to transient * Change type of a primitive field

Ensure Minimal Coupling Between Components
To ensure that your components which use Serialization have minimal runtime dependencies on each other, you have two options: * Declare a specific serialVersionUID, and update it whenever you make a change that breaks backward compatability. * Don’t rely on any classes for use as transfer objects which will potentially change. This one is pretty obvious, but sometimes you will be surprised down the road at which classes are modified more often than others. * Don’t use your own objects at all when transferring data. Instead, rely on classes like Integers, Strings, or HashMaps to shuttle data around among components. (Obviously, protocols like SOAP and REST rely on XML documents for this to ensure maximum de-coupling, but you’re presumably using something like EJB remoting to avoid the complexity or overhead of these protocols).

Photo Credit: Mike Johnson

If you have a service that is a client of a remote EJB, you may have run into the situation where the EJB server shuts down and restarts. When this happens your EJB client may need to be restarted as well, in order to re-discover and reconnect to the EJBs; otherwise you’ll end up with connection exceptions in the client.

If you’re using Spring to autowire your EJB clients, it’s quite easy to configure the service so that the home interface will refresh on connection failures. Note that if you’re using EJB3, you will need to upgrade to at least version 2.5.5 of Spring. There is a bug in earlier versions of Spring which prevented this technique from working with EJB3.

In your spring file, make sure you configure your slsb references to have cache-home disabled, and refresh-home-0n-connect-failure thusly:

1
2
3
4
5
6
7
8
9
<jee:remote-slsb id="myService" jndi-name="MyService/remote"
        business-interface="us.mikedesjardins.services.MyService"
        cache-home="false" lookup-home-on-startup="false"
        home-interface="us.mikedesjardins.services.MyService"
        resource-ref="false" refresh-home-on-connect-failure="true">
    <jee:environment>
           <!-- Include any relevant environment settings here -->
    </jee:environment>
</jee:remote-slsb>

With this, you should be able to restart your EJB hosts without needing to restart your EJB clients!