Hello, Maybe the user forum is not the recommended place for this discussion: but besides the blueprint xml discussion; there's another "design" question that I'm not sure of how it is seen by the AMQ devs at this moment:
I'll be making a few assumptions since I'm not very experienced with ActiveMQ or Karaf or Blueprint: 1) The default contract of ConnectionFactory is that it can throw exceptions if the JMS broker is not immediately available for some reason (that's at least the behavior I'm seeing). 2) The creation of the instances of ActiveMQConnectionFactory & PooledConnectionFactory is in my example done with Blueprint, but it could as well be written POJO classes, in any OSGi or JEE container. So the design is very all-purpose. The solutions we were currently discussing are all based on the Broker and the Client being in the same OSGI/Spring/Blueprint context, but that may not always be true. Wouldn't it be useful to have an option in the (Pooled)ActiveMQConnectionFactory that there's a blocking start-method that blocks until the connection with the broker(url) is established. This would allow the "default" behavior of OSGI to be used: The (pooled)connectionfactory is offered as a Service, and giving it a blocking start/init-method that retries until success or some configurable limit is reached (time/attempts/...) would delay the start of all bundles consuming the javax.jms.ConnectionFactory Service until the broker is really available (whether this in in the same runtime or anywhere else on the network). I can implement this try/retry strategy in the init-method of all my blueprint bundles; but I think it would be a good addition to have this functionality in AMQ. Kind regards, Tom Mercelis -- View this message in context: http://activemq.2283324.n4.nabble.com/Connection-Refused-from-ActiveMQConnectionFactory-tp4664195p4664390.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
