Middleware integration testing with JUnit, Maven and VMware, part 3 (of 3)

Last year, before the Christmas holidays ;-), I described how we do middleware integration testing at XebiaLabs and I described the way we deploy test servlets by wrapping them in WAR and EAR files that get generated on the fly. There is only one thing left to explain; how do we integrate these tests into a continuous build using Maven and VMware?

Running the middleware integration tests

So let’s start with the Maven configuration. As I mentioned in the first blog of this series, the integration tests are recognizable by the fact that the classnames end in Itest. That means they won’t get picked up by the default configuration of the Maven Surefire plugin. And that is fortunate because we don’t always want to run these tests. Firstly they require a very specific test setup (the application server configurations should be in an expected state, see below) and secondly they can take a long time to complete and that would get in the way of the quick turnaround we want from commit builds in our continuous integration system.
Read more β†’

Middleware integration testing with JUnit, Maven and VMware, part 2 (of 3)

Last week I wrote about the approach we use at XebiaLabs to test the integrations with the different middleware products our Java EE deployment automation product Deployit supports.

The blog finished with the promise that I would discuss how to test that an application can really use the configurations that our middleware integrations (a.k.a. steps) create. But before we delve into that, let us first answer the question as to why we need this. If the code can configure a datasource without the application server, it must be OK for an application to use it, right? Well, not always. While WebSphere and WebLogic contain some functionality to test the connection to the database and thereby verify whether the datasource has been configured correctly, this functionality is not available for other configurations such as JMS settings. And JBoss has no such functionality at all. So the question is: how can we prove that an application can really work with the configurations created by our steps?
Read more β†’

Middleware integration testing with JUnit, Maven and VMware, part 1 (of 3)

For Deployit, XebiaLabs’ automated deployment product for Java EE applications, we are always building and modifying integrations with middleware systems such as IBM WebSphere, Oracle WebLogic and the JBoss application server. These integrations are small enough so that they can be rearranged to get many different deployment scenarios. A typical step, as we call these integrations, would be “Create WebSphere datasource” or “Restart WebLogic Server”. So how do the test that code?

We’ve had some success using FitNesse and VMware to do integration tests on our deployment scenarios. But there were a few problems with this apporach:

  • We could only test complete deployment scenarios in this way. If we wanted to test just a single step, we had to make a deployment scenario that used that step just to be able to test it.
  • Because FitNesse does not provide any feedback while a test is running and the steps, let alone the deployment scenarios, can sometimes take a while to execute, there was little feedback on the progress.
  • While it is possible to debug a FitNesse Fixture using Eclipse the process is not very convenient when debugging a technical component such as this step.
  • To verify that a deployment scenario has executed succesfully we had to extend our FitNesse Fixture often. And while debugging code under test in FitNesse is complicated enough, debugging a Fixture is even harder!

Clearly we needed a different approach if we wanted to develop new steps easily.
Read more β†’

IBM WebSphere scripting with wsadmin: containment paths, configuration IDs and object names

logo_websphere2
In my previous blog on the deployment capabilities of the major application servers, I asked, as a joke, whether anybody knew the difference between containment paths, configuration IDs and object names in WebSphere’s scripting interface wsadmin. I didn’t get (nor expect πŸ˜‰ ) an answer. But instead of keeping you in the dark, this blog will explain the difference between these three and how you can translate between them.

Configuration ID

Configuration IDs are the most common id you will encounter when working with wsadmin. They uniquely specify an element in the configuration of WebSphere Application Server and are needed to modify the configuration with one of the commands in the AdminConfig object.

Read more β†’

Do application server vendors really understand deployment?

At XebiaLabs we know a thing or two about the automated deployment of Java EE applications πŸ˜‰ . One thing that strikes me as odd is the fact that the people you would expect to know most about application deployment, the application server vendors, don’t seem to understand the problem at all.

On one of our previous blogs, you can read up on what we see as the full scope of a Java EE application deployment. The short version is this:

  • It’s more than just deploying an EAR file or a WAR file. For starters, it can involve more than one of these.
  • Most applications also need other kinds of artifacts to be deployed, such as static content for the webserver or static configuration files to be read by the Java code on startup.
  • You’ll also need to configure Java EE resources such as data sources, JMS providers, etc.
  • In most cases you need to configure the middleware itself too. Think about creating and configuring application server clusters, or setting up Apache virtual host configurations.
  • All this needs to happen in the right order to minimize (or prevent) downtime of the application during deployment and improve speed of the deployment.

So what do the application server vendors make of this?
Read more β†’

Integrating deployment automation and configuration management

My colleague Robert van Loghem and I have been blogging about Java EE deployment the last few weeks. And that is not without a reason; we have built Deployit, a product to automate Java EE deployments. We’ve already mentioned it before in some of our podcasts and blogs, so now might be a good time to explain some of the concepts behind our product.

The problem

