Posted by Vincent Partington at around evening time: December 14th, 2009
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?
(more…)
Posted by Vincent Partington at around evening time: December 7th, 2009
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.
(more…)
Posted by Vincent Partington in the early evening: November 23rd, 2009
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.
Posted by Vincent Partington mid-afternoon: November 13th, 2009
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?
(more…)
Posted by Vincent Partington in the early evening: August 24th, 2009
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.
(more…)
Posted by Vincent Partington at around evening time: August 5th, 2009
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.
(more…)
Posted by Vincent Partington in the early evening: July 13th, 2009
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.
(more…)
Posted by Vincent Partington around lunchtime: July 11th, 2009
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…
(more…)
Posted by Vincent Partington in the early evening: June 21st, 2009
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:
- 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.
- 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.
- 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?
(more…)
Posted by Vincent Partington around lunchtime: June 13th, 2009
Last week my colleague Albert Sikkema blogged about using UUIDs as primary keys. Interesting stuff, thanks again, Albert! This week I will continue the JPA implementation patterns series by discussing the relative merits of field access vs. property access.
The JPA specification allows two ways for the persistence provider to access the persistent state of an entity. The persistence provider can either invoke JavaBeans style property accessors (getters and setters) or access the instance fields of the entity directly. Which method is used depends on whether you have annotated the properties or the fields of an entity.
(more…)