Hey.. I personally think that XML is must have these days even if it's a little cumbersome. Just about everyone understands it and then you easily integrate into stuff like Spring with a namespace handler. But it would be nice if the same config object model could be parsed from something a little more terse like Yaml or HOCON [1]
Having a BrokerBuilder like Jakub described would be nice, but I think I would prefer if it was a BrokerConfigBuilder :) The reason is that like in Apollo, it would be nice if a broker did not just use the configuration model for initial startup, but also to handle configuration updates. BrokerConfig config = .. some kinda of config builder (dsl or xml parser) ..; Broker broker = factory.createBroker(config); broker.start(); BrokerConfig update = .. some kinda of config builder (dsl or xml parser) ..; broker.update(update); [1]: https://github.com/typesafehub/config#features-of-hocon On Wed, Jan 7, 2015 at 11:13 AM, Jakub Korab <[email protected]> wrote: > Hi Clebert, > > I would like to chime in on the configuration front. > > ActiveMQ 5 currently supports 2 XML variants - Spring and Blueprint > (which have the same features, but different namespaces). This makes it > really easy to embed in existing applications, as well as leverage tools > like Jasypt to support encryption in placeholders used for passwords. > One of the strengths of this approach is that it is also really easy to > drop in Camel code (also via its own XML namespace) inside the same > configurations for things like content-based routing and bridging to > other messaging providers (I have seen this inside numerous installations). > > This is not meant to dissuade from other approaches (except JSON, which > doesn't support comments, ugh), but it needs to be there for feature parity. > > What would be awesome to see in ActiveMQ 6, which is currently a > downside of ActiveMQ 5, is a separation of the configuration part of the > broker from the runtime implementation. ActiveMQ 5 uses XBean on the > implementation classes, which is a bit iffy. Separating the two would > give users the possibility to pull up the config of a broker via the > runtime itself. Camel does this by allowing you to dump routes out as > their XML representation at JMX. There are a number of reasons that this > would be awesome: > > * A small portion of users (< 5%) configure ActiveMQ programatically via > their own wrapper process. You end up going down this path if you have > complex networks of brokers, with lots of networkConnectors that each > have a lot of rules about which destinations are included or excluded. > For someone coming in to fix a problem, this means trawling through code > to work out how a broker is configured. ActiveMQ 5 is also heavily > embedded for testing purposes, anything that would make this easier to > do would be warmly regarded by devs. > * External tooling can only get information about a broker by what is > available via JMX/advisory messages/statistics plugin. This is only a > subset of the information that would be possible if it could pull up > what the config was. E.g. Imagine a visual representation of a broker > network that could take into consideration what paths a message could go > down. > > A configuration DSL could take the form of something like the following > (lovingly ripped straight from the Camel concepts): > > public class MyBroker extends BrokerBuilder { > public void configure() { > broker("myBroker").enableJmx(1099).persistent(false) > .transportConnector("stomp://0.0.0.0:61614") > .networkConnector("static:failover:(tcp://anotherHost)") > .staticallyIncludedDestinations() > .queue("foo") > .queue("bar") > .excludedDestinations() > .topic("ActiveMQ.Advisory.>") > .end(); > } > } > > BrokerContext context = new BrokerContext(new MyBroker()); > context.start(); > // later... > context.stop(); > > IMO this would be huge step forward for ActiveMQ. > > Cheers, > > Jakub > > On 17/12/14 17:17, Clebert Suconic wrote: >> Since we are not moving on ActiveMQ6 we could things differently. >> >> I was wondering for configuration.. is there anything better these >> days for storing config? >> >> I heard today for two options... YAML, and JSON. >> >> >> So we would have Three options so far: >> >> YAML - it seems nice.. but I'm not sure about libraries >> JSON >> XML >> >> >> We could look at what was done on Apollo... but I *believe* it was XML as >> well? >> >> Any experience for other newer projects? >> >> >> >> Clebert > -- Hiram Chirino Engineering | Red Hat, Inc. [email protected] | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
