activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <hi...@hiramchirino.com>
Subject Re: [activemq6] XML or Not on Configurations
Date Wed, 07 Jan 2015 16:53:14 GMT
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
<jakub.korab.lists@gmail.com> 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.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino

Mime
View raw message