images images images

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.

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.

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

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

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!

Recently, I wanted to be able to clear out all of the Hibernate caches via JBoss’s JMX console. I could have taken the easy way out; we’re using EHCache, so it could have been as simple as calling CacheManager.clearAll(). However, that would have tied me to a specific cache provider. We’re still evaluating switching to other cache providers. Ideally, my solution would not be dependent on a specific cache implementation.

Hibernate’s API does provide a simple way to clear specific caches, but does not provide any method for clearing out all of them. Writing your own is fairly straightforward. First, you obtain all of the entity and collection metadata from the session factory. Next you iterate over the entities, and if the object is cached, you clear out all of the caches associated with the persisted class or collection. Here’s the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
  @PersistenceContext
  private EntityManager em;

  public void clearHibernateCache() {
    Session s = (Session)em.getDelegate();
    SessionFactory sf = s.getSessionFactory();
    Map<string,EntityPersister> classMetadata = sf.getAllClassMetadata();

    for (EntityPersister ep : classMetadata.values()) {
      if (ep.hasCache()) {
        sf.evictEntity(ep.getCache().getRegionName());
      }
    }

    Map<string,AbstractCollectionPersister> collMetadata = sf.getAllCollectionMetadata();
    for (AbstractCollectionPersister acp : collMetadata.values()) {
      if (acp.hasCache()) {
        sf.evictCollection(acp.getCache().getRegionName());
      }
    }
    return;
  }

Now, if we decide to switch to a different cache provider, this code will not need to be re-written. Hopefully we won’t ever change to a different JPA implementaion. :)

At my past few jobs, I’ve had to spend a lot of time on conference calls with developers and project managers. While I don’t profess to be a “conference call expert” (or, for that matter, an etiquette expert), I think there are some general ground rules for conference calls, and I’m going to deviate a bit from my usual Hibernate/JEE topics to itemize the ones that I think are important.

At my current job, I’m actually pretty lucky. Almost all of us work remotely, so we’re pretty accustomed to how to behave in the ubiquitous con-call. At a previous engagement, I wasn’t so lucky – I’ll omit their names to protect the guilty.

So here’s an arbitrary list from me, a random guy on the internet of questionable credentials, of what you should and shouldn’t do on a conference call. Some of these probably seem really obvious, but I’m listing even the obvious ones because some people still break them:

1.) Use the Mute Button, especially on a speakerphone. The most important reason for using Mute is to prevent echo-y feedback, particularly on speaker phones. If you aren’t talking, please put your speaker phone on mute for the sake of everyone else listening. Note that following this rule will invariably lead to the embarrassing situation where you start talking and don’t realize that you’ve left your phone on mute. Don’t worry, we’ve all done it and we’ll all forgive you!
2.) Introduce yourself when you enter the conference. Some conference systems will force you to state your name when you log in, and then the robo-operator will announce you when you join. I actually find this to be quite jarring, especially when robo-operator interrupts what everyone is saying. Better systems will play a quiet tone when people enter or leave the call. Some, like one that a client had at my previous job, will do nothing at all. This would allow people to lurk on the line unbeknownst to the participants, which is terribly rude. Likewise, if you enter a conference room while a conference call is already underway, announce yourself at the next free moment. Ideally, the moderator of the conference will also take a moment to introduce everybody at the beginning of the call if there is a chance that everyone doesn’t know each other. This is a great idea.
3.) Close the Door. It’s best to go to a closed room to join a conference call to eliminate background noise. If you can go to such a place, do it. Don’t join a conference call from, e.g., a street cafe or airport gate. In doing so you risk a passing ambulance, street parade, or TSA threats to destroy unattended luggage interrupting the call.
4.) Don’t use a mobile phone if you can help it. Occasionally you can get away with using a mobile for a con-call in a pinch. But if it’s a super-important meeting where you are trying to make an impression or do something complicated, nothing will be more frustrating than a garbled, broken up, or dropped call. Try to use a land-line if you can.
5.) Don’t eat on the phone. I guess this is just a personal pet peeve of mine. I can’t even listen to NPR if the announcer’s voice is all moist and saliva-sounding. This is more important if you’re wearing a headset.
6.) Have an agenda that everyone receives beforehand. This goes for all meetings, but it’s just as critical for a conference call. This helps you set expectations and stay on-topic during the call.
7.) Get some screen-sharing software. Better yet, get some screen sharing software and test it out before the meeting. With it, you can use something as simple as Notepad or TextMate as a virtual whiteboard. For some reason, we never did this at my previous jobs. We’ve done it at my current job and it works great.
8.) Pick a good time for all participants. This is particularly important if you’re working in different time zones. Generally you can depend on developers being available between 10am and 4pm in their respective time zones – you can argue that programmers need to grow up and work regular business hours like everyone else. But until the voodoo of deadline creation becomes a perfected science, software people will need to occasionally work late into the night or early in the morning to meet schedules. Or (like anyone else) we may have daycare responsibilities and have to leave a little early. So we stay flexible. This means that if you’re working on, e.g., both coasts of the United States, your best bet is between 1pm and 3pm, eastern time. If you’re working in the U.S. and the far east, you’re usually stuck with getting the U.S. participants to work early, and the others late in their workday. Similarly between Europe and the U.S., the U.S. participants will probably need to be available late in the day, and the Europeans earlier.

What do you think? Have I missed any conference call ground rules?

Photo Credit: Stephen Cummings