JRun administrators must understand the following JRun and J2EE fundamentals:
To administer JRun effectively, you must know the usage and purpose of certain important files and locations. The following table describes the name, location, and purpose of files and directories typically used by an administrator:
There are a number of ports used by JRun servers and you must be aware of their settings and uses when administering JRun. This is especially important when adding new JRun servers.
These ports must be unique for each JRun server, as follows:
If necessary, individual EJBs can get their own RMI broker, for example, to use special socket factories (EJB over SSL), or to better distribute the remote invocation load. You configure individual RMI brokers in the jrun-ejb-jar.xml file. If an RMI broker is not specified in jrun-ejb-jar.xml, JRun uses the global shared RMI broker. All RMI brokers are clusterable.
Context stub to the client. Remote clients name this port in the Context.PROVIDER_URL property, which is passed to the InitialContext constructor when initiating remote communications for EJB, JMS, JRun services, and so on. (Local clients can use an empty InitialContext constructor.) You define this port in the JRun server's jndi.properties file.Context stub through the JNDI naming server port, JRun uses the JNDI RMI port for all remote communications. You specify this port in the JRun server's jndi.properties file. By default JRun servers use port 0, which causes JRun to choose a random port.The following figure shows how clients interact with commonly used JRun ports:
When you add JRun servers, you should be aware of existing port settings and ensure that unused ports are assigned.
You can start and stop JRun using the following techniques:
Note: You can also start and stop JRun using the JMC. However, that is not typically used in a production environment.
These techniques are explained in the following sections.
The JRun server control panel, also called the launcher, is a Java Swing application that you can use to start, restart, and stop JRun servers. You execute the launcher by running the jrun.exe file (Windows) or the jrun executable (UNIX), both of which are in the jrun_root/bin directory. The launcher contains buttons to start, restart, and stop JRun servers.
The list of servers displayed in the launcher is controlled by the jrun_root/lib/servers.xml file. When you create a server in the JMC, JRun automatically adds the server to the servers.xml file. You can also edit this file in a text editor, if necessary, specifying the following attributes:
The following code shows the default servers.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE servers PUBLIC "-//Macromedia, Inc.//DTD servers 4.0//EN"
"http://jrun.macromedia.com/dtds/servers.dtd">
<servers>
<server>
<name>default</name>
<directory>{jrun.home}/servers/default</directory>
</server>
<server>
<name>samples</name>
<directory>{jrun.home}/servers/samples</directory>
</server>
<server>
<name>admin</name>
<directory>{jrun.home}/servers/admin</directory>
</server>
</servers>
The JVM Settings panel of the JMC lets you make additional startup specifications for a JRun server, including classpath, JNI settings, and VM size.
You can start JRun using the jrun.exe and jrun shell script command-line utilities. Use the following syntax:
jrun {options} {server-name}
The following table describes the options:
J2EE applications interact with a variety of external systems, called resources. Typical external resources include the following:
For complete information on administering resources, see Chapter 5, "Resources".
In the application development and testing phases, security, performance and other production considerations are low priorities. However, as the JRun administrator, it is your responsibility that is the production environment and production servers must perform optimally and securely.
The following table describes steps that you can take when moving a JRun server to production:
| Action |
Description |
|---|---|
| Disable JWS |
If your application uses the web server connector, disable the JRun web server (JWS). For more information, see "WebService". |
| Create servlet mappings |
Disable the /servlet mapping in the SERVER-INF/default-web.xml file. Create servlets and servlet mappings in the web.xml file. For more information, see JRun Programmer's Guide. |
| Disable hot deploy |
Macromedia strongly recommends that you disable hot deploy in a production environment. For more information, see "DeployerService". |
| Remove FileServlet mapping for / |
If your application consists solely of servlets and JSPs, disable the FileServlet servlet mapping for / in the SERVER-INF/default-web.xml file. |
| Disable web services |
If your application does not use web services, disable the AxisServlet mappings in the SERVER-INF/default-web.xml file. |
| Disable JSP translation |
If you have precompiled all JSPs in the application, set the translationDisabled attribute to true in the SERVER-INF/default-web.xml file. For more information, see JRun Assembly and Deployment Guide. |
| Disable automatic compilation |
Set the jrun-web.xml reload and compile elements to false. For more information, see JRun Assembly and Deployment Guide. |
| Control web server access |
Ensure that the interface attribute of the ProxyService is set to the IP address of the production web server. For more information, see "Simple distributed installation". |
| Encrypt passwords |
If your application is using the JRun default security implementation, ensure that passwords in the SERVER-INF/jrun-users.xml file are encrypted. For more information, see "Encryption". |
| Disable directory browsing |
Disable web browser directory browsing by setting the browseDirs parameter to false for FileServlet in the SERVER-INF/default-web.xml file. |
| Remove samples server |
Ensure that the samples JRun server is not deployed. This is not a security risk but it does eliminate the possibility of outside users wasting resources while accessing the samples applications. |
| Remove documentation |
Remove the jrun_root/docs directory. This is not a security risk but it does eliminate the possibility of outside users wasting resources while accessing the documentation. |
Macromedia continually updates the best practices and recommendations for production deployment. For the latest information on JRun production deployment, see the JRun Support Center (http://www.macromedia.com/support/jrun/).
RSS feed | Send me an e-mail when comments are added to this page | Comment Report
Current page: http://livedocs.adobe.com/jrun/4/JRun_Administrators_Guide/adminrole3.htm
Comments
danger42 said on Jul 8, 2002 at 4:49 PM :