You are looking at the HTML representation of the XML format.
HTML is good for debugging, but probably is not suitable for your application.
See complete documentation, or
API help for more information.
<?xml version="1.0"?>
<api>
<query-continue>
<allpages gapfrom="Resin 4 CDI Dependency Injection Application Configuration Example" />
</query-continue>
<query>
<pages>
<page pageid="86" ns="0" title="Resin:Eclipse IDE Plugin">
<revisions>
<rev xml:space="preserve">{{Development}}
Resin includes excellent support for the Eclipse IDE. This page describes the details of the Resin Eclipse plugin.
===Eclipse Versions Supported===
Resin's Eclipse plugin is based on the proven [http://www.eclipse.org/webtools/ Eclipse Web Tools Platform (WTP)]. You must have the WTP installed for the Resin plugin to work. Generally, if you download the [http://www.eclipse.org/downloads/ Eclipse IDE for Java EE Developers], it will automatically include the WTP. This is by far the easiest way to get started. Otherwise, you can add the WTP to your Eclipse installation yourself.
The Resin Eclipse plugin supports Helios (Eclipse 3.6) and above.
For Indigo (Eclipse 3.7) and above, the Resin plugin is already registered.
If you're using Helios (3.6), the plugin should be installed through the [http://www.caucho.com/eclipse/ Resin Eclipse Plugin update site].
Detailed instructions on how to install the plugin for your version of Eclipse are described below.
===Installing through Eclipse Server auto-discovery (Indigo and above)===
To install Resin on Indigo or above, go to the 'Servers' View - it is typically in the bottom tabs (make sure you are in the Java EE Perspective). Right click and select 'New->Server'. In the 'New Server' dialog, you will likely not see Resin as an option. To install Resin, you will have to click on the 'Download additional server adapters' option. It will take a few seconds for the 'Install New Extension' dialog to fully load. Once it loads, select the 'Resin (Java EE Web Profile) Server' option and click 'Next'.
[[Image:New_extension.png|center|frame|Install Server Support for Resin]]
Accept the license terms to start the installation (you might also get an "unsigned content" warning; this is OK, accept it to proceed with the installation). The installation might take a few minutes.
[[Image:Installing_resin.png|center|frame|Installing Server Support for Resin]]
Once the installation finishes, you may be asked to restart Eclipse. You should verify a successful installation by checking if Resin is included in the 'New Server' dialog.
[[Image:New_server_resin.png|center|frame|New Server Dialog with Resin Support]]
===Installing from the Resin Eclipse plugin update site (Helios and above)===
Eclipse versions prior to Indigo did not have Resin automatically registered as a server option. For these versions, you will need to install the Resin plugin yourself directly from the [http://www.caucho.com/eclipse/ Resin Eclipse plugin website] ([http://www.caucho.com/eclipse/ http://www.caucho.com/eclipse/]). One very nice side-effect of the manual plugin installation option is that you can download the very latest pre-release Resin Eclipse plugin snapshot from the [http://www.caucho.com/eclipse-snapshot/ Resin Eclipse plugin snapshot site] ([http://www.caucho.com/eclipse-snapshot/ http://www.caucho.com/eclipse-snapshot/]).
To install the plugin, you must first register the plugin website as an Available Software Site in Eclipse. You do this by going to 'Help->Install New Software...->Add...'. In the 'Add Repository' dialog, enter a name and the location for the Resin Eclipse plugin website ([http://www.caucho.com/eclipse/ http://www.caucho.com/eclipse/]).
[[Image:Add_repository.png|center|frame|Add Resin Eclipse Plugin Site]]
After clicking OK, the plugin site will be registered. After the site is registered, select "Resin (Java EE 6 Web Profile) Server" and click 'Next'.
[[Image:Install_resin.png|center|frame|Installing Resin]]
Review the installation and click 'Next' again. Accept the license terms to start the installation (you might also get an "unsigned content" warning; that's OK right now, simply accept it to proceed with the installation). The installation might take a few minutes. Once the installation finishes, you may be asked to restart Eclipse. Once Eclipse is restarted, go to the 'Servers' View - it is typically in the bottom tabs (make sure you are in the Java EE Perspective). Right click and select 'New->Server'. In the 'New Server' dialog, you will see Resin as an option.
[[Image:New_server_resin.png|center|frame|New Server Dialog with Resin Support]]
===Adding a server===
To add a server, use the Add Server dialog and choose Resin.
The host name and server name values in this dialog are significant. The host name is the location of Resin instance. If you intend to run Resin locally, the default value of "localhost" is correct. The server name is the name of the server in Eclipse. You should choose a sensible name that is meaningful to you.
[[Image:New_server_resin.png|center|frame|New Local Server]]
If you plan on using a Resin instance on a remote server, you should enter the IP address or DNS name of that server in the host name field.
[[Image:remote_resin.jpg|center|frame|New Remote Server]]
===Adding a runtime===
The first step to adding a server is adding a Resin runtime. A Resin runtime essentially corresponds to a Resin installation, while a server corresponds to particular running instance of the runtime. If you only care about running a single local instance of Resin, the runtime and server would be synonymous to you.
If you have already created a runtime, you can simply use that to create a new server by choosing it in the first step of the Add Server dialog (as shown in the last diagram in this section). If the Resin plugin does not find an existing runtime, it will automatically start the Add New Runtime dialog for you as part of adding the server as well as omitting the runtime selection choice in the Add Server dialog (as is the case with all the Add Server dialog diagrams shown so far). A runtime consists of a JRE as well as a Resin installation (Resin Home). If you already have Resin installed, point Resin Home to where you installed Resin. If you have not yet installed Resin, you can do so now by clicking the 'Download and Install' button. This will install the latest version of Resin in the Resin Home location.
[[Image:Add_server.png|center|frame|Add Resin runtime]]
Note that in case of a remote Resin instance, the runtime must match the remote server that you are using, both for the JRE and the Resin version in use.
If you need it, you can certainly create more than one Resin runtime. The most common use of this is using more than one Resin version at a time. You create new runtimes by selecting 'Window->Preferences->Server->Runtime Environments->Add...'.
[[Image:Runtimes.png|center|frame|Runtimes]]
While adding a new server, you can choose the existing runtime that is most suitable. The Resin plugin will detect and list all the registered runtimes that it finds.
[[Image:Existing_runtime.png|center|frame|Choose Existing Runtime]]
===Server Licenses===
The next step to adding a runtime is requesting a development license. You can use the development license to enable Resin Pro features like clustering or extended health checks. The license will be sent to you via email.
[[Image:Licenses.png|center|frame|Get Development License]]
Note the license dialog will only appear if your Resin installation is missing a license. Otherwise, the license dialog is omitted and your existing license is used.
Requesting a license is completely optional and can be skipped over. All of the Resin Open Source features will still be available to you for development.
===Configure Server===
Once you've setup a Resin runtime, you will need to configure the server instance. The Configure Server dialog is fairly self-explanatory. Resin Home is taken from the Resin Runtime for which you are configuring a server. The working directory can and should be different than the Resin Home if you are running multiple instances against the same runtime. If you are running just one instance of Resin, it makes sense for Resin Home and the working directory to be the same, which is the default.
[[Image:Configure_server-1.png|center|frame|Configure Server]]
The port configuration is the HTTP port for Resin, the default for which is 8080. If you wish, you can use git-based remote deployment. In fact, this is the default choice while working with a remote server.
[[Image:configure_remote-1.png|center|frame|Configure Remote Server]]
You can also change the web apps directory for Resin (you can use relative or absolute paths). In most cases, the default of 'webapps' relative to the Resin working directory is probably fine. By default Eclipse projects are deployed as WAR files to the Resin web apps directory. If you want, you can skip the WAR packaging step by choosing 'Deploy as directory'. This will deploy the web application as in exploded form to the web apps directory instead and skip the WAR file creation altogether. Version 4.0.23 of Eclipse plugin adds a new "Deploy from workspace" deployment option. This option attempts to link WebContent directory of the Web Application project into Resin's 'webapps/$context' directory. The '$context' in the link's path is the name of the context of your Web Application. Along with the link a resin-web-pre.xml configuration file is created in WebContent/WEB-INF. The file configures a classloader that will look for classes in the output path of the Eclipse's project.
You are required to specify an admin user and password for the Resin server. You can use the defaults, but it is prudent to change it. In case of a remote server, the admin user and password values must match the ones for the remote server specified using the <resin:AdminAuthenticator> tag. Also, the remote server must have remote administration enabled using the <resin:RemoteAdminService> tag. For remote servers, you must also specify the remote debug port. The default port, 5005 should be sufficient for most cases. We will discuss remote debugging in greater detail in a later section.
After you configure the server, you can add one or more existing projects to the Resin server as the final step of adding a server. Once a server is added, you will see it in the 'Servers' view.
[[Image:Servers.png|center|frame|Resin instance in Servers View]]
===Local Server Configuration===
Unless you are using a remote server, you can configure servers right from Eclipse.
The configuration for each Eclipse Resin local server instance is stored under the /Servers directory in your Project Explorer. You will see the main resin.xml configuration file as well as admin-users.xml (pre-filled with the values you entered during server configuration), app-default.xml as well as health.xml. The plugin uses the configuration supplied with Resin for creating the instance configuration. For remote deployment and restart purposes it adds <resin:RemoteAdminService/> to resin.xml, in addition to enabling admin-users.xml.
[[Image:Resin_configuration_eclipse.png|center|frame|Resin Configuration Files]]
You can configure your local Resin instance appropriately for development using the configuration files in /Servers.
===Modifying Server===
You can modify the server once it is created, to a greater degree than the server creation wizard allows. In order to modify the server, right click on the instance and select open. This will open a property sheet in Eclipse showing all the configuration options you can modify, including the fine-grained launch configuration.
[[Image:Modify_server-1.png|center|frame|Modify Server]]
You can modify the server name, host name, underlying runtime, where the Resin configuration is stored, the server address, server port, automatic publish settings, server operation timeouts and so on. Generally, the defaults are suitable for most situations.
A new 'Do not deploy' deployment option is added as of release 4.0.24. This option allows Eclipse to execute its 'Run As' or 'Debug As' routine without actually deploying the app. You can think of this deployment mechanism as a 'No Operation Deployment'. This can be used when Resin is configured to deploy an application using <web-app> configuration element inside of resin.xm. e.g. <web-app id="/test" root-directory="c:/My Documents/.../workspace/test"/>.
===Server Operations===
The Resin plugin supports all of the common server operations supported by WTP (for details on these check out a good Eclipse/WTP tutorial for your Eclipse version). You can start a server, stop a server, restart a server, debug on the server, profile a server, add/remove projects to the server, clean the server, deploy/redeploy applications and so on.
[[Image:Server_operations.png|center|frame|Server Operations]]
A majority of these operations can be accessed by right-clicking the server instance or right clicking a project associated with a Resin server.
Note that for remote servers the only operations that are permitted are deployment, un-deployment and remote debugging. These operations are only enabled if the remote server is currently running. The plugin will automatically detect if a remote server is running and will update the remote server status in Eclipse.
[[Image:Remote_operations.png|center|frame|Remote Server Operations]]
Note that the context menu items for debugging are also disabled for remote servers. This is because remote servers can only be debugged as remote applications through the remote debug port. The following section describes how the plugin supports debugging a remote Resin instance.
===Remote Debugging===
The plugin supports debugging by automatically creating a remote application debugging profile in Eclipse when you create a remote server. For details on remote application debugging, check out a good Eclipse/WTP tutorial for your particular version.
To access the remote debugging profile, go to Run->Debug Configurations..., under Remote Applications you will see a debug profile corresponding to the remote server you created.
[[Image:Remote_debugging.png|center|frame|Remote Debugging Profile]]
If you need to, you can change the settings in the remote debugging profile. The project is the Eclipse project that the debugging breakpoints should reside in. The connection type for Resin must be Standard (Socket Attach). The host is the host name or IP address of the remote Resin server. The port is the port specified via -debug-port for the remote server instance. The default, 5005, should be good enough in most circumstances. Note, for remote debugging to work, you must start the remote server with -debug-port. For more information on -debug-port, look at the Resin command line help text.</rev>
</revisions>
</page>
<page pageid="191" ns="0" title="Resin 4 Application Server JMX Tutorial">
<revisions>
<rev xml:space="preserve">{{Cookbook}} {{Development}}
=JMX/Administration Tutorials=
=Simple JMX-managed Resource=
<p>
Resources can be JMX managed by exposing a management interface
and registering as an MBean.
</p>
==Files in this tutorial==
<table>
<tr>
<th>File</th>
<th>Description</th>
</tr>
<tr>
<td><code>WEB-INF/web.xml</code></td>
<td>Configures the JMX-managed bean</td>
</tr>
<tr>
<td><code>WEB-INF/classes/example/Basic.java</code></td>
<td>The resource bean implementation.</td>
</tr>
<tr>
<td><code>WEB-INF/classes/example/BasicMBean.java</code></td>
<td>The management interface for the bean.</td>
</tr>
<tr>
<td><code>index.jsp</code></td>
<td>Using the managed bean.</td>
</tr>
</table>
==JMX Resource==
<p>Any resource in Resin can be managed by JMX by implementing
an MBean interface and by specifying an MBean name. The interface
exposes the resource's methods to be managed.</p>
===The Basic resource===
<p>The <code>Basic</code> bean is the example resource implementation.
It exposes its managed interface by implementing a <code>BasicMBean</code>
interface. The <code>xxxMBean</code> naming convention lets JMX determine
which interface to use for management. The MBean interface will expose
the Data attribute to JMX.</p>
====Basic.java====
<pre>
package example;
public class Basic implements BasicMBean {
private String _data = "default";
public void setData(String data)
{
_data = data;
}
public String getData()
{
return _data;
}
}
</pre>
<p><code>BasicMBean</code> is the bean's management interface.
It exposes a single attribute, Data, as a getter/setter pair.
The name of the interface is important. Since the resource is named
<code>Basic</code>, the MBean interface will be
named <code>BasicMBean</code>.</p>
====BasicMBean.java====
<pre>
package example;
public interface BasicMBean {
public void setData(String data);
public String getData();
}
</pre>
===MBean names===
<p>MBeans are stored in the MBean server using
an <code>ObjectName</code> as its key. Essentially, the MBean server
stores the managed beans in a map using the mbean name as a key.</p>
<p>The mbean name consists of a set of &lt;name,value&gt; properties
and a "domain" used like a namespace. The properties allow for
querying related mbeans. For example, you could request for
all mbeans with "J2EEType=Servlet", which would return all the
managed servlets.</p>
<p>The example uses the name "example:name=basic".
"example" is the domain and the bean's single property is "name" with
a value of "basic". By convention, an mbean would normally also have
a "type" property, but this example is using a name as simple as possible.</p>
===web.xml configuration===
<p>The web.xml (or resin.conf) configures the resource with the
&lt;resource&gt; tag just as with
[doc|ioc-bean.xtp other resources]. The resources is
registered as an MBean by specifying an '''''mbean-name'''''.
</p>
====web.xml====
<pre>
<web-app xmlns="http://caucho.com/ns/resin">
<resource mbean-name="example:name=basic" type="example.Basic">
<init>
<data>An Example Resource</data>
</init>
</resource>
</web-app>
</pre>
<table>
<tr><th>tag</th><th>description
</th></tr><tr><td>resource</td><td>defines the resource
</td></tr><tr><td>mbean-name</td><td>the MBean name of the resource
</td></tr><tr><td>type</td><td>the class name of the resource bean
</td></tr><tr><td>init</td><td>Any bean-style configuration goes here
</td></tr><tr><td>data</td><td>The example bean's <code>setData</code> parameter.
</td></tr></table>
===Using the resource proxy===
<p>Resin's JMX implementation provides a proxy to
managed object using the interface for an API. You can, of course,
use the standard JMX interface, the proxy interface is much easier to
use.</p>
====index.jsp====
<pre>
<%@ page import='com.caucho.jmx.Jmx, example.BasicMBean' %>
<%
BasicMBean basic = (BasicMBean) Jmx.find("example:name=basic");
out.println("data: " + basic.getData());
%>
</pre>
====results====
<pre>
data: An example resource
</pre>
==Compatibility==
<p>The resource's code is completely compatible with other JMX
implementations. The proxy interface, however, is unique to Resin.
If you choose, you can use the JMX API to access the resource.
The configuration, of course, is Resin-dependent.</p>
=MBean listeners=
<p>
Example showing configuration of MBean event listeners.
</p>
==Files in this tutorial==
<table>
<tr>
<th>File</th>
<th>Description</th>
</tr>
<tr><td><code>WEB-INF/web.xml</code>
</td><td>Configures the JMX-managed bean
</td></tr><tr><td><code>WEB-INF/classes/example/Listener.java</code>
</td><td>The listener bean implementation.
</td></tr><tr><td><code>WEB-INF/classes/example/ListenerMBean.java</code>
</td><td>The management interface for the listener.
</td></tr><tr><td><code>WEB-INF/classes/example/Emitter.java</code>
</td><td>The emitter bean implementation.
</td></tr><tr><td><code>WEB-INF/classes/example/EmitterMBean.java</code>
</td><td>The management interface for the emitter.
</td></tr><tr><td><code>WEB-INF/classes/example/ListenerServlet.java</code>
</td><td>Using the managed bean.
</td></tr></table>
==Emitter and Listener==
<p>JMX provides a general notification capability where MBean
'''''emitters''''' send data to MBean '''''listeners'''''. Any managed
bean can be an emitter or a listener by implementing the
proper interfaces. The listeners are hooked up to the emitters either
in the configuration file or through MBeanServer calls.</p>
===Listener===
<p>A listener implements <code>NotificationListener</code> to receive
<code>Notification</code> events. The notification contains information
for the type of the notification, the sender of the notification, and
any notification-specific information.</p>
<p>The listener implements the single <code>handleNotification</code>
method. It's parameters are the notification and an opaque
'''''handback''''' object. The '''''handback''''' is specified during
the listener registration and can be any information the listener
wants.</p>
====Listener.java====
<pre>
package example;
import javax.management.NotificationListener;
import javax.management.Notification;
public class Listener
implements NotificationListener, ListenerMBean {
private int _count;
public void handleNotification(Notification notif,
Object handback)
{
_count++;
}
public int getNotificationCount()
{
return _count;
}
}
</pre>
===Emitter===
<p>The Emitter sends notifications. Any managed bean which implements
the <code>NotificationEmitter</code> interface can be an emitter. Many
Emitters will extend the <code>NotificationBroadcasterSupport</code>,
although this is not required.</p>
<p><code>NotificationBroadcasterSupport</code> will handle the logic
for adding and removing listeners as well as sending notifications to
the proper listener. By extending
<code>NotificationBroadcasterSupport</code>, the emitter only needs to
call <code>sendNotification</code> to send the notification.</p>
<p>The first argument for the <code>Notification</code> is the notification
type. Because each emitter can send multiple notifications, the type
tells the listener which event has happened.</p>
<p>The second argument is typically the <code>ObjectName</code> for
the emitter. Often, emitters will use
the <code>MBeanRegistration</code> interface to find out the
<code>ObjectName</code>.</p>
====Emitter.java====
<pre>
package example;
import javax.management.NotificationBroadcasterSupport;
import javax.management.Notification;
/**
* Implements an MBean which sends notifications.
*/
public class Emitter extends NotificationBroadcasterSupport
implements EmitterMBean {
private long _sequence;
/**
* Sends a notification.
*/
public void send()
{
Notification notif;
notif = new Notification("example.send", this, _sequence++);
sendNotification(notif);
}
}
</pre>
===web.xml configuration===
<p>The web.xml (or resin.conf) configures the resource with the
&lt;resource&gt; tag just as with
[doc|ioc-bean.xtp other resources]. The resources is
registered as an MBean by specifying an '''''mbean-name'''''.
</p>
====web.xml====
<pre>
<web-app xmlns="http://caucho.com/ns/resin">
<resource mbean-name="example:name=emitter"
type="example.Emitter">
</resource>
<resource mbean-name="example:name=listener"
type="example.Listener">
<listener mbean-name="example:name=emitter" handback="tutorial"/>
</resource>
</web-app>
</pre>
<table>
<tr><th>tag</th><th>description
</th></tr><tr><td>resource</td><td>defines the resource
</td></tr><tr><td>mbean-name</td><td>the MBean name of the resource
</td></tr><tr><td>type</td><td>the class name of the resource bean
</td></tr><tr><td>listener</td><td>registers the mbean with a notification emitter mbean
</td></tr><tr><td>handback</td><td>a custom object to be passed back to the listener
</td></tr></table>
===Using the listener===
<p>This example provides a <code>send()</code> method to
trigger a notification, but most notifications occuring when
specific events occur, e.g. when a pool fills up.</p>
<p>In this case, invoking the <code>send()</code> method triggers
the notification which will be sent to any waiting listeners. Calling
<code>listener.getNotificationCount()</code> checks that the listener
is getting called back.</p>
====ListenerServlet.java====
<pre>
public class ListenerServlet extends GenericServlet {
private EmitterMBean _emitter;
private ListenerMBean _listener;
public void setEmitter(EmitterMBean emitter)
{
_emitter = emitter;
}
public void setListener(ListenerMBean listener)
{
_listener = listener;
}
public void service(ServletRequest request,
ServletResponse response)
throws ServletException, IOException
{
PrintWriter out = response.getWriter();
_emitter.send();
out.println("listener count: " + _listener.getNotificationCount());
}
}
</pre>
====results====
<pre>
count: 15
</pre>
<results title="log">
[15:37:15.545] notification(type=example.send,handback=tutorial)
[15:37:16.624] notification(type=example.send,handback=tutorial)
[15:37:17.453] notification(type=example.send,handback=tutorial)
</results>
===Configuration with Dependency Injection===
<p>The ListenerServlet example follows the
Dependency Injection pattern. Resin's web.xml will assemble the
correct EmitterMBean and ListenerMBean. Using the Dependency Injection
pattern simplifies the servlet, makes it more configurable,
and more testable.</p>
<p>The configuration takes advantage of the "mbean:" JNDI scheme in Resin.
The name following "mbean:" is used to lookup the mbean instance. The
"mbean:" scheme then constructs a proxy for the mbean. The proxy
of the JNDI lookup is then passed to <code>setEmitter</code>
and <code>setListener</code>.</p>
====web.xml====
<pre>
<servlet-mapping url-pattern="/listener"
servlet-class="example.ListenerServlet">
<init>
<emitter>\${jndi:lookup("mbean:example:name=emitter")}</emitter>
<listener>\${jndi:lookup("mbean:example:name=listener")}</listener>
</init>
</servlet-mapping>
</pre>
==Compatibility==
<p>Notifications and listeners are part of the JMX standard.
Client MBean proxies are standard and can be generated
with <code>javax.management.MBeanServerInvocationHandler</code>
</p>
<p>The &lt;resource&gt; configuration is Resin-specific. The support
for the Dependency Injection for servlet configuration
and the "mbean:" JNDI scheme are also Resin-specific.</p>
=Using MBeanRegistration=
<p>
MBeans can implement the MBeanRegistration interface to find the
ObjectName and MBeanServer they're registered with.
</p>
==Files in this tutorial==
<table>
<tr>
<th>File</th>
<th>Description</th>
</tr>
<tr><td><code>WEB-INF/web.xml</code>
</td><td>Configures the JMX-managed bean
</td></tr><tr><td><code>WEB-INF/classes/example/Test.java</code>
</td><td>The resource bean implementation.
</td></tr><tr><td><code>WEB-INF/classes/example/TestMBean.java</code>
</td><td>The management interface for the bean.
</td></tr><tr><td><code>index.jsp</code>
</td><td>Using the managed bean.
</td></tr></table>
==MBeanRegistration==
<p>Frequently, a managed bean will either need
its <code>ObjectName</code> or its <code>MBeanServer</code>. When the
bean implements the <code>MBeanRegistration</code> interface, the
JMX server tells the bean its <code>ObjectName</code> on registration.</p>
<p>The bean can verify the <code>ObjectName</code> or even
returning a different name, although returning a different
<code>ObjectName</code> is generally a bad idea in most cases since it
makes the to configure.</p>
====Test.java====
<pre>
package example;
import javax.management.ObjectName;
import javax.management.MBeanServer;
import javax.management.MBeanRegistration;
public class Test implements TestMBean, MBeanRegistration {
private ObjectName _name;
public ObjectName getObjectName()
{
return _name;
}
public ObjectName preRegister(MBeanServer server, ObjectName name)
throws Exception
{
_name = name;
return name;
}
public void postRegister(Boolean registrationDone)
{
}
public void preDeregister()
throws Exception
{
}
public void postDeregister()
{
}
}
</pre>
===Client===
<p>The client JSP asks for the object's ObjectName to see the ObjectName
passed in the <code>preRegistration</code> call.</p>
====index.jsp====
<pre>
<%@ page import='com.caucho.jmx.Jmx, example.BasicMBean' %>
<%
BasicMBean basic = (BasicMBean) Jmx.find("example:name=test");
out.println("ObjectName: " + test.getObjectName());
%>
</pre>
====results====
<pre>
ObjectName: example:name=test
</pre>
==Compatibility==
<p>MBeanRegistration is part of the JMX specification.</p>
=Using the JMX MBeanServer API=
<p>
Example showing JMX-managed resources using the MBeanServer API.
</p>
==Files in this tutorial==
<table>
<tr>
<th>File</th>
<th>Description</th>
</tr>
<tr><td><code>WEB-INF/web.xml</code>
</td><td>Configures the JMX-managed bean
</td></tr><tr><td><code>WEB-INF/classes/example/Test.java</code>
</td><td>The resource bean implementation.
</td></tr><tr><td><code>WEB-INF/classes/example/TestAdmin.java</code>
</td><td>The management interface for the bean.
</td></tr><tr><td><code>index.jsp</code>
</td><td>Using the managed bean.
</td></tr></table>
==JMX Resource==
<p>Any resource in Resin can be managed by JMX by implementing
an MBean interface and by specifying an MBean name. The interface
exposes the resource's methods to be managed.</p>
===The Test resource===
<p>The test resource is identical to the
[../jmx-basic/index.xtp basic example] but implements
<code>TestAdmin</code> instead of <code>TestMBean</code>. Because
the name <code>TestAdmin</code> does not conform to the MBean convention,
the web.xml will need to specify the interface explicitly.</p>
====Test.java====
<pre>
package example;
public class Test implements TestMBean {
private String _data = "default";
public void setData(String data)
{
_data = data;
}
public String getData()
{
return _data;
}
}
</pre>
===web.xml configuration===
<p>The web.xml (or resin.conf) configures the resource with the
&lt;resource&gt; tag just as with
[doc|ioc-bean.xtp other resources]. The resources is
registered as an MBean by specifying an '''''mbean-name'''''.
</p>
====web.xml====
<pre>
<web-app xmlns="http://caucho.com/ns/resin">
<resource mbean-name="example:name=basic"
type="example.Test"
mbean-interface="example.TestAdmin>
<init>
<data>An Example Resource</data>
</init>
</resource>
</web-app>
</pre>
<table>
<tr><th>tag</th><th>description
</th></tr><tr><td>resource</td><td>defines the resource
</td></tr><tr><td>mbean-name</td><td>the MBean name of the resource
</td></tr><tr><td>type</td><td>the class name of the resource bean
</td></tr><tr><td>mbean-interface</td><td>the class name to use as the managed interface
</td></tr><tr><td>init</td><td>Any bean-style configuration goes here
</td></tr><tr><td>data</td><td>The example bean's <code>setData</code> parameter.
</td></tr></table>
===Using MBeanServer===
<p>MBeanServer is the main JMX interface for managing resources.
Although it is less convenient than Resin's proxy interface, it has the
advantage of being part of the JMX standard.</p>
<p>Resin stores the MBeanServer it uses for resources in WebBeans.
Since MBeanServer is unique, the application can use <code>@In</code>
to inject the server.</p>
<p>All management of an MBean uses the MBeanServer and the MBean's
ObjectName. In this case, the ObjectName is "example:name=test".</p>
<p>The MBeanServer has three primary management calls:
<code>getAttribute</code>, <code>setAttribute</code>,
and <code>invoke</code>. This example just uses <code>getAttribute</code>.
</p>
====index.jsp====
<pre>
<%@ page import='javax.webbeans.In, javax.management.*, example.TestAdmin' %>
<%!
@In MBeanServer _server;
%><%
ObjectName name = new ObjectName("example:name=test");
out.println("data: " + _server.getAttribute(name, "Data"));
%>
</pre>
====results====
<pre>
data: An example resource
</pre>
==Compatibility==
<p>Using the MBeanServer interface is compatible with other
JMX implementations. The two Resin-dependencies are the configuration
and how to obtain the Resin MBeanServer. Different JMX implementations
will use a different technique to get the MBeanServer, so it's a good
idea to encapsulate getting the MBeanServer in a class that you can
change for different implementations.</p></rev>
</revisions>
</page>
</pages>
</query>
</api>