The problem our product is addressing is that Java EE deployments are tedious and unpredictable affairs that can also be very dependent on specific knowledge. The guys at ZeroTurnaround conducted a survey on Java EE redeployment and restart times. The results are interesting, especially when you consider that these times are for a redeployment in a development environment. Consider the challenges of doing this in a production environment with an application server cluster, multiple web servers, and databases and so forth that all need to be configured and restarted using a full redeployment scenario. I believe that the only way to do deploy applicaitons in a reliable and efficient manner is to automate this task. Something that IT analysts such as Gartner and Forrester also see as an emerging and hot topic.
Read more β†’

Incremental deployments vs. full redeployments

Four weeks ago my colleague Robert van Loghem wrote about what the full scope of a deployment in an enterprise Java environment. The scenario that Robert presented included the configuration of databases, web servers, firewalls and Java EE resources. All are just as important to get your application up and running as the deployment of an EAR file.

But even though Robert’s procedure was more complicated than the simple installation of an EAR file, it did not cover an even more common scenario; upgrading an application to a new version. While the initial deployment of an application is important, I think that upgrades are even more interesting for a number of reasons:

  • The most obvious reason is that upgrades simply happen more often than initial deployments.
  • Upgrades (in production) happen when users are already using the application, so the application should remain accessible during the deployment.
  • If the upgrade fails, the old version of the application should still be there.
  • And finally, but this is a more people oriented aspect of it, upgrades can be tricky because the focus on the application may have disippated over time. When the application is deployed for the first time, everybody is paying attention: the developers, the middleware administrators, the architects, the project managers, the end users, etc. So when a problem arrises, it is usually addressed quite quickly. But when version 2.1.54 comes around and an administrator is asked to install it on a Friday afternoon, that is when things can go horribly wrong and ruin the poor admin’s weekend. Paying attention to the complexity of application upgrades, can mitigate this.

Because the upgrade scenario is the most important deployment scenario, it is something that comes up often when talking to clients about Deployit, our deployment automation product.
Read more β†’

JPA implementation patterns: Wrap-up

The previous blog in the JPA implementation patterns series discussed different ways to test your JPA code. Figuring out how to test DAO’s and then being frustrated because the existing literature on JPA seemed to say very little on this subject, was actually the trigger for me to write these blogs. I have now come full circle, which means it’s time to wrap up the series. There’s lots more to write about, so keep following this blog! πŸ™‚

After discovering that there was a lack of documentation on how to use JPA in real-life scenario’s, I have written a series of blogs about the JPA implementation patterns I discovered while writing JPA code. To wrap up the series, I have made an overview of all the patterns that have been discussed for easy reference. The list is mostly in chronological order. I only changed the order slightly to make a distinction between the basic patterns and the advanced patterns.
Read more β†’

JPA implementation patterns: Testing

In the previous blog in the JPA implementation patterns series, I talked about the three default ways of mapping inheritance hierarchies using JPA. And introduced one non-standard but quite useful method. This week I will discuss various approaches to testing JPA code.

What to test?

The first question to ask is: what code do we want to test? Two kinds of objects are involved when we talk about JPA: domain objects and data access objects (DAO’s). In theory your domain objects are not tied to JPA (they’re POJO’s, right?), so you can test their functionality without a JPA provider. Nothing interesting to discuss about that here. But in practice your domain objects will at least be annotated with JPA annotations and might also include some code to manage bidirectional associations (lazily), primary keys, or serialized objects. Now things are becoming more interesting…
Read more β†’

JPA implementation patterns: Mapping inheritance hierarchies

Last week I discussed the relative merits of field access versus property access in the ongoing JPA implementation patterns blog series. This week I will dwell on the choices offered when mapping inheritance hierarchies in JPA.

JPA provides three ways to map Java inheritance hierarchies to database tables:

  1. InheritanceType.SINGLE_TABLE – The whole inheritance hierarchy is mapped to one table. An object is stored in exactly one row in that table and the discriminator value stored in the discriminator column specifies the type of the object. Any fields not used in a superclass or a different branch of the hierarchy are set to NULL. This is the default inheritance mapping strategy used by JPA.
  2. InheritanceType.TABLE_PER_CLASS – Every concrete entity class in the hierarchy is mapped to a separate table. An object is stored in exactly one row in the specific table for its type. That specific table contains column for all the fields of the concrete class, including any inherited fields. This means that siblings in an inheritance hierarchy will each have their own copy of the fields they inherit from their superclass. A UNION of the separate tables is performed when querying on the superclass.
  3. InheritanceType.JOINED – Every class in the hierarchy is represented as a separate table, causing no field duplication to occur. An object is stored spread out over multiple tables; one row in each of the tables that make up its class inheritance hierarchy. The is-a relation between a subclass and its superclass is represented as a foreign key relation from the “subtable” to the “supertable” and the mapped tables are JOINed to load all the fields of an entity.

A nice comparison of the JPA inheritance mapping options with pictures, and including a description of the @MappedSuperclass option, can be found in the DataNucleus documentation.

Now the interesting question is: which method works best in what circumstances?
Read more β†’