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. [email protected] Twitter: @dejanb Blog: http://sensatic.net ActiveMQ in Action: http://www.manning.com/snyder/ On Sat, Mar 14, 2015 at 1:44 PM, Jakub Korab <[email protected]> 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)); > } > > 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 <[email protected]> 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. >>> >> >
