Plans for project migration on GitHub

Just to let you know what is happening with this project since the Google Code since the hosting repository shutdown was announced.

Impala is was previously hosted on Google Code, which went into only mode in August and was due to be shut down in January 2016.

We have recently migrated the project to GitHub. The most recent fork on which future changes will be made is https://github.com/realtimedespatch/impala until further notice are.

The project has not seen a lot of active development, but it is a core part of the software infrastructure at Realtime Despatch, where I am a part owner and have been Technical Director since 2009.

It has been fantastically effective at Realtime Despatch in creating a development and deployment platform which both aligns with our commercial objectives and suits our agile approach to software development.

We have no plans to 'market' or promote the project to a wider audience in a way that will increase the scope of the software we need to develop and support within the project. However, we will potentially add features as required to meet our own business needs.

The main focus of changes made in the GitHub fork are as follows:

• bringing the code and examples up to date with the latest version of Spring (currently 4.2.4).
• setting the compile compatibility flag to Java 1.6.
• stripping out examples for older frameworks.

Going a bit further forward, my plans for the project are:

• a project rename. There are too many other projects called 'Impala' (although there weren't when I chose the name originally). I need to decide how far to take this in terms of things like renaming files, and core packages, for example.
• further slimming down the project by stripping out features that we no longer intend to support. However, no changes to the structure of core interfaces are planned.
• porting and refining the documentation, focusing on more simple documentation based on the mode of operation that we are currently using at Realtime Despatch.

Impala 1.0.3 released

I am pleased to announce the 1.0.3 release of Impala. Partly a maintenance release to bring Impala fully up to date to latest versions of the Spring Framework.

You can download Impala 1.0.3 from the project site. Modules have also been published to the Maven central repository.

While the core of Impala is very stable, the new release contains a few useful new features to help users of the project in development and in the field. I plan to add separate posts regarding a couple of these features. Below is a quick overview.

Selectively reloadable modules

With Impala 1.0.3 it is now possible to turn on module reloadability selectively.
In other words, some but not all of the modules in an application can be set to reloadable.

The advantage of this feature is that it opens up the possibility of supporting safer reloadability of certain modules in a production environment. Modules that may require reloading while an application is running can be set to reloadable, while core modules that should remain static can be set to non-reloadable. This allows for partial update of selective elements of a running application without disruption to users.

File system module resources

Impala web application resources are typically packaged for production in module-specific jars. On occasions, a requirement exists to change resources (such as web templates) packaged as part of the application without doing a full software build and release. Prior to 1.0.3, replacing any module-specific resource would require the to be rebuilt, which is a little awkward.

With Impala 1.0.3, the resource loading mechanism has been modified to first look in a module-specific file system location, if such a location is present. This supports a simpler mechanism for updating or 'hot fixing' resources in an application, without the overhead of a new software release.

Spring 3.2.2 support

Impala has been updated to work out of the box with the latest version of Spring, currently 3.2.2. Impala is now also compiled using Spring 3.2.

Java Generics compliance

Changes have been made in the Impala source code to support Java 5 generic compliance where this support wasn't present.

Comment syntax

With 1.0.3, the Impala module definition file (in which modules to be deployed are listed) supports a comment syntax, making it easier to comment against entries in this file.

Planned updates to Impala in the near term

I am planning to do some overdue work on Impala in the short term to bring it up to date. The next release I am planning to do will be version 1.1. It will essentially be a maintenance release.

Apart from a couple of minor features still to be determined, the main focus will be on getting Impala working nicely with Spring 3.1 and Spring 3.2.

Right now, Impala won't run Spring 3.1 because of changes to the ApplicationContext interface, which introduced a getEnvironment() method. The changes to Impala to support this are very small, and will be made in this release. I also plan to use Spring 3.2 as the compile version.

I also intend to introduce changes to make it easier to add module-specific resources to a running application, which can be useful in providing on-the-fly template fixes in production.

Apart from this, I also intend to slim down the project significantly:

• removing features that are no longer necessary, have been superseded, or are no longer supported.
• removing old examples projects that I no longer intend to maintain.

I am also planning to all projects relating to OSGi support in Impala. As some will know, I experimented with introducing OSGi support to Impala, with some success. However, I also reached the conclusion it would take a great deal of work to make OSGi really usable in an Impala environment, work which I was certainly not interested in committing to. I'm quite happy to maintain Impala's status as a simpler alternative to OSGi, rather than a project which is designed to support OSGi directly.

Impala 1.0.2 released

I am pleased to announce the release of Impala 1.0.2. This is primarily a bug fix release, but also contains some minor as well as more significant feature enhancements.

It's downloadable from the Impala downloads page. The jars will also be available shortly on the Maven central repository. 

Optional modules
It is now possible to express dependencies on optional modules. Module B may declare an optional dependency on module A, which means that if A is present, it's classes, resources and beans will be visible to module B. However, if A is not loaded, the application will not fail.

This feature makes it possible to allow optional functionality to be included in an application.

Module-specific library jars
This feature, described an earlier blog entry, allows a module to use third party library classes which are specific to that module. In other words, it allows a module to load it's own version of a particular third party library class, potentially one which is different from or conflicts with the class visible to other modules in the application.

In addition, this release covers a number of other issues. See the list of issues in this release.

Dealing with library version clashes in Impala

One of the problems that occasionally crops up in Java application development is library class version clashes. For some reason, you have to use a particular version of some library, but that library, or some of dependencies, clashes with other libraries that you are using for different parts of the application. I encountered an example of this occurring on our project, where we were forced to use the old Axis 1.4 library to connect with an integration partner. (For those who are interested, the reason is that the our partner is using the rpc/encoded SOAP API configuration, which is generally regarded as obsolete, and is not supported by any of the modern SOAP libraries, from CXF to Metro, as well as the Axis successor, Axis 2. See here and here for more on this problem.)

The ability to deal with these kinds of problems is often cited as one of the main reasons for using OSGi. In my development of Impala, I have steered clear from tackling these kinds of problems, on the basis that while they are theoretically quite valid to consider, in practice they occur quite rarely, and there generally is a workaround. Unfortunately, in my recent project, the workarounds seemed quite unpalatable. One would have been to resort a plain text based client for this SOAP API. For a small API, this would have been satisfactory, but for a large API it would have involved quite a bit of extra work. Ultimately, it seemed like a sensible point to add to Impala some capability for dealing with library version clashes.

The new mechanism simply involves the following:

• add any module-specific library in the module's lib directory. For our project, this involved adding axis-1.4.jar and a couple of its dependencies
• add the setting supports.module.libraries=true to impala.properties

This feature is currently in the code base and will be available in the next release, 1.0.2, which should be available soon.

How does it work?

In the normal Impala application, a class is loaded first by using the web application or system class loader (typically to load third party libraries), then using a topologically sorted list of the dependent module class loaders (typically to find application classes).

With module-specific libraries, the scheme is a bit more complex. For any module which has module-specific libraries, the module-specific library locations are searched first. Suppose we are loading module A, and we need to load the class Foo is in both the shared library area (WEB-INF/lib) and in a module-specific location for module A. In this case, the class Foo will be found in and loaded from the module-specific location.

Caveats

The main caveat is that the class Foo should never be 'published' from module A, for example as the return type in a method which might be called from another module, otherwise ClassCastExceptions or LinkageErrors can result. Instead, the interfaces to module A should ensure that appropriate abstractions are in place to ensure that this does not occur. In our Axis example, we need to ensure that instances of classes which hold references to Axis libraries are not passed around between modules.

More details on how the class versioning feature works, and how it can be configured, will be added to the documentation wiki.

The solution is by no means the solution to any kind of class versioning requirement which may crop up. Multiple versions for particular classes is still seen as the exception rather than the rule, and the scope as well as the complexity of the solution reflects this. That being said, there is at least a workable practical solution when you are stuck in a corner on this problem.

Impala 1.0.1 released

I am pleased to announce the release of Impala 1.0.1. This release is basically a bug fix release. For more details on the bugs fixed, see this list.

While the pace of Impala's development has slowed in recent months, it is still in active development. I am still using Impala every day in my day job. If provides the foundation for the next generation e-commerce fulfillment software we are developing at Realtime Despatch. The reason I have been spending less time developing Impala is not because I have less use for it. On the contrary, it has really proved it's worth in the last year, making what could otherwise be a monster project quite comfortably manageable. The modularity and productivity features provided by Impala are not only fundamental for rapid development of our software, they also important in supporting our business model.

That being said, there are a few features that are backing up which I am hoping to develop in the next few months, and hope to pick up the pace again.

Impala Code Jam in London in London on May 26th

Next Wednesday I will be holding an Impala Code Jam at Skills Matter in London, organised through the Java Web User's Group (JavaWUG). For the people who come along, this will be a hands-on opportunity to spend some time working on a simple Impala application and to get a better understanding of the concepts involved, and for most, to get a first hand flavour of how Impala can help in writing better, more flexible Spring based applications.

More details on the Code Jam are available from the JavaWUG announcement.