activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: [DISCUSS] How to proper support blueprint in karaf?
Date Wed, 04 Feb 2015 18:23:33 GMT

Just to follow up on list about this to fully describe the issue and potential solution…

In the ActiveMQ schema that is used for both Blueprint and Spring, we use a bunch of:

<xsd:any namespace=“##other”/>

in places where the user may want to add custom implementation of various things.   Plugins,
transports, etc….      In Spring, the normal way this would work is to use the Spring “bean”
element to define a bean there.   However, blueprint does not have a top level “bean”
element.  The only top-level element that blueprint defines is the “blueprint” element.
 Thus, you cannot define a custom bean in those locations when using blueprint unless you
create a NamespaceHandler and register it and use a custom namespaced element in those locations.
  Definitely more work than should be necessary (and certainly more work than when using Spring).

I just committed some changes to aries/blueprint to add “bean” and “reference” elements
to the aries “extensions” namespace handler.    While that’s not in the blueprint namespace
itself, it should work.  The users would need to use something like:

<broker …>
     <bp:bean xmlns:bp=""
               class="org.apache.activemq.plugin.StatisticsBrokerPlugin" />

to get it to work.  This will obviously require a new release of the aries blueprint module
and karaf releases and such.  I’m going to do some more testing and verification before
pursuing that.   No changes required for ActiveMQ though.   

Any additional thoughts/ideas on this are more than welcome.


> On Feb 4, 2015, at 9:32 AM, Hadrian Zbarcea <> wrote:
> There is rather serious issue related to supporting blueprint in karaf. In case the jira
[1] and it's relevance is not immediately obvious, I am pointing to it here to draw a bit
of attention and choose among the two proposed solutions (or throw in other options). Lazy
consensus defaults to the 2nd solution. Unfortunately, either solution requires a new bundle.
> Thanks,
> Hadrian
> [1]

Daniel Kulp -
Talend Community Coder -

View raw message