A call hierarchy on the DiscoveryTransport constructor reveals that it is instantiated in FanoutTransportFactory and DiscoveryTransportFactory, which extends FailoverTransportFactory. In DiscoveryTransportFactory, the parameters are applied to the DiscoveryTransport. Wouldn't it be better to have both fanout and failover factories call DiscoveryTransportFactory to ensure the discovery transport is created correctly? In that case, DiscoveryTransportFactory would no longer extend FailoverTransportFactory.
Unfortunately, this would probably break using the discovery transport directly, right? So, it's probably better to simply add transport.setParameters(parameters) and IntrospectionSupport.setProperties(transport, parameters) to FanoutTransportFactory. I'll look to open a jira issue and will create a test case. Thanks. Gary Tully wrote: > > I think that is the correct approach. Compare > FanoutTransportFactory.createTransport to some of the other transport > factories, FailoverTransportFactory for example, it follows that > pattern. > Possibly open a jira issue and attach your patch and a test case to > protect it. > > -- > http://blog.garytully.com > > Open Source Integration > http://fusesource.com > > -- View this message in context: http://old.nabble.com/Applying-Parameters-to-Discovered-Brokers-tp29239157p29248723.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
