You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by tpounds <tr...@gmail.com> on 2007/10/01 03:02:07 UTC
Proposed Additional BrokerViewMBean Methods
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: http://www.nabble.com/Proposed-Additional-BrokerViewMBean-Methods-tf4545757s2354.html#a12971981
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Proposed Additional BrokerViewMBean Methods
Posted by tpounds <tr...@gmail.com>.
The patch has been completed and attached the following JIRA ticket.
https://issues.apache.org/activemq/browse/AMQ-1444
--
View this message in context: http://www.nabble.com/Proposed-Additional-BrokerViewMBean-Methods-tf4545757s2354.html#a13051320
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Proposed Additional BrokerViewMBean Methods
Posted by James Strachan <ja...@gmail.com>.
Sounds good to me. Any patches always welcome
http://activemq.apache.org/contributing.html
On 01/10/2007, tpounds <tr...@gmail.com> 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: http://www.nabble.com/Proposed-Additional-BrokerViewMBean-Methods-tf4545757s2354.html#a12971981
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
>
--
James
-------
http://macstrac.blogspot.com/
Open Source SOA
http://open.iona.com
Re: Proposed Additional BrokerViewMBean Methods
Posted by tpounds <tr...@gmail.com>.
The patch has been completed and attached in the following JIRA ticket.
https://issues.apache.org/activemq/browse/AMQ-1444
--
View this message in context: http://www.nabble.com/Proposed-Additional-BrokerViewMBean-Methods-tf4545757s2354.html#a13051320
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.