Spring out of the box provides little support for loading property attributes based on environments and/or server contexts. Many projects work around this by creating custom ant builds. With Configleon you can build one war file that can be deployed to every location.
Configleon really shines is in it's ability to cascade the property attributes. This allows the common attributes to be defined in a global file and then overridden at the environment and server context.
If we consider the development of a web application, it typically starts in a local environment. The application will then be deployed to various environments including dev, qa, test, and production. Within a given environment, you may be deploying the same application to different server contexts.
For example, say we are deploying the JMesa example web application to the test environment. But we also have two different versions of the application. One is deployed to mycompany.com/jmesa and the other is deployed to mycompany.com/jmesa2. In this example that same war file can use different properties based on both environment and context. In this example, the environment is test and the server context is jmesa and jmesa2.
Impala 1.0M5 introduces a number of API and configuration improvements, making the framework easier to configure and extend, and usable in a wider range of environments. Following 1.0M5, only minor changes in internal APIs are now expected prior to the 1.0 final release.
The 1.0M5 release makes it much easier to configure Impala-based applications by supporting a property-based configuration. While Impala is still very heavily based on the Spring framework, 1.0M5 now also makes it possible to plug in other runtime frameworks into Impala's dynamic module loading mechanism.
The full list of issues for milestone 1.0M5 is here: http://code.google.com/p/impala/issues/list?q=label:Milestone-Release1.0M5&can=1.
Note that there are a number of package name and configuration changes in this release. If you are upgrading from an earlier release, you will probably wish to check the backward incompatible changes for 1.0M5 and an example migration sequence for this release.
If you're interested in getting involved in the Impala project, please take a look at this page: http://code.google.com/p/impala/wiki/GetInvolved.
The Firewater Framework lets you create sophisticated REST based web APIs for your Java and Flash/Flex based web applications. Features include:
* Spring based declarative architecture (zero code web services)
* extensible framework
* supports GET, PUT, POST, OPTIONS and DELETE HTTP methods and matches incoming URL patterns
* supports JDBC back-ends with templated SQL mappings
* supports secured web services using Acegi Spring Security
* supports paging, full-text search, sorting and filtering
* flexible cacheing strategy based on OSCache
* custom Spring schema for easy configuration
AtUnit minimizes boilerplate code in unit tests and guides test development by enforcing good practices.
* mark exactly one field with @Unit to indicate the object under test.
* mark fields with @Mock or @Stub to obtain mock objects
* inject your tests, and your test subjects, using your favorite IoC container
Mock Objects Integration
AtUnit integrates with JMock or EasyMock to provide mock objects:
* obtain a JMock context simply by declaring a field
* annotate fields with @Mock to obtain JMock or EasyMock mock objects
* annotate fields with @Stub to obtain a JMock or EasyMock stub object
... or you can use your own mock objects plug-in with two easy steps:
* implement the MockFramework interface
* annotate your tests with @MockFrameworkClass(MyMockFramework.class)
Container Integration
AtUnit integrates with Guice or Spring to take all of the work out of dependency-injected tests.
With Guice:
* never see the Injector, never write bootstrapping boilerplate!
* @Inject test class fields without even defining a Module
* declaratively obtain mock objects with @Inject @Mock
* if you need more binding flexibility, simply have your test class implement Module
With Spring:
* annotate fields with @Bean to get them from the Spring context
* fields annotated with @Bean which do not appear in your Spring context are added to it automatically! (This includes @Mock and @Stub fields.)
* AtUnit looks for a Spring XML file with the same name as your test, or you can specify the location yourself with @Context("filename")
* Most of the time, you don't even need a Spring XML file!
You can easily plug in other containers in two steps:
* implement the Container interface
* annotate your tests with @ContainerClass(MyContainer.class)