Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of ataylor@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <54AE50BE.2070105@redhat.com>
Date: Thu, 08 Jan 2015 09:41:18 +0000
From: Andy Taylor <ataylor@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: dev@activemq.apache.org
Subject: Re: [activemq6] XML or Not on Configurations
References: 
 <CAKF+bsoR6giJcBpmdMO462WCqsmhsKMciA-Hs=cfrOs=De-QSA@mail.gmail.com>
	<54AD5B38.9030606@gmail.com>
 <CAGZ-RDKT3_03i6Y1H20tVsMkFHA-j_E9kZNNjNjKCNh3_owESQ@mail.gmail.com>
In-Reply-To: 
 <CAGZ-RDKT3_03i6Y1H20tVsMkFHA-j_E9kZNNjNjKCNh3_owESQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

+1 for xml, and the code snippet shows exactly how it will work, so in 
the future we could if we want plug in any config we want.

Also we have a JIRA for configuration updates..

On 07/01/15 16:53, Hiram Chirino wrote:
> 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
>
>