activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: ActiveMQ DSLs
Date Wed, 18 Mar 2015 02:34:38 GMT
I will add another couple of thoughts on this topic. I totally get that, 
and I agree.

My thinking though is that outside testing, where yes, it could be very 
convenient, I doubt it will find much use in production. The main reason 
is that one would very likely have to change code in order to 
reconfigure the broker. In practice, there are way more stringent rules 
for code deployment than configuration changes. Sometimes that's what 
one wants, treating configuration as code and limit changes, but then 
one could very well deliver the activemq.xml configuration in a 
jar/bundle with the same effect.

So anyway, from a production perspective, very limited benefit, I see it 
mostly as bloat. From a community perspective, I have very bad 
experience with larger jars, with a large number of packages and 
classes, sometimes just alternatives for each other. They tend to be 
confusing and off-putting for new contributors. From a vendor 
perspective, I do see the appeal of providing more 'features'. I try to 
resist the temptation.

I hope that clarifies the rationale behind my previous statements.


On 03/16/2015 08:39 AM, Dejan Bosanac wrote:
> I like this approach of configuring the brokers. I see it as as very
> powerful tool for writing complex unit tests, which can make our lives
> easier. On the other hand, I don’t see any reason why wouldn’t we include
> it in the code base. It doesn’t affect the core, so it’s not a
> stability/performance risk, nor it is a big maintenance burden.
> Regards
> --
> Dejan Bosanac
> ----------------------
> Red Hat, Inc.
> Twitter: @dejanb
> Blog:
> ActiveMQ in Action:
> On Sat, Mar 14, 2015 at 1:44 PM, Jakub Korab <>
> wrote:
>> The end() idiom was just something I put in to make it clear when an
>> element was closing (there's no way to easily express the difference
>> between an attribute and a subelement of a config node, or when an element
>> is finishing). I'm not married to any particular syntax here, and it
>> definitely has room for improvement.
>> Just to refer back to my previous reply to Hadrian, imagine this sort of
>> thing, and you get a much better idea as to where my thinking is heading
>> with regard to the power of a DSL.
>> String[] destinationsToReplicate = new String[] {"a", "b", "c", "d",
>> "e"...};
>> List<VirtualDestinationDefinition> virtualDestinations = new
>> ArrayList()<>;
>> for (String destination : destinationsToReplicate} {
>>      virtualDestinations.add(
>>          compositeQueue(destination) // statically included method
>>              .forwardOnly(true)
>>              .forwardTo()
>>                  .queue("toNY." + destination)
>>                  .queue("toLN." + destination)
>>                  .topic("audit." + destination));
>> }
>>      .destinationInterceptors()
>>          .virtualDestinationInterception()
>>              .withVirtualDestinations(virtualDestinations)
>>      .networkConnectors()
>>          .networkConnector("TY-NY", "tcp...")
>>              .staticallyIncludedDestinations("toNY.>")
>>          .networkConnector("TY-LN", "tcp...")
>>              .staticallyIncludedDestinations("toLN.>");
>> Tiny amount of code, lots of work being performed, easy to comprehend and
>> maintain.
>> If you had multiple brokers in different geographical locations, you could
>> inject all the string values from some config into a template broker
>> definition, and have a standard deployed process that uses this DSL spin up
>> a uniformly configured broker specific to that location. That's something
>> you can't do with ease right now.
>> Jakub
>> On 13/03/15 22:18, David Jencks wrote:
>>> Unfortunately your sample didn't show up on the mailing list…. I had to
>>> resort to looking at nabble.
>>> I think your example is too simple to see the benefits of a fluent api.
>>> For instance, you haven't added an object that itself needs configuration
>>> to a collection (e.g. transport connector).  My experience is that they
>>> make configuring anything reasonably complicated 10x simpler and more
>>> pleasant :-)
>>> That being said….. I'm not familiar with the ".end()" idiom.  Is this
>>> common? "standard"?  I'd think it would be less confusing if they were
>>> .endTransportConnectors() etc so it was clear what you were ending.
>>> thanks
>>> david jencks
>>> On Mar 13, 2015, at 5:32 PM, artnaseef <> wrote:
>>>   I see "fluent is easier" as a valid argument to maintaining the project,
>>>> but
>>>> not necessarily as a reason to pull it into the ActiveMQ main code base.
>>>> Still, I am 50/50 on this myself.  I personally don't have a need for
>>>> simpler configuration of embedded brokers.  Also, the syntax of fluent
>>>> builders doesn't appeal to me personally, so that makes it harder for me
>>>> to
>>>> buy-in.  For example:
>>>> Seems simpler to understand than (I'm making this one up - not using the
>>>> posted language):
>>>> With that said - I acknowledge this is my opinion and welcome some
>>>> discussion of the benefit of including the code inside of ActiveMQ itself
>>>> (beyond the well-understood "it will then be maintained with the core
>>>> code").
>>>> Art
>>>> --
>>>> View this message in context: http://activemq.2283324.n4.
>>>> Sent from the ActiveMQ - Dev mailing list archive at

View raw message