So I haven't had the time to research this - but as lack of instant feedback is interpreted as ignoring, I believe this has merit - but will require some in depth investigation.

James Carman <mailto:ja...@carmanconsulting.com>
8 April 2015 08:13
Pluggable *within* ActiveMQ. That is what doesn't exist. The idea is that
the underlying engine could be optimized on a case-by-case basis. For
instance, you may be able to streamline the implementation of a broker that
doesn't require persistence at all. Right now, we have one implementation
that tries to be the end-all-be-all solution for everything.


Jim Gomes <mailto:jgo...@apache.org>
8 April 2015 07:45
I'm with Guillaume on this. From the NMS perspective, the broker already is
a plugin implementation. I don't understand why it would need to go any
deeper than that. NMS can talk to TIBCO or ActiveMQ brokers via one common
API. The idea of pluggable brokers already exists.


Guillaume Nodet <mailto:gno...@apache.org>
30 March 2015 16:32
Fwiw, the whole broker implementation looks like an implementation detail
from a user point of view that uses the JMS spec... ;-)


Hadrian Zbarcea <mailto:hzbar...@gmail.com>
30 March 2015 16:12
+1.

The blocking today it merely an implementation detail than can be addressed.

Hadrian


Reply via email to