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
