activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: spring package problem
Date Fri, 09 Mar 2007 13:53:08 GMT
BTW I'm replying but taking future discussions over to the dev list...

On 3/9/07, Javier Leyba <> wrote:
> On 3/8/07, James Strachan <> wrote:
> >
> > BTW it would be pretty useful to have a pure properties files based
> > way to configure the broker! Fancy starting it off and we can improve
> > it?
> >
> James
> Well, I need to do it for me so, if it could be useful for others...
> I know how load properties (grin) could you give some ideas  about how
> should be the best way to wire properties with Broker setter methods ?
> Is there an ActiveMQ class to be extended or something else ?

A good class to look at is DefaultBrokerFactory which shows how the
default URI based configuration works...

So if there was a class like that which implements
BrokerFactoryHandler but then rather than taking the URI as the
configuration, it took the URI as a location of a properties file (or
a URL to a properties file such as, then
read it and did some introspection on it.

The code would end up being kinda similar to DefaultBrokerFactory.

Notice this code...

        IntrospectionSupport.setProperties(brokerService, params);

which does the introspection for you. Notice this only works for
primitive types. So for nested types we often write code like this...

            Map childOptions =
IntrospectionSupport.extractProperties(options, "memoryManager.");

To allow nesting of properties using dot notation. (We use this all
over the place when supporting configuration by URI throughout
ActiveMQ). Then the properties file could include a line...

memoryManager.limit = 10 Mb

Note that we could always just enhance
IntrospectionSupport.setProperties() to deal with being able to
auto-detect dot notations and navigate into beans setting properties
etc. (Please be hour guest if you fancy the challenge) - or failing
that you could just explicitly configure some complex bean properties
on BrokerService like consumerUsageManager, memoryManager and so

We could add some complex logic for dealing with lists of things. e.g.

transportConnectors.0 = ...
transportConnectors.1 = ...
transportConnectors.2 = ...

Finally the past piece of the puzzle is the BrokerFactory which has a
helper method...

BrokerService broker = BrokerFactory.createBroker(someURI);

To wire into that one (we support xbean: and broker: so far as
schemes), we could add properties as a scheme.

Then folks could do...

BrokerService broker = BrokerFactory.createBroker(new

To add this we just need to add a file called properties in this location...

(if you look in the other files or the BrokerFactory code you'll see
how it all works)

Do let us know if you need any help!


View raw message