Page History

...

• You don't need separate deployment units and separate XML configuration files for each of your components. Just add a new entry in your Spring XML file to use a new component. So its a more lightweight approach.
• You don't need to learn a new XML configuration file syntax, just stick to Spring if you already know it
• You can use the various nice features in Spring (aliasing, using expandable properties to keep login/passwords outside of the XML etc).
• You can take advantage of POJO support to write light weight JBI components in a POJO style

Its also worth pointing out that a single component can be used in a Spring configuration or in a traditional JBI deployment unit without any code changes so you are free to choose either approach.

...

Here is an example of that in action.

JBI POJO support

ServiceMix provides support for JBI POJOs in addition to the usual JBI Components. JBI Components are maybe not as lightweight as they could be; there's a bunch of methods on there for dealing with metadata, management and capability management along with a lifecycle object.

ServiceMix introduces the idea of a JBI POJO which is any Java object which implements the ComponentLifeCycle interface and uses dependency injection to configure itself. Adding an instance of ComponentLifeCycle to the SpringJBIContainer will automatically wrap the POJO in a JBI ComponentAdaptor so that it faithfully obeys the JBI Component contract.

This means you can write JBI POJOs to be deployed by Spring without deriving from some helper base class like ServiceMix's ComponentSupport so that your POJO has no dependency other than on the JBI APIs and then let ServiceMix take care of more of the plumbing for you.

To see this in use, take a look at this example. The Spring XML looks about the same as the above example, the difference is the implementation classes.