Rebranding the JMC

As an OEM, you can rebrand the JRun Management Console (JMC) so that it appears to be part of your application toolset. You can also add your own panels to include settings that are specific to your application. You use the supplied JMC source code to rebrand the JMC.

The JMC is implemented as a web application on the admin JRun server. The source code for this application is included in the SDK. You can access it in the following directory:

sdk_root/src/jmc

JMC source code overview

Retail customers use the JMC application to manage JRun server, JVM, and web application settings. The JMC application source code contains the following top-level files and directories:
Files and directories
Description
META-INF
Contains the EAR file settings in the application.xml file.
tools
Contains tools used for localization of the JMC application.
build.xml
Contains the description of the project, tasks, targets, and properties used by Ant to compile the JMC application.
webapp
Contains most of the files used by the JMC, including images, JSPs, error pages, style sheets, and helper classes. The subdirectories in /webapp are described in the table in the next section, "Compiling the JMC" .

Looking at the JMC source code is especially helpful when you are writing your own JSPs that use the JMC custom tag library as described in Chapter 6, "Using the JMC Custom Tag Library".

Compiling the JMC

You can build the JMC with Ant by using the included build.xml file in the top-level JMC source directory. For instructions on installing and configuring Ant, see http://jakarta.apache.org/ant/.

You can execute a simple compilation using the default settings by executing the ant command from the JMC application source code top-level directory. The default settings compile the full JMC application and deploy it in the jrun_root/servers/admin directory.

To change the default settings, you must edit the build.xml files included with the JMC source code.

The following table describes the targets in the top-level build.xml file of the JMC application:
Target
Description
compile
Compiles the JMC application with an open directory structure. The open directory must be in the server deploy directory.
This is the default target for the project.
package
Compiles the JMC application as an EAR file rather than an open directory structure. Deploys the jmc-app.ear file to the admin JRun server.
The package target is not invoked by default.
l10n_extract
Compiles the JMC application using localization-aware settings for either Japanese or French. Deletes the existing copy of tranlation.xml and generates a new one.
l10n_clean
Deletes existing files in directories used by the localization-related targets. By default, Any invokes the l10n_clean target before compiling the new localized application.
l10n_genjsp
Generates the JSPs in Japanese or French. Uses settings in the translation_ja.xml and translation_fr.xml.
javadoc
Generates Javadocs for all classes and packages in /WEB-INF/classes and stores the HTML files in the /docs directory.
The javadoc target is not invoked by default.
clean
Deletes existing jmc-app.ear files and files in the /WEB-INF/classes and /WEB-INF/jsp directories.
By default, Ant invokes the clean target before compiling the new JMC application.
clean-build-area
Called only when src.depend isn't defined.

The top-level build.xml file invokes subordinate build files based on your initial target. The following table describes the subordinate build files:
Build file
Description
/webapp/build.xml
Contains the logic for compiling and deploying the JMC web application.
/tools/build.xml
Generates localized versions of the JMC.

Creating a custom JRun interface

To let your customers interact with the JRun servers and services but still maintain your application's brand, you can do one of the following:

Hiding the JMC

You might not want your customers to have access to the JMC at all. In this case, remove the JMC merge module (Windows) or the JMC fileset (UNIX) before creating your installer.

You can include the JMC if you plan to use it for troubleshooting. You can include the JMC, and then disable the admin JRun server, so that you (or your field technical support) can access it only when necessary.

Deploying applications outside the JRun directory structure

To deploy your application outside of the JRun hierarchy, you can use the addDeployDirectory method of the DeployerService. JRun provides programmatic access to the DeployerService, or you can modify the jrun.xml file that defines the DeployerService's settings.

The following JSP page uses the invoke tag in the JMC custom tag library to add a hot deploy directory:

<%@ taglib prefix="jmcmgmt" uri="WEB-INF/lib/jmcmgmt.jar" %>
...
<jmcmgmt:invoke server="default" mbean="DefaultDomain:service=DeployerService" method="addDeployDirectory" errorId="error">
��<jmcmgmt:parameter value="C:\MyApplication\deploy"/>
</jmcmgmt:invoke>
<% if (error == null) {
��out.println("successfully added directory");
} else {
��error.printStackTrace();
��out.println("failed - " + error.getMessage());
} %>

The preceding code adds the following line to the DeployerService's definition in the jrun.xml file:

<attribute name="deployDirectory">c:/MyApplication/deploy</attribute>

JRun deploys this application when you add a web application to this directory. You are not required to restart the JRun server to deploy the application.

For more information about using the JMC tag library, see Chapter 6, "Using the JMC Custom Tag Library".

For more information on using the DeployerService, see JRun Administrator's Guide.

 

Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/jrun/4/JRun_SDK_Guide/embedding6.htm