activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Korab <jakub.korab.li...@gmail.com>
Subject Re: ActiveMQ DSLs
Date Sat, 14 Mar 2015 12:44:13 GMT
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));
}

ActiveMQBrokers.broker("TY.orderRouter")
     .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 <art@artnaseef.com> 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.nabble.com/ActiveMQ-DSLs-tp4693171p4693202.html
>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Mime
View raw message