tag:blogger.com,1999:blog-13756331674269045362024-02-21T15:43:38.117+00:00The Impala BlogPhil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.comBlogger67125tag:blogger.com,1999:blog-1375633167426904536.post-54592191171882458602016-01-22T11:43:00.002+00:002016-01-22T11:54:45.902+00:00Plans for project migration on GitHubJust to let you know what is happening with this project since the Google Code since the hosting repository shutdown was announced.<br />
<br />
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.<br />
<br />
We have recently migrated the project to GitHub. The most recent fork on which future changes will be made is <a href="https://github.com/realtimedespatch/impala">https://github.com/realtimedespatch/impala</a> until further notice are.<br />
<br />
The project has not seen a lot of active development, but it is a core part of the software infrastructure at <a href="http://www.realtimedespatch.co.uk/" target="_blank">Realtime Despatch</a>, where I am a part owner and have been Technical Director since 2009.<br />
<br />
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.<br />
<br />
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.<br />
<br />
The main focus of changes made in the GitHub fork are as follows:<br />
<ul>
<li>bringing the code and examples up to date with the latest version of Spring (currently 4.2.4).</li>
<li>setting the compile compatibility flag to Java 1.6.</li>
<li>stripping out examples for older frameworks. </li>
</ul>
Going a bit further forward, my plans for the project are:<br />
<ul>
<li>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.</li>
<li>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.</li>
<li>porting and refining the documentation, focusing on more simple documentation based on the mode of operation that we are currently using at Realtime Despatch.</li>
</ul>
Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com5tag:blogger.com,1999:blog-1375633167426904536.post-25425386308703810442013-04-22T15:23:00.000+01:002013-04-22T15:23:06.648+01:00Impala 1.0.3 releasedI 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 <a href="http://www.springsource.org/spring-framework" target="_blank">Spring Framework</a>.<br />
<br />
You can <a href="http://code.google.com/p/impala/downloads/list" target="_blank">download Impala 1.0.3</a> from the project site. Modules have also been published to the <a href="http://search.maven.org/#search|ga|1|impalaframework" target="_blank">Maven central repository</a>.<br />
<br />
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.<br />
<br />
<b>Selectively reloadable modules</b><br />
<br />
With Impala 1.0.3 it is now possible to turn on module reloadability selectively.<br />
In other words, some but not all of the modules in an application can be set to reloadable.<br />
<br />
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.<br />
<br />
<b>File system module resources</b><br />
<br />
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.<br />
<br />
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.<br />
<br />
<b>Spring 3.2.2 support</b><br />
<br />
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.<br />
<br />
<b>Java Generics compliance</b><br />
<br />
Changes have been made in the Impala source code to support Java 5 generic compliance where this support wasn't present.<br />
<br />
<b>Comment syntax</b><br />
<br />
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.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-80589876874791234972012-12-19T09:42:00.003+00:002012-12-19T09:42:34.528+00:00Planned updates to Impala in the near termI 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.<br />
<br />
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.<br />
<br />
Right now, Impala won't run Spring 3.1 because of changes to the <span style="font-family: "Courier New",Courier,monospace;">ApplicationContext</span> interface, which introduced a <span style="font-family: "Courier New",Courier,monospace;">getEnvironment()</span> 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.<br />
<br />
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.<br />
<br />
Apart from this, I also intend to slim down the project significantly:<br />
<ul>
<li>removing features that are no longer necessary, have been superseded, or are no longer supported.</li>
<li>removing old examples projects that I no longer intend to maintain.</li>
</ul>
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.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-38971990723433945562012-03-24T22:32:00.000+00:002012-03-24T22:44:35.765+00:00Impala 1.0.2 releasedI 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.<br />
<br />It's downloadable from the <a href="http://code.google.com/p/impala/downloads/list" target="_blank">Impala downloads page</a>. The jars will also be available shortly on the Maven central repository. <br />
<br />
<b>Optional modules</b><br />
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.<br />
<br />
This feature makes it possible to allow optional functionality to be included in an application.<br />
<br />
<b>Module-specific library jars</b><br />
This feature, described <a href="http://impalablog.blogspot.co.uk/2011/11/dealing-with-library-version-clashes-in.html" target="_blank">an earlier blog entry</a>, 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.<br />
<br />
In addition, this release covers a number of other issues. See the <a href="http://code.google.com/p/impala/issues/list?can=7&q=label%3AMilestone-Release1.0.2" target="_blank">list of issues in this release</a>.<br />
<br />Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com1tag:blogger.com,1999:blog-1375633167426904536.post-54591299940908126992011-11-08T16:53:00.008+00:002011-11-08T17:05:09.966+00:00Dealing with library version clashes in Impala<span style="font-family:Helvetica, Arial, sans-serif;">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 <span style="font-family:courier new;">rpc/encoded</span> 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 <a href="http://stackoverflow.com/questions/412772/java-rpc-encoded-wsdls-are-not-supported-in-jaxws-2-0">here</a> and <span style="text-decoration: underline;">here</span> for more on this problem.)<br /><br />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.<br /><br />The new mechanism simply involves the following:<br /></span><ul><li><span style="font-family:Helvetica, Arial, sans-serif;"> add any module-specific library in the module's <span style="font-style: italic;">lib</span> directory. For our project, this involved adding <span style="font-style: italic;">axis-1.4.jar</span> and a couple of its dependencies</span></li><li><span style="font-family:Helvetica, Arial, sans-serif;"> add the setting <span style="font-family:courier new;">supports.module.libraries=true</span> to <span style="font-style: italic;">impala.properties</span></span></li></ul><span style="font-family:Helvetica, Arial, sans-serif;"> This feature is currently in the code base and will be available in the next release, 1.0.2, which should be available soon.<br /><br /><span style="font-weight: bold;"> How does it work?</span><br /><br />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).<br /><br />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 <span style="font-family:courier new;">Foo</span> is in both the shared library area (<span style="font-style: italic;">WEB-INF/lib</span>) and in a module-specific location for module A. In this case, the class <span style="font-family:courier new;">Foo</span> will be found in and loaded from the module-specific location.<br /><br /><span style="font-weight: bold;">Caveats</span><br /><br />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 <span style="font-family:courier new;">ClassCastExceptions</span> or <span style="font-family:courier new;"> LinkageErrors</span> 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.</span><br /><br />More details on how the class versioning feature works, and how it can be configured, will be added to the documentation wiki.<br /><br />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.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-62361129442533026132011-08-10T21:53:00.006+01:002011-08-10T22:12:13.287+01:00Impala 1.0.1 releasedI 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 <a href="http://code.google.com/p/impala/issues/list?can=7&q=label%3AMilestone-Release1.0.1&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary+Component&y=milestone&cells=tiles">this list</a>.
<br />
<br />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 <a href="http://www.realtimedespatch.co.uk/">Realtime Despatch</a>. 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.
<br />
<br />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.
<br />Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-4134698190469453272010-05-20T16:21:00.003+01:002010-05-20T16:50:38.524+01:00Impala Code Jam in London in London on May 26thNext 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.<br /><br />More details on the Code Jam are available <a href="http://www.jroller.com/javawug/entry/javawug_projam_3_impala_framework">from the JavaWUG announcement</a>.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-38470358440970443672010-05-12T10:10:00.000+01:002010-05-12T10:10:57.195+01:00Some further comments on the 1.0 releaseI'd like to make some comments about the timing of the <a href="http://impalablog.blogspot.com/2010/05/impala-10-final-released.html">1.0 final release of Impala</a>. 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.<br /><br />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 <span style="font-style: italic;">right</span> - 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.<br /><br />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.<br /><br />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.<br /><br />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.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-15223658094729710252010-05-12T09:38:00.007+01:002010-05-12T09:58:27.097+01:00Impala 1.0 final releasedI am pleased to announce the <a href="http://www.impalaframework.org/">1.0 final release of Impala</a>.<br /><br />Impala is a dynamic, modular productivity framework built around Spring. The aim of Impala is to extract every last ounce of productivity and flexibility out of your Spring development environment, while at the same time remaining true to the principles that made Spring popular in the first place - simplicity and testability.<br /><br />Impala offers instantaneous redeployment of parts of your application, dramatically improving build/deploy/test cycle times. Impala supports on the fly 'drop-in' of new application functionality - including web modules - without requiring an application restart and without requiring any changes to existing application code or configuration.<br /><br />With Impala you can achieve the productivity benefits of a modular approach to application development. When using Impala, you no longer need to work with application contexts which contain hundreds of bean definitions. Instead, you break your application down into smaller, manageable chunks. You no longer need to put up with the ever-increasing complexity and tangled interdependencies which come with a monolithic approach to application development. Instead, you develop your application in a loosely coupled way, with a clean distinction between application's interfaces and implementation components.<br /><br />With Impala it is much easier to mix and match features for particular environments, which is particular useful for applications which may need to be deployed with different features and configurations on a per-environment basis. Writing integration tests with Impala is a doddle, because setting these up is simply a matter of selecting the modules you want to include in your tests.<br /><br />Impala works with all the technologies you would expect in the Spring world - Hibernate, Quartz, JMX, etc. - without requiring any special plugins to be written for those technologies. It also supports - in most cases without modification - web applications using a variety of web frameworks, from Struts to JSF to Tapestry and others. A lot of work has been put into making Impala elegantly support modular web applications, allowing for modular vertical web application 'slices', rather than just a modular back end.<br /><br />Impala works straight out of the box using a plain Eclipse installation (no fancy plugins required). It has a built-in build system which you can optionally use, based on Ant, and also integrates nicely with Maven.<br /><br />With Impala, you can take your Spring-based application development to a new level of ease and sophistication, with remarkably few changes to the way you write applications.<br /><br />See the full list of <a href="http://code.google.com/p/impala/issues/list?can=7&q=label%3AMilestone-Release1.0">issues covered in this release</a>.<br /><br />With Impala 1.0 released artifacts are also available in the Maven central repository. See <a href="http://repo1.maven.org/maven2/org/impalaframework/">http://repo1.maven.org/maven2/org/impalaframework/</a>.<br /><br />If you like Impala and would like to support the project, please take a look at this page: <a href="http://code.google.com/p/impala/wiki/GetInvolved">http://code.google.com/p/impala/wiki/GetInvolved</a>.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-27261222454375414702010-04-25T19:56:00.002+01:002010-04-25T19:57:32.091+01:00Impala 1.0 RC4 releasedI am pleased to announce the release of Impala 1.0 RC4.<br /><br />Impala 1.0 RC4 was originally supposed to be the 1.0 final release. However, due to a few more than expected changes in this release, it was decided to have one last release candidate prior to 1.0 final.<br />The main changes in this release are:<br /><ul><li>simplifications and enhancements in the mechanism for mapping web requests to modules, allowing for more intuitive arrangements of JSPs and resources within modules.</li><li>modification of the starter application to use the multi-web module mechanism out of the box, as this is the recommended approach for building Impala web applications.</li><li>the addition of Javadocs to the build artifacts (this is now required for artifacts deployed to the Maven central repository via Sonatype's infrastructure).</li></ul><br />For more information on this release see: <a href="http://code.google.com/p/impala/wiki/Release1_0RC4Announcement">http://code.google.com/p/impala</a><a href="http://code.google.com/p/impala/wiki/Release1_0RC4Announcement">/wiki/Release1_0RC4Announcement</a>.<br /><br />Phil Zoio<br /><br />Impala Home: <a href="http://impala.googlecode.com">http://impala.googlecode.com</a>Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-19327710796369574562010-04-05T21:06:00.000+01:002010-05-04T20:32:55.457+01:00Seven ways in which Impala makes Spring development more productive<span>Impala is a modular, dynamic <span style="font-style: italic;">productivity</span> framework. The principal aim of Impala is to help developers extract every ounce of productivity out of the Spring development environment, while remaining true to the original Spring premise of simplicity and testability. The result is a much more productive Spring application development than you might think possible.<br /><br />Here's how Impala lets you be more productive when working with Spring.<br /></span><span style="font-weight: bold;"><span style="font-weight: bold;"><br /></span></span><span style="font-weight: bold;">1. Virtually instantaneous build/deploy/test cycles</span><br /><span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"><br /></span></span></span><span><span>For typical Java applications, redeploying a change requires redeploying the whole application. Not with Impala. Only the affected parts of the application need to be deployed. This leads to virtually instantaneous build/deploy/test cycles, as the granularity of redeployment is typically very small relative to that of the application as a whole. You don't need to sit around for ages waiting for your whole application to load.<br /></span></span><span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"></span><br /></span></span><span style="font-weight: bold;">2. Automatic modification detection and redeployment</span><br /><br />When you make a change to an Impala web application running in Eclipse, Impala can automatically pick up which parts of the application have changed, and redeploy those parts of your application without any user intervention. This removes the need for a manual step to perform this task. Impala gives you control over what resources are monitored for changes, how frequently resources are checked for modification, etc.<br /><br /><span style="font-weight: bold;">3. No explicit build step required</span><br /><br />When writing typical Java web applications using Eclipse, in many projects there is an extra build step required to package your applications in order to deploy them. Not with Impala. Eclipse automatically compiles your classes for you incrementally in the background. The project structure conventions for Impala mean that this sufficient, and that no extra build steps are required during development.<br /><br />Of course, you can do a regular WAR build when required for packaging for a production environment.<br /><br /><span style="font-weight: bold;">4. You can write your integration tests interactively</span><br /><br />Writing Spring integration tests can be slow, particularly for monolithic single module applications. Impala allows you to write integration tests interactively. You can write and run integration tests using an interactive console within Eclipse. If making changes to your application between test runs, you simply redeploy the changed modules. If you're simply changing your test, you don't need to do anything special as changes to your test class will automatically be picked up on the fly. All of this leads to a much more rapid build/deploy/test cycle when writing integration tests than would be possible otherwise.<br /><br /><span style="font-weight: bold;">5. Suites including integration tests run super-efficiently</span><br /><br />When running a suite of integration tests, modules needed by successive tests are loaded incrementally and remain available for subsequent tests run as part of the same suite. There is no need for continually starting and stop Spring application contexts, which can really slow down the execution of integration tests.<br /><br />All of this makes test suite execution really fast, making Impala very friendly to use in environments where developers are expected (as they should be) to run the full project test suite before each commit to the version control system.<br /><br /><span style="font-weight: bold;">6. Setup is very simple</span><br /><br />For a developer getting started on an existing project using Impala, it is really as simple as "check out and go" - simply check out the project files and starting writing and deploying the application within the IDE.<br /><br />If you're starting a new project, this too is easy, as Impala provides a script which allows you to set up a simple, working application by executing a couple of commands.<br /><br /><span style="font-weight: bold;">7. Easy to use build and dependency management support if you need it</span><br /><br />Impala works with Maven, but if you're not a fan of Maven, Impala also features a reusable build system which saves you having to write create your own build from scratch. Impala also gives you a simple way to pull third party library jars and source from Maven repositories, even if you aren't using Maven as your build system.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-63553295972412109912010-03-12T14:37:00.004+00:002010-03-12T14:44:30.689+00:00Impala 1.0 RC3 releasedI am pleased to announce the release of Impala 1.0 RC3. Impala 1.0 RC3 is the final release candidate prior to the official 1.0 release. If no significant issues are raised against this released, it is envisaged that there will be virtually no changes in the subsequent 1.0 final release.<br /><br />This release contains a number of enhancements:<br /><ul><li>simplifications making it easier to migrate existing Spring-based projects to use Impala. It is now possible to run Impala as part of an existing virtually unchanged traditional Spring web application, which should significantly simplify the task of migrating an existing Spring application to use Impala.</li><li>support for JSPs deployed within individual web modules. Prior to 1.0 RC3, JSPs need to be contained within the web application folder. With 1.0 RC3 it is now possible to completely modularise the web elements of a JSP-based web application.</li><li> support load time weaving of aspects created using AspectJ. </li><li> various other minor features and bug fixes.</li></ul>Also, Impala 1.0 RC3 is available in the Maven central repository for the first time.<br /><br />For more information on this release see: <a href="http://code.google.com/p/impala/wiki/Release1_0RC3Announcement.">http://code.google.com/p/impala/wiki/Release1_0RC3Announcement.</a><br /><br />In the next couple of weeks, I plan to add more documentation on how to get Impala working nicely with Maven, and how to migrate an existing Spring-based project to use Impala.<br /><br />Please don't hesitate to report any issues you may encounter, which you can do on the Impala issue tracker: <a href="http://code.google.com/p/impala/issues/list">http://code.google.com/p/impala/issues/list</a>.<br /><br />Phil Zoio<br /><br /><a href="http://impala.googlecode.com"> http://impala.googlecode.com</a>Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-30676103932430517172010-02-03T07:12:00.001+00:002010-02-03T09:28:16.587+00:00OSGi and Enterprise Java dynamic modularity after Spring dm ServerThe key message to be taken from SpringSource's decision to hand last month their Spring OSGi projects (Spring DM and dm Server) to the Eclipse foundation is the following: that OSGi is not ready for adoption by the mainstream of enterprise Java. Reality has finally dawned!<br /><br />According the <a href="http://blog.springsource.com/2010/01/12/dm-server-project-moves-to-eclipse-org/">announcement from Adrian Colyer</a>, CTO of SpringSource:<br /><blockquote><em>For a mainstream development team though, who just want to build an enterprise application as quickly as possible, and with as little hassle as possible, the costs currently associated with adopting enterprise OSGi can outweigh the short-term benefits</em>. This situation needs to be addressed before enterprise OSGi can become the de-facto approach for <em>mainstream enterprise</em> <em>application</em> development.<br /></blockquote>While SpringSource will no doubt continue to support OSGi, the extent to which it will continue to provide resources to the <span style="font-style: italic;">donated</span> projects is far from certain. What is more clear, though, is it will no longer be wielding it's own considerable influence within the industry to shepherd its user base <span style="font-style: italic;">en masse</span> towards OSGi.<br /><br />This is a good thing. Firstly, the obsession with OSGi has distracted the community away from practical efforts which could work more comfortably within the existing enterprise Java model. Hopefully that obsession will go away, or at least be limited to those already converted to the OSGi way. Secondly, from a purely selfish, egotistical point of view, I feel vindicated. For years, I have been saying that OSGi is <a href="http://impalablog.blogspot.com/2008/05/spring-application-platform-is-it-big.html">too complex for the Java mainstream</a>. For years, I have been beaten over the head by a small group of hardcore OSGi evangelists who have persistently used the argument that if SpringSource is betting on OSGi, then it must be a good thing for everyone else, and that any alternative approach does not warrant any consideration. The bet has failed, and this argument has now fallen rather flat. If SpringSource, with all the credibility it has generated through the Spring Framework, all its intellectual and marketing muscle, and all the effort and expense it has incurred, cannot make work OSGi for mainstream enterprise Java, then no one else can.<br /><br />But all of this is also points to a real missed opportunity. The fact remains that <span style="font-weight: bold;">Spring users still need a modularity solution</span>. They need a way of being able to take advantage of the best of what dynamic modularity has to offer - dynamically composable software with genuine decoupling between parts of the application, and rapid build/deploy/test cycles during development - without having to take on all the complexity of the full-blown OSGi approach. This need still exists, and will not go away. As Adrian suggests, this need will not be served by OSGi without some fundamental simplifications, something I could not imagine happening any time soon.<br /><br />In the meantime, I have invited SpringSource to engage more with Impala. While they have flirted with the idea in the last few months, perhaps even seriously, they have backed away from it for now. In view of recent history, it is not that surprising. Imagine the uproar that would ensue among the OSGi zealots if SpringSource were to go down that route. It doesn't bear thinking about.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com7tag:blogger.com,1999:blog-1375633167426904536.post-30578530921406874302010-01-04T14:54:00.003+00:002010-01-04T14:56:36.562+00:00Impala 1.0 RC2 releasedI am pleased to announce the release of Impala 1.0 RC2. With this release, support for Maven is introduced for the first time, along with various other enhancements, refactorings and bug fixes, including:<br /><ul><li>simplifications to the default project structure, making it more intuitive and Maven-friendly</li><li>a dynamic properties Spring namespace, making it easier to support properties which can be injected and dynamically updated without requiring module or application reloads.</li><li>further refinements to the mechanisms for supporting multi-module web applications.</li><li>initial support for Spring 3.0. </li></ul>For more information on this release see: <a href="http://code.google.com/p/impala/wiki/Release1_0RC2Announcement.">http://code.google.com/p/impala/wiki/Release1_0RC2Announcement.</a><br /><br />Cheers,<br />Phil ZoioPhil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-15580569062033526002009-11-26T08:51:00.001+00:002009-11-26T09:15:02.344+00:00Don't let OSGi put you off modularityIf you are interested in the ideas of modularity, there is quite a good chance you have looked at OSGi. But there is also quite a good chance that you have been put off by the extra development overhead required to set up and maintain OSGi-based applications.<br /><br />If this is the case for you, my message is this: <span style="font-style: italic; font-weight: bold;">don't let fact that you are put off by OSGi put you off the ideas of modularity</span>. Modularity is a bigger, more important and valuable idea than any particular technology. The ability to modularise an application can massively improve your application's ability to absorb complexity as new features and components are added, which in turn means that you remain much more productive as your application grows. It reduces the rate of entropy in your system, extending its potential life span, which of course if great for business.<br /><br />This kind of modularity is one of the fundamental benefits of <a href="http://code.google.com/p/impala/">Impala</a>. Also, because Impala's modules are dynamically reloadable, and you also get dynamic redeployment of small parts of your application, allowing you to greatly <span style="font-weight: bold;">accelerate application development</span>, maintain high levels of productivity, and retain high levels of code and functionality reuse as you application grows.<br /><br />Impala does not solve all of the problems solved by OSGi. Notably, it does not provide versioning of third party libraries. However, it solves most of the important ones relevant for day to day development. Fundamentally, it allows you to modularise your <span style="font-style: italic;">application</span>, without having to worry about micro-managing the dependencies of third party libraries in your application. Don't get me wrong - there are times when this capability can be important, especially for very large projects with large budgets and teams. But certainly not for every project, and probably not even for the typical one.<br /><br />One way to think of choice is to look at the graph below.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOnS3v9lmbzOFjv7u0PSQllGB-Hj0RVvmoXmaU0cH7lqIRtSnlqXnTq_a2oFWL2gqm_oETu-zYWhrRcs67S2NRTIYV6VkVJiuWVrXa3YZArJkF-t7pGXh1ZEmLrHPvFKGsuLc3enWaUtA/s1600/complexity.png"><img style="cursor: pointer; width: 400px; height: 261px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOnS3v9lmbzOFjv7u0PSQllGB-Hj0RVvmoXmaU0cH7lqIRtSnlqXnTq_a2oFWL2gqm_oETu-zYWhrRcs67S2NRTIYV6VkVJiuWVrXa3YZArJkF-t7pGXh1ZEmLrHPvFKGsuLc3enWaUtA/s400/complexity.png" alt="" id="BLOGGER_PHOTO_ID_5407224607061697218" border="0" /></a><br />The basic idea behind modularity is that the growth in complexity of your application slows as your application grows in size, compared to applications without modules. This applies both for Impala and OSGi-based applications. The difference is that because the barriers to entry are lower for Impala-based applications, the benefits kick in sooner, and accumulate for longer over the duration of the project, greatly reducing the overall cost of complexity over the lifetime of a project.<br /><br />So, don't shy away from modularity just because OSGi looks complex. The benefits of modularity are too valuable, and an alternative like Impala make these attainable with fewer headaches.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com2tag:blogger.com,1999:blog-1375633167426904536.post-37346691071960196292009-11-05T20:19:00.002+00:002009-11-05T20:45:29.942+00:00The granularity of change in dynamic Java web applicationsWhen writing Java web applications, you are continually making changes to your application, and to be productive you need to be able to deploy and test these changes quickly. The kinds of changes you make are of all sorts: from changes to resources to changes to markup templates to changes in the way your application is wired to changes in the code itself.<br /><br />The point of this article is that not all changes are equal, both in their frequency and in the difficulty in applying them dynamically in a running web application. Let's go through some examples, and how the changes might be applied in different types of frameworks:<br /><br /><span style="font-weight: bold; font-style: italic;">1. Static resources</span><br />The simplest kinds of changes for any dynamic web framework to apply are those of static resources - images, JavaScript files, page templates etc. That's because these kinds of artifacts are inherently free of dependents.<br /><br /><span style="font-weight: bold; font-style: italic;">2. Application configuration</span><br />Configuration consists of things such as settings for data sources, mail servers, etc, as well as switches in your application itself. While it is in general possible to reflect these kinds of changes <span style="font-style: italic;">dynamically</span>, there is a cost. For example, if you are using database connection pooling, pointing to a different data source dynamically is a non-trivial exercise. Also, if your application checks particular application settings at source each time the affected functionality is used, then the system is more dynamic, but also less performant. By contrast, if you only load particular settings at startup (for example using wired in property placeholders in a Spring application context), the application is more efficient but is more likely to require reloads to reflect changes.<br /><br /><span style="font-weight: bold; font-style: italic;">3. Application wiring</span><br />Application wiring is a configuration of sorts, but relates more to how parts of the system are composed or wired together to form the whole application. In a Spring application, the application wiring is simply your Spring configuration.<br /><br />In general, changes to application wiring requires reloads. There are special cases where this doesn't apply. For example, you could introduce new Spring beans without reloading the application context. Changes to existing beans and their collaborators are harder to make.<br /><br /><span style="font-weight: bold; font-style: italic;">4. Scripts</span><br />Scripts are programs in your application which by definition can be altered without having to reload your entire application or even significant parts of it. However, a scripting infrastructure needs to be in place to allow changes to scripts to be introduced, recognised and reflected in the system.<br /><br /><span style="font-style: italic; font-weight: bold;">5. Application code</span><br />Application code in a Java application are your Java classes. Actually, considering this group as a single category is an oversimplification, especially in a dynamic module system, where making changes to core interfaces and domain classes will impose much greater requirements in terms of reloading than peripheral or implementation classes with fewer dependants.<br /><br /><span style="font-weight: bold; font-style: italic;">6. Third party libraries</span><br />The libraries in your application are the jar files containing all the third party dependencies.<br /><br /><span style="font-weight: bold;">The challenge for frameworks</span><br /><br />The key productivity challenge with a dynamic application framework is to make it as easy as possible to make the kinds of changes you need to make, while at the same time keeping the framework as lightweight as possible. In the next section I take a look a number of technology stacks, what they do to make different types of reloading possible, what they get wrong, and what they get right.<br /><br /><span style="font-weight: bold; font-style: italic;">A. Traditional Java web application</span><br />A traditional Java web application might consist, for example, of a Struts or JSF front end, Hibernate back end, all wired together using Spring.<br /><br />The traditional Java web application has no problem reloading static resources without having to reload any other part of the application. Most web containers are able to reload an entire web application, including third party libraries, Java code, application wiring etc.<br /><br />The problem is they are not much good at reloading any finer grained changes. Any changes you make to your application wiring or code will normally require a full application reload.<br /><br /><span style="font-weight: bold; font-style: italic;">B. Scripted applications</span><br />Scripted applications are based on scripting languages such as Groovy (Grails) and JRuby (Rails). As well as explicitly providing support for reloading capabilities, these frameworks rely on the fact that all application functionality is in scripts rather than in compiled Java code, making fine grained reloading of parts of the application possible. The downside (if you think of it this way) is that you have to work with scripted code without any of the type safety checking of a statically typed language such as Java.<br /><br /><span style="font-style: italic; font-weight: bold;">C. OSGi applications</span><br />OSGi applications offer a fairly comprehensive solution to the reloading problem. All artifacts within the application, from resources to application code to libraries are contained within modules which are treated in a more or less uniform manner by the OSGi container. This is a strength, but it is also a weakness. The strength is that it does allow third party libraries to be reloaded in a fine grained way. The weakness is that in your high level view of the application, OSGi doesn't really allow you to easily distinguish between the parts of your application which should be easy to reload - e.g. resources - and the parts which are harder to reload, but are changed much less frequently during the lifetime of the application (third party libraries).<br /><br /><span style="font-weight: bold;">What about Impala?</span><span style="font-weight: bold; font-style: italic;"><br /><br /></span>Impala tries to find the right balance in the strengths of the various approaches. Resource reloading works as with traditional Java applications - nothing special needs to take place. Impala includes mechanisms which make it easier to change configurations dynamically without requiring any module reloading. For changing static configuration and application wiring, Impala allows you to reload parts of your application at exactly the right granularity. If only a single module is affected, then only that module needs to be reloaded. If the change affects core interfaces, then the reload will automatically ripple through to the right dependent modules.<br /><br />Impala even allows you to dynamically change the structure of modules within the application. Unlike OSGi, it doesn't support reloading of third party libraries. For this, an entire application reload is required. However, Impala's approach does your application modules in central focus, which is important as these are the normally parts of your application which change most frequently.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com6tag:blogger.com,1999:blog-1375633167426904536.post-88213868606368164962009-11-01T20:32:00.004+00:002009-11-01T20:39:36.408+00:00Slides for Impala talk at the Server Side Europe in PragueI'm pleased to say that <a href="http://javasymposium.techtarget.com/html/frameworks.html#PZoioImpala">my talk at The Server Side Java Symposium</a> in Prague went well and was apparently well received. There definitely is a growing interest in the ideas of modularity and how the benefits of modularity can be achieved in practice.<br /><br />I've posted a copy of my slides for the talk <a href="http://impala.googlecode.com/svn/wiki/presentations/tss-europe.pdf">here in PDF format</a>. The document contains the slides that I presented, as well as quite a few which were held in reserve but weren't actually presented during the talk.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-20783652841061033622009-10-14T20:15:00.002+01:002009-10-16T11:12:49.426+01:00How to make your Spring wirings more manageableWhen Spring first came along it was a breath of fresh air - a clever way to wire up applications which did not rely on the use of all sorts of singletons all over the place. (I still remember what it was like working that way, and shudder at the thought.) The idea was simple: let classes in the application just do their own job, but leave the business of figuring out how to get collaborators to the IoC container, with the help of some XML configuration. No longer did your application code did not have to deal the messy business of having to resolve their own dependencies.<br /><br />OK, we've solved the problem with the code, but <span style="font-weight: bold; font-style: italic;">the job isn't completely done</span>. Actually, the problem has shifted onto managing Spring wirings.<br /><br /><span style="font-weight: bold;">The problem with managing Spring wirings<br /><br /></span>Applications necessarily get big. You end up having to write a lot of XML. So while your code may stay nice and clean, you end up with some tricky questions about how to manage this part of your application. Of course, here you try to be as "modular" as you can, putting DAOs together, infrastructure related beans together, etc. You try to identify vertical slices for your application and put beans relating to particular vertical slices together.<br /><br />The problem is that for all the bean definitions that exist in your application, some groups are inherently coupled, while others are inherently free of coupling. <span style="font-style: italic;">In a vanilla Spring application, there is no way to express these dependencies at a system level. </span>So it is very easy for your application wiring to become an unnecessarily fragile collection of invisible dependencies, liable to break in unexpected ways when any rearrangement takes place.<br /><br /><span style="font-weight: bold;">Autowiring, namespaces and class path scanners don't necessarily help</span><br /><br />Then of course there is the<span style="font-style: italic;"> drudgery of editing XML </span>configuration files by hand. Personally, I think that is less of a problem, but Spring has gone to great lengths to free developers from some of this pain over the years, through the introduction of <span style="font-style: italic;">autowiring</span>, <span style="font-style: italic;">class path scanners</span>, and XML namespaces. I happily embrace all of the above as they reduce the amount of code I need to write, but they don't address the fundamental problem. They don't enhance one's ability to express dependencies between parts of your application at a system level, and where possible, to reduce these dependencies.<br /><br /><span style="font-weight: bold;">So how does Impala help?</span><br /><br />Remember how easy Spring seemed when we were working with just small applications? Impala allows you to keep your applications small, or at least keep them <span style="font-style: italic;">feeling small</span>. This is done through <span style="font-weight: bold; font-style: italic;">modules</span>. You can think of a module as a mini-application which is able to communicate with other mini-applications in the system through well defined mechanisms and through sharing common interfaces.<br /><br />The Spring configuration for each module remains pretty small. If it starts getting too big, then its a good sign that some of it's functionality needs to be split off into another module. So within the module, you only need to deal with small configurations - <span>bite size chunks</span>.<br /><br />You can configure beans within a module however you like - through plain Spring XML, custom namespaces or through annotations. If your module needs to use functionality from other parts of the system (as most will), then you can import services directly from the <span style="font-style: italic;">shared service registry </span>(as long as the service has been exported using an interface or class visible to the current module). If necessary, you can allow your module to depend directly on another module, either as a dependent or as a direct child.<br /><br />If you need to compose your application in different ways <span style="font-style: italic;">according to environment</span><span> </span>or customer, that's easy too. Simply change which modules your deploy, or you can even vary the configuration of within a module according to requirements.<br /><br />You no longer need to wait ages for <span style="font-style: italic;">integration tests</span> to load, because you can easily create integration tests which consist simply of the modules you need to use.<br /><br />And you get the benefits of much <span style="font-style: italic;">more productive</span>, responsive development environment because each of these modules can be reloaded on the fly, either individually, in groups, or as a whole - and this applies whether you are running integration tests or running your application on a web container.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-60477767665009207942009-10-06T08:58:00.002+01:002009-10-06T09:01:29.802+01:00Talk at the Server Side Europe in PragueI am doing a <a href="http://javasymposium.techtarget.com/html/frameworks.html#PZoioImpala">talk on Impala at The Server Side Europe</a>'s conference in Prague, which is taking place on October the 27th and 28th. Really looking forward to it, especially as I used to be a regular visitor of Prague in the early 90s when I was living in Germany.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-14157370681039729592009-10-03T14:52:00.000+01:002009-10-03T20:14:00.712+01:00Why web.xml makes it hard to write modular web applicationsIn a typical Java enterprise application, the <span style="font-style: italic;">web.xml</span> is used to define servlets and filters, which are among the main entry points into your application from the outside world. Since <span style="font-style: italic;">web.xml </span>cannot be reloaded, added to or modified without reloading the entire application, it is not a very convenient place to host application configuration and definitions in a dynamic module applications.<br /><br />Another related problem is the limitations of the request mapping capability of web containers as defined by the current servlet specification. Currently, these make it possible to map requests to servlets and filters using an exact match (e.g. <span style="font-style: italic;">/myservlet/myresource</span>) or either a prefix and wildcard match (e.g <span style="font-style: italic;">/myservlet/*</span>) or using a suffix wildcard match (e.g. <span style="font-style: italic;">*.do</span>). It doesn't allow you to use a combination of prefix and suffix wildcard matches. This means that you cannot, for example, use the path (<span style="font-style: italic;">/myprefix/*</span>) to match application URLs, and at the same time allow your application's CSS files to be accessible in a resource such as <span style="font-style: italic;">/myprefix/styles.css</span>.<br /><br /><span style="font-weight: bold;">Multi-module web applications in Impala</span><br /><br />One of biggest changes in the recent 1.0 RC1 release of Impala is the ability to write web applications which are less reliant on <span style="font-style: italic;">web.xml</span>, allowing both dynamic registration of modules containing servlets and filters, and at the same time solving the path mapping limitation described in the previous paragraph.<br /><br />In an Impala application, you cannot do away with the <span style="font-style: italic;">web.xml </span>altogether. However, you can reduce the request handlers defined in <span style="font-style: italic;">web.xml</span> to the following:<br /><pre class="brush:xml"><br /><filter><br /><filter-name>web</filter-name><br /><filter-class>org.impalaframework.web.spring.integration.ModuleProxyFilter</filter-class><br /><init-param><br /> <param-name>modulePrefix</param-name><br /> <param-value>urlmapping-web</param-value><br /></init-param><br /><load-on-startup>2</load-on-startup><br /></filter><br /><br /><filter-mapping><br /><filter-name>web</filter-name><br /><url-pattern>/*</url-pattern><br /></filter-mapping><br /></pre>In the example above, the <span style="font-style: italic;">ModuleProxyFilter</span> captures requests and routes them into Impala modules. The mapping rules which determine which modules service which requests are contained within modules. Here's an example from the <a href="http://code.google.com/p/impala/wiki/SamplesURLMapping">URL mapping sample</a>:<br /><pre class="brush:xml"><br /><web:mapping><br /><web:to-module prefix = "/webview" setServletPath="true"/><br /><web:to-handler extension = "htm" servletName="urlmapping-webview" filterNames = "characterEncodingFilter,sysoutLoggingFilter"/><br /><web:to-handler extension = "css" servletName="urlmapping-resources"/><br /></web:mapping><br /><br /><web:servlet id = "urlmapping-webview"<br />servletClass = "org.impalaframework.web.spring.servlet.InternalModuleServlet"/><br /><br /><web:servlet id = "urlmapping-resources"<br />servletClass = "org.springframework.js.resource.ResourceServlet"<br />initParameters = "cacheTimeout=10"/><br /><br /><web:filter id = "characterEncodingFilter"<br />filterClass = "org.springframework.web.filter.CharacterEncodingFilter"<br />initParameters = "forceEncoding=true,encoding=utf8"><br /></web:filter><br /><br /><web:filter id = "sysoutLoggingFilter"<br />filterClass = "org.impalaframework.urlmapping.webview.SysoutLoggingFilter"><br /></web:filter><br /></pre><br />This module defines a number of servlets and filters who's life cycles are tied to that of the module, rather than that of <span style="font-style: italic;">web.xml</span>. They can be dynamically registered and removed, and don't require an application restart. The modules can contain all the classes and resources necessary to service requests, without relying on the presence, for example, or resources such as JavaScript files on the context path (e.g. in the <span style="font-style: italic;">WEB-INF</span> directory).<br /><br /><span style="font-weight: bold;">What about Servlet 3.0?</span><br /><br />The changes described above are very much in line with the changes in the forthcoming Servlet 3 specification which allow servlets and filters to be added via web.xml fragments, and via annotations. It will also allows you to add Servlet and Filter instances programmatically. I expect that Impala will be able to take advantage of this mechanism when it becomes available, perhaps by wrapping the Servlet or Filter to ensure that it is associated with the originating module's class loader, and not the web application class loader. This will have the advantage of allowing Impala to make use of the web container's invocation infrastructure while still supporting dynamic servlet or filter registration.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-51744783730828921752009-09-24T14:17:00.006+01:002009-09-24T14:40:23.773+01:00Impala 1.0 RC1 releasedI am pleased to announce the release of <a href="http://code.google.com/p/impala/">Impala</a> 1.0 RC1.<br /><br />With this release, Impala is now feature complete for the 1.0 final release, with only minor enhancements and bug fixes planned before this happens.<br /><br />Impala 1.0 RC1 contains a number of big feature improvements from the previous release:<br /><ul><li>a more powerful and flexible mechanism for mapping web requests to and within modules, making it easier to build truly <a href="http://code.google.com/p/impala/wiki/WebModuleBasedHandlerRegistration">multi-module web applications</a>.</li><li>a new Spring <a href="http://code.google.com/p/impala/wiki/NamespaceWebReference">web namespace</a> for registering servlets, filters and other web artifacts in Impala web modules.</li><li>enhancements to make the automatic module reloading mechanism more robust and suitable for applying in production environments.</li><li>various other minor bug fixes and enhancements, particularly in the areas of build, dynamic services and class loading.<br /></li></ul>For more information on this release see <a href="http://code.google.com/p/impala/wiki/Release1_0RC1Announcement">http://code.google.com/p/impala/wiki/Release1_0RC1Announcement</a>.<br /><br />Enjoy!Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-55834989136059686162009-09-06T19:13:00.045+01:002009-09-17T14:13:41.184+01:0010 reasons for Spring users to try ImpalaIf you are a user of the Spring framework and you haven't tried Impala, I hope to convince you in this entry that you are really missing out.<br /><br />These are the reasons why I make this claim.<br /><br />When Spring was introduced 2004-2005, it brought a big shift in the frontier of Java enterprise software development, offering solutions to many of the challenges faced by developers in a way which other technologies before, notably EJB, had conspicuously failed. Spring is still very much a valid technology in today's environment, but the frontiers have shifted.<br /><br />One shift is in the increasing recognition of the shortcomings of the Java language itself, and the need for an eventual replacement as the premier JVM language. Another shift is the increasing awareness of the need for modularity in application development. My view is that without the backing of a truly modular framework, it is almost impossible to build a large enterprise application which does not end up becoming unwieldy, difficult to manage, and slow to build and deploy. This more than anything else leads to the perception that Java is unproductive to work with.<br /><br /><span style="font-weight: bold;">1. Impala gives your project a massive productivity boost</span><br />The reason for this stems from Impala's dynamic reloading capability. When you make changes to an Impala application, you only need to reload the affected modules and their dependents. Indeed, you can set Impala up so that these modules will be reloaded automatically. This allows code/deploy/test cycles to be reduced to an absolute minimum. In some of the next few points we give some further examples of how Impala improves your productivity.<br /><br /><span style="font-weight: bold;">2. With Impala you can make your applications truly modular</span><br />Modularity is about removing all unnecessary coupling between parts of your application, and is essential for building large applications which don't grow exponentially in complexity as they grow linearly in size.<br /><br />With Impala and other dynamic modularity frameworks, modularity is achieved through a separation of interface and implementation which is just not possible in traditional Java applications. With Impala, modularity is enforced at the class loader level.<br /><br />Impala makes it simple to deploy multiple flavours of the same application simply by choosing which modules to deploy. Impala gives you mechanisms for configuring individual modules, so that you can support different deployment options in a clean and simple way.<br /><br /><span style="font-weight: bold;">3. Impala works "out of the box"</span><br />I can't resist using this term because it features often in Rod Johnson's books. If you try any of the Impala examples, you will notice that all you typically need to do is to check out the code, then run it in your IDE. (If a database is involved, you may need a little extra setup there.) There is no need for any extra build steps, installation of third party environments, containers, etc. It's all self-contained.<br /><br /><span style="font-weight: bold;">4. With Impala, Spring integration testing is a doddle</span><br />Impala makes it really simple to write Spring integration tests. Gone is the need for convoluted test application context definitions such as<br /><pre class="brush:java"><br />new ClasspathApplicationContext(new String[] {<br />"config-context.xml",<br />"dao-context.xml",<br />"config-context.xml",<br />"some-context-which-you-you-need-for-your-test.xml",<br />"some-context-which-you-you-dont-need-for-your-test.xml",<br />"another-context-which-you-you-dont-need-for-your-test.xml",<br />}<br /></pre><br />With Impala, all you need to do in a typical integration test is to specify which modules you want to include (dependent modules get included automatically), and use Impala's API to access beans either from the root or one of the module application contexts. For example:<br /><pre class="brush:java"><br />public class InProjectEntryDAOTest extends BaseDataTest {<br /><br />public static void main(String[] args) {<br /> InteractiveTestRunner.run(InProjectEntryDAOTest.class);<br />}<br /><br />public void testDAO() {<br /> //get the entryDAO bean from the root module<br /> EntryDAO dao = Impala.getBean("entryDAO", EntryDAO.class);<br /> ... test methods<br />}<br /><br />public RootModuleDefinition getModuleDefinition() {<br /> return new TestDefinitionSource("example-dao", "example-hibernate").getModuleDefinition();<br />}<br /><br />}<br /></pre><br />Tests work equally well whether you are running them interactively (without the need to reload the entire application or even any part of it between successive test runs), or whether you are running it as part of a suite (in which case the application modules are incrementally loaded as required). In both cases, running integration tests is very efficient, allowing you to be much more productive while still practicing TDD.<br /><br /><span style="font-weight: bold;">5. With Impala you can write truly multi-module web applications</span><br />A big barrier to truly modular web applications is the reliance on <span style="font-style: italic;">web.xml</span>, because changes to <span style="font-style: italic;">web.xml</span> require a full application reload. The forthcoming release of Impala allows you to define servlets and filters within the modules themselves, with their life cycle tied to that of the containing module. It also allows you to map requests with arbitrary URL path prefixes to individual modules. Once within a module, requests can be mapped to filters and servlets based on file extension.<br /><br />These capabilities allow you to create a web application tier which is truly modular: you can package all of the filters, servlets, controllers, templates, images, Java script files required to service URLs with a particular prefix into the module jar itself. Indeed, you can even reduce your web.xml filter and servlet declarations to the following:<br /><pre class="brush:xml"><br /><filter><br /> <filter-name>web</filter-name><br /> <filter-class>org.impalaframework.web.spring.integration.ModuleProxyFilter</filter-class><br /> <init-param><br /> <param-name>modulePrefix</param-name><br /> <param-value>urlmapping-web</param-value><br /> </init-param><br /> <load-on-startup>2</load-on-startup><br /></filter><br /><br /><filter-mapping><br /> <filter-name>web</filter-name><br /> <url-pattern>/*</url-pattern><br /></filter-mapping><br /></pre><br />See the <a href="http://impala.googlecode.com/svn/trunk/urlmapping-sample/urlmapping-web/context/WEB-INF/web.xml">web.xml</a> from the <a href="http://code.google.com/p/impala/wiki/SamplesURLMapping">URL mapping sample</a> for the full example.<br /><br /><span style="font-weight: bold;">6. Impala does not reinvent the Spring programming model</span><br />Spring has been a huge success for a good reason - because it offers a much simpler programming model than was offered before. Spring offers a great solution for dependency injection as well as for making otherwise key technologies - transactions, AOP, JMX, remoting, etc - accessible or very simple to use.<br /><br />Impala does not reinvent the Spring programming module - within modules you will recognise all the artifacts familiar to Spring applications: collaborators wired together via dependency injection, configured using XML configuration files, annotations, etc. The big difference is that Impala gives you a well defined way for expressing relationships between modules within the application, allowing for simpler implementations of - and clear boundaries between - the constituent parts of a bigger application.<br /><br /><span style="font-weight: bold;">7. With Impala you can forget about the build (most of the time)</span><br />Impala allows you to develop your applications in a vanilla Eclipse environment without having to invoke any build scripts or do any extra environent setup to run your application. This makes getting new developers started on projects extremely simple. Simply check out and go.<br /><br />Of course, you will need to build for production environment. Impala includes an ANT-based build system which allows you to build either a WAR file or a Jetty-based standalone web application, which you simply unzip in the target environment and run.<br /><br /><span style="font-weight: bold;">8. Impala fundamentally simpler to use than OSGi-based alternatives</span><br />OSGi is a powerful technology, a very complete modularity solution. It is also quite a complex technology, requiring a non-trivial investment in time and energy to understand it, both conceptually and in its effect on the application environment.<br /><br />From a practical point of view, applying OSGi to enterprise environments is far from trivial, and involves solving a number of challenging technical problems. For example, many common Java libraries do not ship out the box in an OSGi-friendly way. Also, the use of the thread context class loader in many libraries poses a problem for OSGi-based applications.<br /><br />Solutions to these problems do exist, but they typically involve creating a more complex, more restrictive, or less familiar environment than required for traditional Java enterprise apps. Nothing comes for free. The question is whether it is worth paying the price.<br /><br /><span style="font-weight: bold;">9. Impala poses no extra requirements for third party library management</span><br />In terms of the management of third party libraries, Impala is no different from traditional Java applications. Third party library jars are bundled in the <span style="font-style: italic;">lib</span> directory of a WAR file. If you change a third party library, you will need to reload your application to apply these changes.<br /><br />Where Impala differs from traditional applications is the way that you manage application modules. In a WAR file, these will be bundled in a the <span style="font-style: italic;">modules</span> directory under <span style="font-style: italic;">/WEB-INF</span>.<br /><br />The relationship between modules can be hierarchical, or even in the form of a graph of dependencies. The important point is that modularity is applied to <span style="font-style: italic;">your application's code.</span> That is in my opinion the part which needs it most<span style="font-style: italic;"> </span>because that's the part of your application which changes frequently. If you are not sure whether you agree with this point, ask yourself the questions:<br /><ol><li>How often would you actually want to run multiple versions of the same third party library in the same application?</li><li>If you made changes to third party libraries in your application, how often would you want to apply these without restarting the application</li></ol>If your answer to these questions is "not very often" or "not at all", then you probably don't need the full blown form of modularity offered by OSGi.<br /><br />Some may regard the traditional approach to third party libraries as broken - but it is also very convenient when it works!<br /><br /><span style="font-weight: bold;">10. Impala is a practical solution for practical problems</span><br /><br />Impala did not evolve from an ivory tower view of how Java enteprise applications are supposed to be written. Instead, it was borne around two years ago out of the need to solve practical real world problems which were harming the productivity and maintainability of a large Java project. The most notable of these were the lack of any first class modularity in traditional Spring-based application development, and the slow build/deploy/test cycles arising from unwieldy integration tests.<br /><br />Impala has been designed and refactored to be simple and intuitive to work with, once you've grasped the basic concepts. It allows you to get the benefits of a modular approach to application development without many of the costs, and without being swamped by technobabble.<br /><br /><span style="font-weight: bold;">What are you waiting for?</span><br /><br />Working with Impala will give you the programmer's equivalent of a "spring in your step" - you will be amazed by how easily it is to get things done.<br /><br />So give it a go. Try one of the <a href="http://code.google.com/p/impala/wiki/RunningSamples">samples</a>, read the <a href="http://code.google.com/p/impala/wiki/GettingStarted">tutorial</a>, or kick start your own <a href="http://code.google.com/p/impala/wiki/FirstSteps">application</a>, and let me know how you get on.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-73285450870453678832009-09-01T17:16:00.003+01:002009-09-01T19:05:50.068+01:00Avoiding over eager reloading in ImpalaThe forthcoming version of Impala has new features which help to avoid "over-eager" reloading of modules, that is, module reloads which take place either unnecessarily and too frequently.<br /><br />If you run an Impala application within Eclipse you can have a running application automatically reload modules to reflect changes in your workspace. You do this by adding the line<br /><pre class="brush:plain"><br />#Automatically detect changes and reload modules<br />auto.reload.modules=true<br /></pre><br />to the file <span style="font-style: italic;">impala-embedded.properties</span>.<br /><br />This is really nice, because it means you can redeploy your application <span style="font-style: italic;">without having to do anything</span>, that is, no build step whatsoever.<br /><br />The trouble is, redeployment can get a bit overeager. For example, some changes will automatically get picked up without the need for redeployment, for example, my Freemarker web templates. Some changes you also want Impala to ignore completely, for example, changes which occur within your subversion (<span style="font-style: italic;">.svn</span>) directories.<br /><br />The next drop of Impala now contains a mechanism to filter which files get checked for modifications, via the auto.reload.extension.includes and auto.reload.extension.excludes. An example is shown below:<br /><pre class="brush:plain"><br />#Includes only files ending with context.xml and class<br />auto.reload.extension.includes=context.xml,class<br /></pre><br />With the setting above, only classes and files ending in context.xml will be checked for modifications, reducing the number of spurious reloads. You can also get complete control over the timing of reloads by specifiying a touch file.<br /><pre class="brush:plain"><br />use.touch.file=true<br />touch.file=/touch.txt<br /></pre><br />Using a touch file removes all spurious reloads, but does require an extra build step every time in order to update the timestamp of the touch file.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-89476794064381968352009-08-28T16:47:00.003+01:002009-08-28T17:15:11.367+01:00Spring Faces sample projectI recently put together a sample of Impala working with Spring Faces, that is, the combination of Spring Web Flow and JSF. The example is based on the Spring Faces <a href="http://richweb.springframework.org/swf-booking-faces/spring/intro">flagship sample</a>, a hotel booking application which uses JSF for persistence, and Spring Security for authentication/authorization.<br /><br />See <a href="http://code.google.com/p/impala/wiki/SamplesSpringFaces">instructions on how to run the sample</a> on the Impala wiki.<br /><br />I have to confess that none of the technologies used in this sample are personal favourites - I'm much more inclined towards Spring MVC, Hibernate on its own, and a more straightforward templating technology like Freemarker for the view layer. That being said, it was an interesting exercise, which threw up some interesting challenges, and also important to verify that Impala could work nicely with each of these technologies without a gargantuan amount of effort on the user's part.<br /><br />One of these challenges was figuring out how to set up the JSF runtime to be loaded up by the module class loader, rather than the application class loader.<br /><br />More significant for the evolution of Impala itself was figuring out how to create an arbitrary mapping from the request URI path prefix (the part of the URL after the host, port and application name), and an arbitrary module. In the Spring Faces sample, I needed to map all requests with a prefix of <span style="font-style: italic;">/spring</span> and no extension (e.g. .htm) in the path to the web module containing the Web Flow definitions and faces view. This particular requirement gave me the push I needed to implement the main features coming in the next drop of Impala, that is, the ability to map from arbitrary URI path prefixes to modules, and once within a module, to map individual requests to servlets or filters, themselves defined within the module, based on the URI extension.<br /><br />The Impala Spring Faces stack is somewhat experimental, but it does offer the promise of truly modular, dynamically reloadable applications based on these technologies.<br /><br /><span style="font-weight: bold;">Outstanding issues</span><br />There are a few wrinkles outstanding, though. The Spring web flow long running transaction is still not working. I have added a <span style="font-style: italic;">flush()</span> call so that the booking does persist, but this happens at the time the booking is first entered rather than confirmed. Also, it does seem possible at least in some situations to make simple changes to the flow definitions and reload these without preventing the completion of existing flows, but I'm sure there are some corner casePhil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0tag:blogger.com,1999:blog-1375633167426904536.post-23982049217053677762009-05-17T21:27:00.002+01:002009-05-17T21:30:06.367+01:00Impala 1.0 M6 releasedI am pleased to announce the 1.0M6 release of Impala. The 1.0M6 is an important release for Impala, as it is the last pre-1.0 final release to include major enhancements and API changes. I am now pretty comfortable that the APIs and abstractions are correct and suitable for the 1.0 final release, but as always welcome any feedback from users on this.<br /><br />The 1.0M6 release includes a major reworking of the shared service registry and proxying mechanisms, a new Spring namespace for importing and exporting services, and enhancements to the dynamic reloading of modules.<br /><br />The headline improvements include the following.<br /><ul><li>Configuration of Impala services is now much simpler, as a new Spring 'service' namespace has been provided for easily exporting and importing services.</li><li>Service export and import can now be done not only by name but also by type or by custom attributes, the latter using a model similar to that used in OSGi.</li><li>Impala's mechanism for proxying services obtained from the service registry has improved, and is now more easily configurable.</li><li>It is now possible to export and import Impala services without having to specify an interface - proxying of the service implementation class is now also supported.</li><li>Impala now supports exporting and importing services based on Spring beans which are not singletons or not created using non-singleton Factory beans. It does this in a way that is totally transparent to users of the services, effectively allowing clients to treat all beans as singletons.</li><li>Impala now provides implementations of<span style="font-style: italic;"> java.util.List</span> and <span style="font-style: italic;">java.util.Map</span>, dynamically backed by beans imported from the service registry.</li></ul>The 1.0M6 release also introduces a number of improvements to make dynamic module reloading more robust, particularly when using the module 'auto-reload' feature, as well as other minor enhancements and bug fixes.<br /><br />For more information on this release see<br /><a href="http://code.google.com/p/impala/wiki/Release1_0M6Announcement">http://code.google.com/p/impala/wiki/Release1_0M6Announcement</a>.Phil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.com0