activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Proposed Additional BrokerViewMBean Methods
Date Wed, 03 Oct 2007 16:46:06 GMT
Sounds good to me. Any patches always welcome

On 01/10/2007, tpounds <> wrote:
> I think the following operations would be very useful if they were added the
> the BrokerViewMBean:
> void add/removeConnector(URI bindAddress) throws Exception;
> void add/removeNetworkConnector(URI discoveryAddress) throws Exception;
> void add/removeProxyConnector(URI bindAddress) throws Exception;
> Basically all this entails is updating the BrokerView class to forward these
> methods from the already registered BrokerSerive object avaible in the
> class.  The only impeding feature from forwarding the methods from
> BrokerService directly is the
> TransportConnector/NetworkConnector/ProxyConenctor objects that are returned
> from the methods in the BrokerService impl do not implement the Serializable
> interface. This can be supported by two options: 1) either implementing the
> Serializable interface on the returned objects or 2) by changing the
> BrokerViewMBean method to throw an exception on a non-successful
> registration of the network connector URI.  If we go with the option 1 then
> we could potentially publish all of the add*Connector methods provided by
> the BrokerService class.  Option 2 requires the least amount of code changes
> and could be implemented fairly quickly. I'm currently in the process of
> developing some patches to support option 2...but I wanted to get an idea
> what the core developers think about the proposed feature.  I can create a
> jira improvement ticket for the task and assign it to myself if everyone
> thinks this would be beneficial to the community.
> I know this feature will be very useful in environments that have statically
> configured connectors where auto discovery is not provided or possible (i.e.
> internet). A dynamically changing business environment that has remote
> management tools for auto-registering of client brokers could benefit in the
> above case when all that is known at deployment time is that local JMS
> clients connect to a local broker that needs to publish queue/topic upstream
> to unknown.  This is also particularly useful for components based on
> ActiveMQ such as ServiceMix where servicemix client need to connect to other
> ServiceMix/ActiveMQ brokers/clusters upstream.
> --
> View this message in context:
> Sent from the ActiveMQ - Dev mailing list archive at


Open Source SOA

View raw message