mx4j/src/docs/english jsr160-explained.xml,1.10,1.11
Simone Bordet <[email protected]>
| Newsgroups | gmane.comp.java.mx4j.cvs |
|---|---|
| Message-ID | <[email protected]> |
Update of /cvsroot/mx4j/mx4j/src/docs/english
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30004/src/docs/english
Modified Files:
jsr160-explained.xml
Log Message:
Added documentation about the SOAPConnector
Index: jsr160-explained.xml
===================================================================
RCS file: /cvsroot/mx4j/mx4j/src/docs/english/jsr160-explained.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** jsr160-explained.xml 8 Dec 2003 22:02:29 -0000 1.10
--- jsr160-explained.xml 20 Jul 2004 13:08:41 -0000 1.11
***************
*** 31,34 ****
--- 31,62 ----
</para>
</section>
+ <section>
+ <title>MX4J's JSR 160 implementation</title>
+ <para>
+ MX4J implements JSR 160. This means that MX4J ships the standard JSR 160 API, located in package
+ <classname>javax.management.remote</classname>, and the mandatory providers defined by the specification,
+ namely the
+ <emphasis>rmi</emphasis> and
+ <emphasis>iiop</emphasis> providers, located in package
+ <classname>javax.management.remote.rmi</classname>.
+ <sbr/>
+ MX4J does not implement yet the optional
+ <emphasis>jmxmp</emphasis> provider defined by the JSR 160 specification.
+ <sbr/>
+ MX4J provides other two providers, not specified by the JSR 160 specification. This means that they will work
+ only if MX4J runs at both client and server side. These two providers are the
+ <emphasis>soap</emphasis> and
+ <emphasis>local</emphasis> providers.
+ </para>
+ <para>
+ To sum up, MX4J allows you to specify JMXServiceURLs (see next section) of the following kind:
+ <itemizedlist>
+ <listitem>service:jmx:rmi://host</listitem>
+ <listitem>service:jmx:iiop://host</listitem>
+ <listitem>service:jmx:soap://host</listitem>
+ <listitem>service:jmx:local://host</listitem>
+ </itemizedlist>
+ </para>
+ </section>
</section>
***************
*** 269,273 ****
<para>
To receive notifications, a client must register a listener by means of the
! <classname>javax.management.MBeanServerConnection.addNotificationListener(...)</classname> method. <sbr/>
There are two overloaded versions of this method: one that takes an ObjectName as listener, and one that
takes a NotificationListener as listener.
--- 297,302 ----
<para>
To receive notifications, a client must register a listener by means of the
! <classname>javax.management.MBeanServerConnection.addNotificationListener(...)</classname> method.
! <sbr/>
There are two overloaded versions of this method: one that takes an ObjectName as listener, and one that
takes a NotificationListener as listener.
***************
*** 278,285 ****
</para>
<para>
! The more interesting case is the second, where the listener is local to the client code. <sbr/>
In this case the listener that receives notifications emitted by a remote MBean always
remains local to the client code that registered it. The NotificationListener object is never sent across
! the wire. <sbr/>
NotificationListener objects are usually implemented with anonymous inner classes
(that most of the times are not serializables), and client code should not make any particular attention
--- 307,316 ----
</para>
<para>
! The more interesting case is the second, where the listener is local to the client code.
! <sbr/>
In this case the listener that receives notifications emitted by a remote MBean always
remains local to the client code that registered it. The NotificationListener object is never sent across
! the wire.
! <sbr/>
NotificationListener objects are usually implemented with anonymous inner classes
(that most of the times are not serializables), and client code should not make any particular attention
***************
*** 289,294 ****
<para>
On the other end, if the remote MBean sends custom subclasses of the Notification class, it must ensure that
! the custom Notification objects are <emphasis>serializable</emphasis>. <sbr/>
! The meaning of <emphasis>serializable</emphasis> depends on the protocol used; in case of RMI, it is the
usual meaning of "Java serializable" (that is, it can be written to a
<classname>java.io.ObjectOutputStream</classname>).
--- 320,328 ----
<para>
On the other end, if the remote MBean sends custom subclasses of the Notification class, it must ensure that
! the custom Notification objects are
! <emphasis>serializable</emphasis>.
! <sbr/>
! The meaning of
! <emphasis>serializable</emphasis> depends on the protocol used; in case of RMI, it is the
usual meaning of "Java serializable" (that is, it can be written to a
<classname>java.io.ObjectOutputStream</classname>).
***************
*** 317,321 ****
mechanism. However, if the server does not have notifications to send to the client, it does not return
an empty result, but instead holds the call for a configurable timeout until a notification is emitted
! or the timeout elapses. <sbr/>
This allows to reduce the network traffic (since there is no continuous polling from the client to the
server) and still have a fast reactivity to notification emitted by the server.
--- 351,356 ----
mechanism. However, if the server does not have notifications to send to the client, it does not return
an empty result, but instead holds the call for a configurable timeout until a notification is emitted
! or the timeout elapses.
! <sbr/>
This allows to reduce the network traffic (since there is no continuous polling from the client to the
server) and still have a fast reactivity to notification emitted by the server.
***************
*** 323,333 ****
Refer to the javadocs of the
<ulink url="/docs/api/mx4j/remote/RemoteNotificationClientHandler.html">
! <classname>mx4j.remote.RemoteNotificationClientHandler</classname></ulink> and of the
<ulink url="/docs/api/mx4j/remote/RemoteNotificationServerHandler.html">
! <classname>mx4j.remote.RemoteNotificationServerHandler</classname></ulink> for further details.
</para>
<para>
Take also a look at the examples bundled with the MX4J distribution for code snippets on registering
! listeners to remote MBeans. <sbr/>
Below, a quick example of how to register a listener to a remote MBean:
</para>
--- 358,371 ----
Refer to the javadocs of the
<ulink url="/docs/api/mx4j/remote/RemoteNotificationClientHandler.html">
! <classname>mx4j.remote.RemoteNotificationClientHandler</classname>
! </ulink> and of the
<ulink url="/docs/api/mx4j/remote/RemoteNotificationServerHandler.html">
! <classname>mx4j.remote.RemoteNotificationServerHandler</classname>
! </ulink> for further details.
</para>
<para>
Take also a look at the examples bundled with the MX4J distribution for code snippets on registering
! listeners to remote MBeans.
! <sbr/>
Below, a quick example of how to register a listener to a remote MBean:
</para>
***************
*** 369,374 ****
<title>Requiring user authentication to connect to a JMXConnectorServer</title>
<para>
! JSR 160 provides a pluggable authentication mechanism based on the interface
! <classname>javax.management.remote.JMXAuthenticator</classname>.
<sbr/>
The JMXAuthenticator interface has only one method that takes credentials from the client and returns a
--- 407,412 ----
<title>Requiring user authentication to connect to a JMXConnectorServer</title>
<para>
! JSR 160 provides a pluggable authentication mechanism based on the
! <classname>javax.management.remote.JMXAuthenticator</classname> interface.
<sbr/>
The JMXAuthenticator interface has only one method that takes credentials from the client and returns a
***************
*** 717,721 ****
<para>
JSR 160 offers a standard way of intercepting calls between the JMXConnectorServer
! and the target MBeanServer. <sbr/>
Such interception can be useful for logging, for granting access in a dynamic way (for example
based on the value of the arguments for a certain call to an MBean - this cannot be
--- 755,760 ----
<para>
JSR 160 offers a standard way of intercepting calls between the JMXConnectorServer
! and the target MBeanServer.
! <sbr/>
Such interception can be useful for logging, for granting access in a dynamic way (for example
based on the value of the arguments for a certain call to an MBean - this cannot be
***************
*** 813,817 ****
<para>
JSR 160 compliance requires implementation of a JMXConnector and JMXConnectorServer that
! use Java's Remote Method Invocation (RMI) to communicate. <sbr/>
The RMI connector and connector server are meant to work both over JRMP (Java Remote
Method Protocol, RMI's native protocol) and over IIOP (Internet Inter ORB Protocol, CORBA's
--- 852,857 ----
<para>
JSR 160 compliance requires implementation of a JMXConnector and JMXConnectorServer that
! use Java's Remote Method Invocation (RMI) to communicate.
! <sbr/>
The RMI connector and connector server are meant to work both over JRMP (Java Remote
Method Protocol, RMI's native protocol) and over IIOP (Internet Inter ORB Protocol, CORBA's
***************
*** 819,830 ****
</para>
<para>
! Java's RMI works so that the RMI client needs to have a <emphasis>stub</emphasis> object.
A normal java method call on the stub is routed to the network and ends up on the RMI server
! making possible to perform remote calls as if they were standard local calls. <sbr/>
The stub takes care the details of invoking the server side such as arguments and return
! value marshalling, exception throwing and so on. <sbr/>
The stub class is normally present in the client's
classpath (since the stub is part of the JSR 160 classes), but the stub object is normally
! downloaded from a naming server such as the <emphasis>rmiregistry</emphasis>.
The RMI client only needs to know the naming path under which the stub object has been bound to
by the RMI server.
--- 859,874 ----
</para>
<para>
! Java's RMI works so that the RMI client needs to have a
! <emphasis>stub</emphasis> object.
A normal java method call on the stub is routed to the network and ends up on the RMI server
! making possible to perform remote calls as if they were standard local calls.
! <sbr/>
The stub takes care the details of invoking the server side such as arguments and return
! value marshalling, exception throwing and so on.
! <sbr/>
The stub class is normally present in the client's
classpath (since the stub is part of the JSR 160 classes), but the stub object is normally
! downloaded from a naming server such as the
! <emphasis>rmiregistry</emphasis>.
The RMI client only needs to know the naming path under which the stub object has been bound to
by the RMI server.
***************
*** 835,839 ****
<para>
A JSR 160 RMIConnector needs to be able to retrieve the stub object in order to contact
! a remote JSR 160 RMIConnectorServer. <sbr/>
JSR 160 gives two possibilities to retrieve the RMI stub object to be able to contact the
RMIConnectorServer.
--- 879,884 ----
<para>
A JSR 160 RMIConnector needs to be able to retrieve the stub object in order to contact
! a remote JSR 160 RMIConnectorServer.
! <sbr/>
JSR 160 gives two possibilities to retrieve the RMI stub object to be able to contact the
RMIConnectorServer.
***************
*** 842,853 ****
The first way to contact an RMIConnectorServer is make the stub object part of
the RMIConnectorServer's address, represented by a JMXServiceURL.
! The JSR 160 specification refers to this possibility as the "encoded form". <sbr/>
In case of JRMP, the stub is serialized and its bytes are Base64 encoded and attached to
the JMXServiceURL, so that passing the JMXServiceURL to clients, they have all information
! needed to contact the server side (no naming server is needed). <sbr/>
! The JMXServiceURL path, in this case, starts with <emphasis>/stub/</emphasis>. <sbr/>
In case of IIOP, the IOR is attached to the JMXServiceURL (and again no naming server is
! needed). <sbr/>
! The JMXServiceURL path, in this case, starts with <emphasis>/ior/</emphasis>. <sbr/>
Simply passing an encoded form JMXServiceURL to a JMXConnector is enough to allow it
to contact the corrispondent JMXConnectorServer: the JMXConnector will take care of
--- 887,905 ----
The first way to contact an RMIConnectorServer is make the stub object part of
the RMIConnectorServer's address, represented by a JMXServiceURL.
! The JSR 160 specification refers to this possibility as the "encoded form".
! <sbr/>
In case of JRMP, the stub is serialized and its bytes are Base64 encoded and attached to
the JMXServiceURL, so that passing the JMXServiceURL to clients, they have all information
! needed to contact the server side (no naming server is needed).
! <sbr/>
! The JMXServiceURL path, in this case, starts with
! <emphasis>/stub/</emphasis>.
! <sbr/>
In case of IIOP, the IOR is attached to the JMXServiceURL (and again no naming server is
! needed).
! <sbr/>
! The JMXServiceURL path, in this case, starts with
! <emphasis>/ior/</emphasis>.
! <sbr/>
Simply passing an encoded form JMXServiceURL to a JMXConnector is enough to allow it
to contact the corrispondent JMXConnectorServer: the JMXConnector will take care of
***************
*** 871,877 ****
The second way to contact an RMIConnectorServer is to specify a path in the JMXServiceURL
that indicates the location of a naming server and the JNDI path where the stub object
! can be found. <sbr/>
! The JSR 160 specification refers to this possibility as the "JNDI form". <sbr/>
! In this case the JMXServiceURL path starts with <emphasis>/jndi/</emphasis>.
</para>
<para>
--- 923,932 ----
The second way to contact an RMIConnectorServer is to specify a path in the JMXServiceURL
that indicates the location of a naming server and the JNDI path where the stub object
! can be found.
! <sbr/>
! The JSR 160 specification refers to this possibility as the "JNDI form".
! <sbr/>
! In this case the JMXServiceURL path starts with
! <emphasis>/jndi/</emphasis>.
</para>
<para>
***************
*** 910,914 ****
Alternatively, JNDI properties can be specified in the usual ways they are specified for JNDI,
namely specifying system properties, a 'jndi.properties' file in the classpath or via an environment Map
! passed to the <funcdef>JMXConnector.connect(Map environment)</funcdef> method or to the
<funcdef>JMXConnectorFactory.connect(JMXServiceURL url, Map environment)</funcdef> method.
<sbr/>
--- 965,970 ----
Alternatively, JNDI properties can be specified in the usual ways they are specified for JNDI,
namely specifying system properties, a 'jndi.properties' file in the classpath or via an environment Map
! passed to the
! <funcdef>JMXConnector.connect(Map environment)</funcdef> method or to the
<funcdef>JMXConnectorFactory.connect(JMXServiceURL url, Map environment)</funcdef> method.
<sbr/>
***************
*** 945,953 ****
<para>
When working with IIOP, there may be the need to pass some information in order to
! correctly create the ORB. <sbr/>
In plain Java code, these properties are passed via system properties or via environment Map.
Similarly, when using the JSR 160 API, ORB properties can be specified as system properties
or via the environment Map
! passed to the <funcdef>JMXConnector.connect(Map environment)</funcdef> method or to the
<funcdef>JMXConnectorFactory.connect(JMXServiceURL url, Map environment)</funcdef> method.
</para>
--- 1001,1011 ----
<para>
When working with IIOP, there may be the need to pass some information in order to
! correctly create the ORB.
! <sbr/>
In plain Java code, these properties are passed via system properties or via environment Map.
Similarly, when using the JSR 160 API, ORB properties can be specified as system properties
or via the environment Map
! passed to the
! <funcdef>JMXConnector.connect(Map environment)</funcdef> method or to the
<funcdef>JMXConnectorFactory.connect(JMXServiceURL url, Map environment)</funcdef> method.
</para>
***************
*** 956,962 ****
<title>RMI socket factories (over SSL) for the RMIConnectorServer over JRMP</title>
<para>
! JSR 160 specifies two constants to specify the <classname>java.rmi.server.RMIClientSocketFactory</classname>
! and <classname>java.rmi.server.RMIServerSocketFactory</classname> instances that the
! RMIConnectorServer should use to export itself to the RMI runtime. <sbr/>
These constants are
<classname>javax.management.remote.rmi.RMIConnectorServer.RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE</classname> and
--- 1014,1023 ----
<title>RMI socket factories (over SSL) for the RMIConnectorServer over JRMP</title>
<para>
! JSR 160 specifies two constants to specify the
! <classname>java.rmi.server.RMIClientSocketFactory</classname>
! and
! <classname>java.rmi.server.RMIServerSocketFactory</classname> instances that the
! RMIConnectorServer should use to export itself to the RMI runtime.
! <sbr/>
These constants are
<classname>javax.management.remote.rmi.RMIConnectorServer.RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE</classname> and
***************
*** 966,973 ****
The MX4J implementation provides already an implementation of the
<classname>java.rmi.server.RMIClientSocketFactory</classname>
! and <classname>java.rmi.server.RMIServerSocketFactory</classname> interfaces that can be used to
encrypt the communication between the RMIConnector and the RMIConnectorServer using SSL, namely the
<classname>mx4j.tools.remote.rmi.SSLRMIClientSocketFactory</classname> and
! <classname>mx4j.tools.remote.rmi.SSLRMIServerSocketFactory</classname>. <sbr/>
These classes only work with JDK 1.4 or superior.
</para>
--- 1027,1036 ----
The MX4J implementation provides already an implementation of the
<classname>java.rmi.server.RMIClientSocketFactory</classname>
! and
! <classname>java.rmi.server.RMIServerSocketFactory</classname> interfaces that can be used to
encrypt the communication between the RMIConnector and the RMIConnectorServer using SSL, namely the
<classname>mx4j.tools.remote.rmi.SSLRMIClientSocketFactory</classname> and
! <classname>mx4j.tools.remote.rmi.SSLRMIServerSocketFactory</classname>.
! <sbr/>
These classes only work with JDK 1.4 or superior.
</para>
***************
*** 998,1001 ****
--- 1061,1192 ----
<section>
+ <title>MX4J's JSR 160 JMXConnectors and JMXConnectorServers</title>
+ <section>
+ <title>Overview of SOAPConnector and SOAPConnectorServer</title>
+ <para>
+ Thanks to the fact that JSR 160 allows complete pluggability of the communication protocol between
+ JMXConnector and JMXConnectorServer, it is possible to add easily new protocol providers.
+ <sbr/>
+ However, since these protocol providers are not defined by the JSR 160 specification, they are likely
+ to be not interoperable between different JSR 160 implementations.
+ <sbr/>
+ This means that - for example - it is safe to have the JSR 160 Sun Reference Implementation on server side
+ and MX4J on client side, or viceversa, only when the the protocol used is RMI or IIOP.
+ <sbr/>
+ MX4J implements a JSR 160 JMXConnector and JMXConnectorServer that use
+ <ulink url="http://www.w3.org/TR/soap/">SOAP</ulink> to communicate. The SOAP toolkit used by MX4J is
+ <ulink url="http://ws.apache.org/axis/">Axis 1.1</ulink>.
+ <sbr/>
+ When the SOAP protocol is used, other JSR 160 implementations will fail because
+ they don't implement the SOAP provider, or they don't implement it in a interoperable way with MX4J.
+ <sbr/>
+ By placing MX4J on both client and server side, you can leverage the functionalities offered by MX4J:
+ in this case you can use SOAP to communicate from client to server and viceversa.
+ </para>
+ <para>
+ Refer to the examples shipped with the MX4J distribution,
+ <classname>mx4j.examples.tools.remote.soap.Server</classname> and
+ <classname>mx4j.examples.tools.remote.soap.Client</classname> to follow the instructions below.
+ </para>
+ </section>
+ <section>
+ <title>Using the JSR 160 JMXConnector and JMXConnectorServer over SOAP</title>
+ <para>
+ Starting successfully a SOAPConnectorServer requires Axis 1.1 and a servlet 2.3 compliant web container.
+ <sbr/>
+ Starting a standalone SOAPConnectorServer will perform several operations:
+ <itemizedlist>
+ <listitem>Start a Jetty 4.2.x server on the port specified by the JMXServiceURL</listitem>
+ <listitem>Deploy to Jetty the Axis servlet, and mapping it to the path specified by the JMXServiceURL</listitem>
+ <listitem>Deploy to Axis the webservice that represent the remote MBeanServer</listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ On server side, the SOAPConnectorServer ignores the host part of the JMXServiceURL, since
+ it starts the web container on the local host.
+ <sbr/>
+ It is therefore recommended to start the SOAPConnectorServer passing null as host name,
+ to allow the real host name to be retrieved and used (as stated by the JMXServiceURL specification).
+ Also, it is recommended that URL path of the JMXServiceURL not be the empty string.
+ </para>
+ <para>
+ On client side, differently from the rmi, iiop and local providers, the host part of the JMXServiceURL
+ is not ignored; it is used to connect to the server side.
+ <sbr/>
+ It is very important that the host name of the JMXServiceURL on the server and the host name
+ of the JMXServiceURL on the client be exactly the same. If they differ (for example one is the
+ IP address and the other is the host name), then a message saying that the SOAPConnectorServer
+ cannot be found will be displayed.
+ </para>
+ <para>
+ It is possible to start several SOAPConnectorServers in the same JVM, with the constraint that
+ they must all have different URL path in their JMXServiceURLs.
+ In this case only one instance of Jetty will be used (and multiple servlet-mappings mapped to
+ the same Axis servlet).
+ </para>
+ <para>
+ <example>
+ <title>Starting the SOAPConnectorServer</title>
+ <programlisting>
+ <![CDATA[
+ // Use null as host
+ JMXServiceURL url = new JMXServiceURL("soap", null, 8080, "/jmxconnector");
+
+ MBeanServer server = ...;
+
+ JMXConnectorServer cntorServer = JMXConnectorServerFactory.newJMXConnectorServer(url, null, server);
+
+ // This method call will:
+ // 1. Start Jetty on port 8080
+ // 2. Deploy to Jetty the Axis servlet with servlet-mapping /jmxconnector/*
+ // 3. Deploy to Axis the web service that represent the remote MBeanServer
+ cntorServer.start();
+ ]]>
+ </programlisting>
+ </example>
+ </para>
+ <para>
+ <example>
+ <title>Connecting to the SOAPConnectorServer</title>
+ <programlisting>
+ <![CDATA[
+ // Remember to specify the host name if not in-VM
+ JMXServiceURL url = new JMXServiceURL("soap", null, 8080, "/jmxconnector");
+
+ // Connect !
+ JMXConnector cntor = JMXConnectorFactory.connect(url);
+
+ // Invoke some operation
+ MBeanServerConnection connection = cntor.getMBeanServerConnection();
+ Integer count = connection.getMBeanCount();
+ ]]>
+ </programlisting>
+ </example>
+ </para>
+ <para>
+ When you want to use a SOAPConnectorServer from within a running web application, it is possible
+ to tell to the SOAPConnectorServer not to start another web container, by passing the property
+ <classname>SOAPConnectorServer.USE_EXTERNAL_WEB_CONTAINER</classname> with the value
+ <classname>Boolean.TRUE</classname> to the environment map passed to
+ <classname>JMXConnectorServerFactory</classname>.
+ <sbr/>
+ In this case, the external web container must already have Axis deployed and mapped to a certain path.
+ <sbr/>
+ For example, the default installation of Axis maps the Axis servlet to the path /axis/services/*.
+ <sbr/>
+ The JMXServiceURL to use in this case should be:
+ </para>
+ <para>
+ service:jmx:soap://host:8080/axis/services
+ </para>
+ <para>
+ As further example, you can take a look at the index.jsp page inside the mx4j-soap.war bundled
+ with the MX4J distribution to see how a SOAPConnectorServer can be started from within a web
+ application.
+ </para>
+ </section>
+ </section>
+
+ <section>
<title>Porting old MX4J remoting code to JSR 160</title>
<section>
***************
*** 1169,1175 ****
<title>Remote MBean Proxying</title>
<para>
! Complex systems based on JMX are also, most of the times, distributed systems. <sbr/>
! Such systems are often made of <emphasis>nodes</emphasis>, and each node is made of
! <emphasis>components</emphasis>. <sbr/>
When the underlying architecture is JMX, in each node there is one (possibly more) MBeanServer that manages
the components, and each component is an MBean.
--- 1360,1369 ----
<title>Remote MBean Proxying</title>
<para>
! Complex systems based on JMX are also, most of the times, distributed systems.
! <sbr/>
! Such systems are often made of
! <emphasis>nodes</emphasis>, and each node is made of
! <emphasis>components</emphasis>.
! <sbr/>
When the underlying architecture is JMX, in each node there is one (possibly more) MBeanServer that manages
the components, and each component is an MBean.
***************
*** 1178,1182 ****
Sometimes there is the need to have one MBeanServer gathering information from many remote
MBeanServers. However, the information needed is only part of the information exposed by each remote
! MBeanServer: you may want to collect only some information from each remote MBeanServer. <sbr/>
For this purpose, it is useful to write an MBean that exposes this information, and register one instance
of this MBean per each remote MBeanServer.
--- 1372,1377 ----
Sometimes there is the need to have one MBeanServer gathering information from many remote
MBeanServers. However, the information needed is only part of the information exposed by each remote
! MBeanServer: you may want to collect only some information from each remote MBeanServer.
! <sbr/>
For this purpose, it is useful to write an MBean that exposes this information, and register one instance
of this MBean per each remote MBeanServer.
***************
*** 1193,1200 ****
<para>
For this purpose MX4J provides a remote MBean proxy: an MBean you can register in the
! gathering MBeanServer that acts as a proxy for a remote MBean hosted in a remote MBeanServer. <sbr/>
Refer anyway to the javadocs of the
<ulink url="/docs/api/mx4j/remote/RemoteMBeanProxy.html">RemoteMBeanProxy</ulink> class for further
! information. <sbr/>
Below there is an example where remote MBeanServers publish information about the downloads of
products, and a gathering MBeanServer proxies these information for easier access via the HTTPAdaptor.
--- 1388,1397 ----
<para>
For this purpose MX4J provides a remote MBean proxy: an MBean you can register in the
! gathering MBeanServer that acts as a proxy for a remote MBean hosted in a remote MBeanServer.
! <sbr/>
Refer anyway to the javadocs of the
<ulink url="/docs/api/mx4j/remote/RemoteMBeanProxy.html">RemoteMBeanProxy</ulink> class for further
! information.
! <sbr/>
Below there is an example where remote MBeanServers publish information about the downloads of
products, and a gathering MBeanServer proxies these information for easier access via the HTTPAdaptor.
***************
*** 1245,1252 ****
</para>
<para>
! The <classname>mx4j.remote.RemoteMBeanProxy</classname> MBean is a transparent proxy for the remote MBean:
invoking a method on the proxy results in the method being invoked on the remote MBean; registering a local
NotificationListener on the proxy results in registration on the remote MBean, and thus
! the local listener will receive notifications emitted by the remote MBean. <sbr/>
For example, by proxying the remote MBeanServerDelegate MBean, you can receive locally notifications of
MBean registrations/unregistrations that happens in the remote MBeanServer.
--- 1442,1451 ----
</para>
<para>
! The
! <classname>mx4j.remote.RemoteMBeanProxy</classname> MBean is a transparent proxy for the remote MBean:
invoking a method on the proxy results in the method being invoked on the remote MBean; registering a local
NotificationListener on the proxy results in registration on the remote MBean, and thus
! the local listener will receive notifications emitted by the remote MBean.
! <sbr/>
For example, by proxying the remote MBeanServerDelegate MBean, you can receive locally notifications of
MBean registrations/unregistrations that happens in the remote MBeanServer.
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click