Apache ActiveMQ is based on the model of POJOs and Dependency Injection. If you are developing Interceptors or additional components or plugins for ActiveMQ then the first thing you should do is develop the code as if you are writing any other Spring component, using dependency injection.
Some folks favour using constructor based injection as it removes the need to have a separate lifecycle start() method - others find using property based injection is a little more flexible and easier to map to XML configuration files. We'll leave that choice up to you. For complex to create objects you could consider writing a FactoryBean. For more details on writing POJOs with Spring see their documentation.
If you wish your POJO to have its own custom XML you may wish to follow the following source examples for working nicely with XBean. Basically you add an XBean annotation in the javadoc comments to tell XBean how to map the POJO to custom XML. This should look something like
You can omit the element configuration. For more details on the available annotation options see here
If you are submitting your plugin to the ActiveMQ project then it will end up being included in the maven build step to create the XBean artifacts as part of the jar (in the META-INF/services area).
However if you are writing an external plugin to ActiveMQ then you will need to add the maven-xbean-plugin to your Maven 2 build. Refer to the activemq-core/pom.xml as an example of using this plugin.
Configuring plugins without custom XML
If you want to configure plugins that does not implement custom XML, you can define plugins as "regular" Spring beans and reference them in broker's
Not that this mechanism will not work in case that you have some XBean plugins configured inside the
The easiest way to get a feel for how to extend ActiveMQ is maybe to look at some concrete examples of features and how those are implemented and configured. Here are some examples