Monday, April 22, 2013

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.

Wednesday, December 19, 2012

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.

Saturday, March 24, 2012

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.

Tuesday, November 8, 2011

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.

Wednesday, August 10, 2011

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.

Thursday, May 20, 2010

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.

Wednesday, May 12, 2010

Some further comments on the 1.0 release

I'd like to make some comments about the timing of the 1.0 final release of Impala. As I've mentioned elsewhere, the aim of Impala is to extract every last ounce of productivity and flexibility out of Spring-based development, while at the same time remaining true to the principles that made Spring popular in the first place - simplicity and testability. I believe that with this release I can confidently claim that these aims are being achieved, and that Impala provides one of the most productive and flexible environments for building Spring-based applications.

Impala has been used in real world projects for almost three years. Over this period it has undergone extensive refactoring to ensure that the architecture is right - flexible, maintainable, and open to the kinds of extensions which are likely to be introduced in the coming months and years. After over 5500 subversion commits, I am pleased to say that I am comfortable that this goal has been achieved.

While Impala has allowed me to achieve unprecedented levels of productivity in projects in which I have used it, I have also been mindful that more widespread adoption requires adding support to commonly requested features, even ones not necessary in my own projects. Much of the effort put into the project in recent months supports these objectives. Impala now has decent support for Maven, and also allows for fully modularised web applications, including their constituent classes, JSPs and resources.

This work has gone a long way to extending the capabilities of Impala and offering a greater choice in the technology combinations that will work out of the box with Impala. This work is continuing. Nevertheless, I am now comfortable that the feature set in Impala is suitable for a 1.0 release.

I have really enjoyed developing Impala and look back on the work with a lot of pride. It has been a fun project, full of technical challenges. However, there is still plenty of work to do, and plenty of exciting areas to explore. To this end I would very much welcome more direct involvement from the community in helping the project to achieve it's potential. This involvement can take any form you might imagine, from testing the framework in different environments, to building a web site for the project, to adding tool support, through to working on new samples and even new feature set.