Page History

Backward compatiblity

HiveMind 2 was developed to be as much backward compatible as possible.
Although most public APIs remained the same there are certain areas which require changes when migrating to this version.

How far an application is backward compatible depends on the way it uses hivemind.
For example a web application that uses the HiveMindFilter for loading the registry
and defines service and configuration points without the use of custom factories
has a good chance to be 100% compatible.

Things that have changed

The registry build and construction process

The RegistryBuilder and related classes (ModuleDescriptorProvider) are not used in the same way as before. Look here for examples how the registry is build.

Unique attributes and key-attributes

Occurances of configurations

Configurations are not lazy by default

since 2.0-alpha-2

This may cause trouble if cyclic references between configurations and services exist.
In that case configuration points can be defined lazy via the new lazy attribute:

  <configuration-point id="Translators" lazy="true">
    ...
  </configuration-point>

Factory interfaces

These interfaces have changed. They now belong to the hivemind-xml module.
Items that were of type java.util.List before are now of type Object:

public interface ServiceInterceptorFactory
{
    /**
    public void createInterceptor(InterceptorStack stack, Module invokingModule, Object parameters);
}