Using the eApps Virtual Server in the Cloud Hosting service, Java SE 7 or Java SE 8, and GlassFish Server 4, you can create web sites and web applications with dynamic content for your customers and users.
 |
Pay careful attention to the amount of RAM allocated to your Virtual Server if you are deploying GlassFish applications. GlassFish is very memory intensive. For a small GlassFish application, start with at least 1024 MB of RAM, and be prepared to scale upwards. |
If you do not need the advanced features of GlassFish, we recommend that you use a less resource intensive JSP/servlet container such as Tomcat.
Installing GlassFish
Installing GlassFish using a Control Panel
Installing GlassFish using the command line
Starting and stopping GlassFish
Using the Control Panel
Using the Command line
Using the asadmin tool (command line)
Using the GlassFish Administration Console
Deploying applications using the GlassFish Admin Console
GlassFish application deployment using Apache
1. Apache as a front-end to GlassFish using mod_jk
2. Apache as a front end to GlassFish using mod_proxy_ajp
GlassFish application deployment without Apache
How to set up GlassFish to run without Apache
Deployment Example
Multiple Sites With GlassFish (Additional Virtual Servers)
Creating a new Virtual Server in GlassFish
Deploying the second application in GlassFish
The asadmin Utility
Create and starting a new domain (a GlassFish administrative domain)
Creating a new Virtual Server for a domain, and deploying an application to the Virtual Server
The pkg Utility
Installing the pkg utility
Using the pkg utility
Tuning GlassFish
Java Heap Settings – an overview
GlassFish is usually part of the operating system template used with the Virtual Server was created. This template installs GlassFish v4, Java SE 8, and mod_jk.
If you did not select the CentOS GlassFish template when you created the Virtual Server, you will need to install GlassFish, Java SE 7 or 8, and mod_jk if your deployment approach will use that. You will also need to install a database and database connector.
|
If you are installing GlassFish from a Control Panel, make sure to install Java SE FIRST. If you try to install GlassFish without a JVM installed, the GlassFish service will not start. |
If you are using the ISPmanager Control Panel, you can install GlassFish and related applications from that Control Panel.
For ISPmanager 4, go to Server Settings > Applications. Make sure to install Java SE 7 or Java SE 8 first, then install GlassFish and any other related applications. More information on installing applications can be found here - Installing Server Applications
For ISPmanager 5, go to Settings > Features. Make sure to install Java SE 7 or Java SE 8 first, then install GlassFish and any other related applications. More information on installing applications can be found here - Installing Features (Server Applications)
Information on how to tell which version of ISPmanager you are using can be found here - ISPmanager versions
You can install GlassFish and related applications from the command line of the Virtual Server. You will need to install either Java SE 7 or Java SE 8 and several Java plugins first, and then install GlassFish. All of this is done using yum.
To install Java SE 7 and the related applications, use the yum install -y java-1.7.0-sun java-1.7.0-sun-plugin java-1.7.0-sun-jdbc java-1.7.0-sun-src java-1.7.0-sun-devel java-1.7.0-sun-javafx command.
[root@eapps-example ~]# yum install -y java-1.7.0-sun java-1.7.0-sun-plugin java-1.7.0-sun-jdbc java-1.7.0-sun-src java-1.7.0-sun-devel java-1.7.0-sun-javafx
To install Java SE 8 and the related applications, use the yum install -y java-1.8.0-oracle java-1.8.0-oracle-plugin java-1.8.0-oracle-jdbc java-1.8.0-oracle-src java-1.8.0-oracle-devel java-1.8.0-oracle-javafx command.
[root@eapps-example ~]# yum install -y java-1.8.0-oracle java-1.8.0-oracle-plugin java-1.8.0-oracle-jdbc java-1.8.0-oracle-src java-1.8.0-oracle-devel java-1.8.0-oracle-javafx
To install GlassFish, use the yum install -y glassfish4 command.
[root@eapps-example ~]# yum install -y glassfish4
If you are going to use the mod_jk approach for GlassFish, you will need to install mod_jk using the yum install -y mod_jk.
[root@eapps-example ~]# yum install -y mod_jk
If you are going to install your database from the command line, please see the specific user guide for that database. Which databases are available will depend on your OS Template (CentOS 6 or CentOS 7).
CentOS 6 - either MySQL or PostgreSQL is available to install.
CentOS 7 - either MariaDB or PostgreSQL is available to install. If you want to install MySQL you need to use the official MySQL Community repo or a third-party repo (this is explained in the MySQL user guide).
You will also need to install either the MySQL JDBC Driver for MySQL or MariaDB, or the PostgreSQL JDBC Driver for PostgreSQL. This is explained in the user guide for each database.
All GlassFish configurations are done either through the GlassFish Administration Console which is located at http://eapps-example.com:4848, or by using the command line asadmin tool as the gfish user.
Due to the extreme amount of complexity available with GlassFish, it is impossible to explain anything more than how to deploy a simple application. This User Guide will focus on the minimum configurations required for using GlassFish. Please click on the Help button on the top right of the GlassFish Admin Console for details on advanced configurations.
If you are new to GlassFish it is highly recommended that you get a basic understanding of how GlassFish works, and how all the components interact. The official GlassFish Wiki is a good starting point - http://wikis.sun.com/display/GlassFish/GlassFishWiki.
The first thing to understand is how GlassFish maps a request to a given application. GlassFish uses domains (an administrative area), instances, virtual servers, hosts (the domain names or IP addresses which to serve a applications for) and web modules (applications that are deployed) to determine what application to serve.
Upon installation, there is a domain (domain1), an instance (server), a virtual server (server) is created and the hostname of the VS is set by default as a host to serve applications.
 |
Please note that the term domain as it is related to GlassFish is not to be confused with a domain name as in DNS domains. A domain in GlassFish is an instance of a single application server installation. |
Instead of another installation of GlassFish (which would be required when using Tomcat or JBoss) you can simply create multiple domains (administrative domains) each with its own administration settings for serving applications totally separate from the other domains.
Each domain will need a set of ports to bind on for its service. Since the standard ports are taken by the default domain (domain1) different port numbers must be assigned. You must use the asadmin command line tool to create a domain. An example is given in the The asadmin Utility section of this documentation. Please see the official GlassFish documentation for more information.
GlassFish can be stopped, started or restarted from the Control Panel, the command line, or by using the command line asadmin tool. Be aware that these commands will stop, start, or restart ALL the administrative domains and instances - in other words, these commands will restart the entire GlassFish server.
The way to start, stop, and restart GlassFish from ISPmanager will depend on which version of ISPmanager you are using.
For ISPmanager 4, go to Management Tools > Services, and highlight the glassfishv4 service. Then click on Stop, Start, or Restart in the upper right corner. More information about managing service in ISPmanager 4 is available here - Managing Services
For ISPmanager 5, go to System > Services, and highlight the glassfishv4 service. Then click on Start, Stop, or Restart in the upper left corner. More information about managing services in ISPmanager 5 is available here - Managing Services
Information on how to tell which version of ISPmanager you are using can be found here - ISPmanager versions
The following commands must be run from the command line of the Virtual Server while logged in as SSH, as the root user.
For CentOS 6, use the service glassfish start, service glassfish stop, and service glassfish restart` commands:
[root@eapps-example ~]# service glassfish start
[root@eapps-example ~]# service glassfish stop
[root@eapps-example ~]# service glassfish restart
For CentOS 7, use the systemctl start glassfish, systemctl stop glassfish, and systemctl restart glassfish commands:
[root@eapps-example ~]# systemctl start glassfish
[root@eapps-example ~]# systemctl stop glassfish
[root@eapps-example ~]# systemctl restart glassfish
If you have multiple administrative domains running and want to control a single domain please use the asadmin tool as shown below.
| [root@eapps-example ~]# su - gfish -bash-4.1$ asadmin stop-domain domain1 Waiting for the domain to stop ... Command stop-domain executed successfully. -bash-4.1$ -bash-4.1$ asadmin start-domain domain1 Waiting for domain1 to start ....... Successfully started the domain : domain1 domain Location: /opt/glassfish4/glassfish/domains/domain1 Log File: /opt/glassfish4/glassfish/domains/domain1/logs/server.log Admin Port: 4848 Command start-domain executed successfully. -bash-4.1$ |
You can login to the GlassFish Admin Console URL at http://eapps-example.com:4848 or http://IP_Address:4848 (substitute your own domain name for eapps-example.com).
The default login and password for the GlassFish Admin Console are located in the /opt/glassfish4/.console-secret directory.
The first time you try to access the GlassFish Admin Console, the software has to install some components and initialize some system functions. It may take 5 to 8 minutes (possibly more, depending on your available system resources) for the GlassFish Admin Console to show in the browser. Please be patient.
After you log in to the Admin Console, you are taken to the main screen.
To deploy your application using the GlassFish Admin Console, follow the steps below. These steps will work for any of the eApps supported methods for deploying GlassFish applications.
|
The navigation menus in the GlassFish Admin Console can collapse and expand depending on the context. Please take a few moments as you move around the Admin Console to familiarize yourself with all the options. |
In the GlassFish Admin Console screen, click on Common Tasks in the left navigation pane to make sure you are on the correct screen. Then click on Deploy an Application in the Deployment section of the main screen.
This takes you to the Deploy Applications or Modules screen.
Location
Packaged File to Be Uploaded to the Server - click on Choose File to browse the file system on your local computer for the file to upload and deploy.
Local Packaged File or Directory That is Accessible from GlassFish Server - this allows you to browse the file system on the Virtual Server for the file to deploy.
Type - using the drop down menu, choose from one of the following:
Once you choose the packaged file to upload or deploy, the Deploy Applications or Modules screen expands. The options available will change depending on the Type chosen. This example uses a hello.war file, so Web Application is the default choice. Depending on the type of file you are uploading, you may have different options.
Context Root – this is a string that identifies the application. In the URL for a Web Application, the Context Root immediately follows the port number (http://host:port/context-root/...). The Context Root takes the same name as the Application Name, and can be changed to match.
Application Name – a unique name for the application. If the application is uploaded using the GlassFish Admin Console, the name will be the file name, minus the file extension. For example, if you uploaded hello.war, the Application name would be hello. You can name the application anything you want, as long as the name is unique.
Virtual Servers – if you have created additional Virtual Servers, there will also be a Virtual Servers field, where you can select which Virtual Server to use for the application.
Status – by default, an application is Enabled (available) as soon as it is deployed. To disable the application so that it is unavailable after leaving the Deploy Applications or Modules page, uncheck the Enabled checkbox.
Precompile JSPs – check this box to precompile the JSP pages. If this is not checked, the JSP pages are compiled at runtime, which can result in a performance hit for production environments.
Run Verifier – this verifies the structure and contents of the file. Be aware that verification of large files can be quite time consuming and resource intensive. Only check this if you suspect the file to be corrupt or non-portable. To use the Verifier, you must have the correct Verifier packages installed from the Update Tool, otherwise this option is ignored.
Force Redeploy - if the application is already deployed the option forces redeployment.
Keep State - this retains any active web sessions for the application if it is redeployed.
Preserve Application Scoped Resources - this preserves all application-scoped resources, and restores them if the application is redeployed.
Libraries - a comma separated list of .JAR files specific to this module or application.
Description - a description of the application
|
The available options in this screen will vary depending on the Type chosen. Click on Help in the upper right corner of the screen to see a full listing for all the options for each Type. |
Once you have set up your configuration for the application, click OK. GlassFish will process and enable your application.
Assuming you have not yet set up any mod_jk or mod_proxy_ajp configuration, your application will be available at http://eapps-example.com:8080/app_name (substitute your domain name or IP address for eapps-example.com).
Once that is finished, you will see your new application on the Applications screen, which you can access again by clicking on Common Tasks > Applications from the left navigation pane, or by clicking on Common Tasks in the left navigation pane, and then List Deployed Applications in the main screen.
Clicking on Deploy will take you to the screen where you can deploy another application.
Clicking on the Name of the application will take you to a screen where you can edit and reconfigure the application. Enabled shows if the application is currently available, and Engines shows the Type that was chosen.
In the Action section, you have Launch, Redeploy, and Reload.
Launch - clicking on Launch will take you to a page that shows the current URL for your deployed application. For this example, the URL for the application is http://eapps-example.com:8080/help.
Redeploy - this will take you back to the screen where you can upload your application and choose the configuration. If you need to change the configuration options for the application, this is where you need to go.
Reload - this will restart the application
As always, see the available Help for more information.
The general method to deploy your applications is the same, no matter which Apache deployment approach you take (mod_jk or mod_proxy_ajp). If you use the Standalone deployment approach, you will need to make a change to the Context Root, which is covered in the section for Standalone deployment.
Your Virtual Server includes the Apache web server as part of the base environment (if you are using an eApps supported template). Apache is designed to serve static content, perl scripts, php scripts, and other types of content that require a web server, whereas GlassFish is designed to serve Java EE applications.
Using the Apache web server, you can deploy your GlassFish application in two ways - using mod_jk or using mod_proxy_ajp. Both give the same end result, it is basically just a matter of preference as to which one you choose.
Note that the term "deploy" here is used to reference how your GlassFish application interacts with the Apache web server. By this point, you will have also "deployed" your Java application to GlassFish.
Apache as a front end to GlassFish using mod_jk - this approach allows you to control what content is served by GlassFish and what content (if any) is served by the Apache web server. You will need to specify directives that tell Apache what content to pass on to GlassFish. mod_jk is mature, widely used, and also has advanced features for load balancing and other techniques. The majority of eApps customers use this approach.
Apache as a front end to GlassFish using mod_proxy_ajp - this approach is similar to mod_jk but is simpler to use and allows you to take better advantage of Apache’s capabilities, such as mod_rewrite. It provides features for load balancing as well, but is not as sophisticated as mod_jk.
The Apache web server runs securely on port 80, and GlassFish runs securely on port 8080. This means that by default, the URL for your application will be either http://eapps-example.com:8080 or http://eapps-example.com:8080/mywebapp.
With mod_jk, you can have GlassFish run securely on its normal port (8080) and have Apache forward requests from port 80 to GlassFish. This means that you no longer need the :8080 in the URL, so that your application URL will now be http://eapps-example.com or http://eapps-example.com/mywebapp. To use mod_jk as the front-end to Apache, you will need to install the mod_jk application. This is done from the ISPmanager > Server Settings > Applications > mod_jk
mod_jk Syntax Overview
To enter mod_jk directives, you need to know the correct syntax. The standard format of a mod_jk directive is:
JkMount /servlet/* ajp13
JkMount – this is the JkMount directive that calls mod_jk.
/servlet/* - this is the regular expression (regex) that is matched in the referring URL and is passed to the servlet container. Typically, this is the only part of a JkMount directive you will change. Note the wildcard asterisk (*) at the end of servlet/*. If you forget the asterisk, the directive will not pass the request to your application correctly.
ajp13 – this is the internal handler that will receive the request. Unless you are a very advanced user you will never change this part of the directive. eApps only supports the ajp13 handler.
The above directive will pass all URLs with a suffix of /servlet/ to the ajp13 handler and the request will be handled by GlassFish. A URL with a suffix of /mail will still be handled by Apache.
You can add the mod_jk directives from a Control Panel or from the command line of the Virtual Server.
Deployment with GlassFish serving JSP and Servlets at eapps-example.com/mywebapp, Apache serving all other content
In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://eapps-example.com/mywebapp or http://www.eapps-example.com/mywebapp with Apache serving other applications provided by eApps.
Deploy your applications using the steps from the Deploying applications using the GlassFish Admin Console section of this User Guide.
The mod_jk directives in this example will serve all applications provided by eApps but forward request to /mywebapp to GlassFish.
Add the following mod_jk directives to the Apache config for the website using either the Control Panel or the command line.
Using a Control Panel
How to add mod_jk directives to the ISPmanager Control Panel will depend on which version of ISPmanager you are using. Information on how to tell which version of ISPmanager you are using can be found here - ISPmanager versions
ISPmanager 4 - go to Domains > WWW Domains and select the domain where you want to add the mod_jk directives. Click on Config, and then add your mod_jk directives near the end of the file, just above the closing </VirtualHost> tag. More information about managing WWW Domains in ISPmanager 4 can be found here - Managing WWW Domains
ISPmanager 5 - go to Domains > Web-domains and select the domain where you want to add the no_jk directives. Click on Config, and then add your mod_jk directives near the end of the file, just above the closing </VirtualHost> tag. More information about managing Web-domains in ISPmanager 5 can be found here - Managing Web-domains
| JkMount /mywebapp* ajp13 |
Once you have added your mod_jk settings, click OK. This will reload Apache so that the new settings are read.
Using the command line
If you are comfortable working with the Apache httpd.conf file directly, you can add your mod_jk directives directly at the end of the Virtual Host block for the web site, and then restart Apache.
Deployment with GlassFish serving JSP and Servlets at eapps-example.com, Apache serving all other content
In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://eapps-example.com/ or http://www.eapps-example.com/ with Apache serving other applications provided by eApps.
Deploy your applications using the steps from the Deploying applications using the GlassFish Admin Console section of this User Guide.
The mod_jk directives in this example will serve all applications provided by eApps but forward all other requests to GlassFish.
Add the following mod_jk directives to the Apache config for the website using either the Control Panel or the command line.
Using a Control Panel
How to add mod_jk directives to the ISPmanager Control Panel will depend on which version of ISPmanager you are using. Information on how to tell which version of ISPmanager you are using can be found here - ISPmanager versions
ISPmanager 4 - go to Domains > WWW Domains and select the domain where you want to add the mod_jk directives. Click on Config, and then add your mod_jk directives near the end of the file, just above the closing </VirtualHost> tag. More information about managing WWW Domains in ISPmanager 4 can be found here - Managing WWW Domains
ISPmanager 5 - go to Domains > Web-domains and select the domain where you want to add the no_jk directives. Click on Config, and then add your mod_jk directives near the end of the file, just above the closing </VirtualHost> tag. More information about managing Web-domains in ISPmanager 5 can be found here - Managing Web-domains
| JkMount /* ajp13 # Directives to enable Apache to continue serving applications dependent on it. SetEnvIf Request_URI "/webmail" no-jk SetEnvIf Request_URI "/awstats" no-jk SetEnvIf Request_URI "/myadmin" no-jk SetEnvIf Request_URI "/pgadmin" no-jk SetEnvIf Request_URI "/cgi-bin" no-jk SetEnvIf Request_URI "/joomla" no-jk SetEnvIf Request_URI "/wordpress" no-jk SetEnvIf Request_URI "/drupal" no-jk SetEnvIf Request_URI "/mailman*" no-jk |
Once you have added your mod_jk settings, click OK. This will reload Apache so that the new settings are read.
Make a note of these three "no-jk" directives:
SetEnvIf Request_URI "/manager/ispmgr*" no-jk
SetEnvIf Request_URI "/manimg*" no-jk
SetEnvIf Request_URI "/mancgi*" no-jk
These are the directives that allow the ISPmanager 4 Control Panel to still be available, even if everything else is being forwarded to GlassFish. These must be included if you still want to use ISPmanager 4.
Using the command line
You can also add these lines to the correct VirtualHost block in the httpd.conf file using the File Manager, or from the command line.
mod_proxy_ajp is an extension of the mod_proxy module that is available in Apache 2.2. The required modules are installed automatically, because mod_proxy_ajp is part of the Apache 2.2 web server.
As with mod_jk, you use mod_proxy_ajp to allow GlassFish to run on port 8080, and have Apache pass requests to GlassFish from port 80. This allows each service to run securely on their native ports. This will let you remove the default port 8080 from the URL for your application.
Deployment with GlassFish serving JSP and Servlets at eapps-example.com/mywebapp, Apache serving all other content
In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://eapps-example.com/mywebapp or http://www.eapps-example.com/mywebapp with Apache serving other applications provided by eApps.
Deploy your applications using the steps from the Deploying applications using the GlassFish Admin Console section of this User Guide.
The mod_proxy_ajp directives in this example will serve all applications provided by eApps but forward all requests for /mywebapp to GlassFish.
Add the following mod_proxy_ajp directives to the Apache config for the website using either the Control Panel or the command line.
Using a Control Panel
How to add mod_jk directives to the ISPmanager Control Panel will depend on which version of ISPmanager you are using. Information on how to tell which version of ISPmanager you are using can be found here - ISPmanager versions
ISPmanager 4 - go to Domains > WWW Domains and select the domain where you want to add the mod_proxy_ajp directives. Click on Config, and then add your mod_jk directives near the end of the file, just above the closing </VirtualHost> tag. More information about managing WWW Domains in ISPmanager 4 can be found here - Managing WWW Domains
ISPmanager 5 - go to Domains > Web-domains and select the domain where you want to add the mod_proxy_ajp directives. Click on Config, and then add your mod_jk directives near the end of the file, just above the closing </VirtualHost> tag. More information about managing Web-domains in ISPmanager 5 can be found here - Managing Web-domains
| ProxyPass /mywebapp ajp://localhost:8009/mywebapp |
Once you have added your mod_proxy_ajp settings, click OK. This will reload Apache so that the new settings are read.
Using the command line
If you are comfortable working with the Apache httpd.conf file directly, you can add your mod_proxy_ajp directives directly at the end of the Virtual Host block for the web site, and then restart Apache.
Deployment with GlassFish serving JSP and Servlets at eapps-example.com, Apache serving all other content
In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://eapps-example.com/ or http://www.eapps-example.com/ with Apache serving other applications provided by eApps.
Deploy your applications using the steps from the Deploying applications using the GlassFish Admin Console section of this User Guide.
The mod_proxy_ajp directives in this example will serve all applications provided by eApps but forward all requests for / to GlassFish.
Add the following mod_proxy_ajp directives to the Apache config for the website using either the Control Panel or the command line.
Using a Control Panel
How to add mod_jk directives to the ISPmanager Control Panel will depend on which version of ISPmanager you are using. Information on how to tell which version of ISPmanager you are using can be found here - ISPmanager versions
ISPmanager 4 - go to Domains > WWW Domains and select the domain where you want to add the mod_proxy_ajp directives. Click on Config, and then add your mod_jk directives near the end of the file, just above the closing </VirtualHost> tag. More information about managing WWW Domains in ISPmanager 4 can be found here - Managing WWW Domains
ISPmanager 5 - go to Domains > Web-domains and select the domain where you want to add the mod_proxy_ajp directives. Click on Config, and then add your mod_jk directives near the end of the file, just above the closing </VirtualHost> tag. More information about managing Web-domains in ISPmanager 5 can be found here - Managing Web-domains
| # Directives for your application ProxyPass / ajp://localhost:8009/ ProxyPassReverse / ajp://localhost:8009/ # Directives for eApps applications dependent on Apache ProxyPass /manager/ispmgr ! ProxyPass /manimg ! ProxyPass /mancgi ! ProxyPass /webmail ! ProxyPass /joomla ! ProxyPass /awstats ! ProxyPass /myadmin ! ProxyPass /cgi-bin ! ProxyPass /pgadmin ! |
Once you have added your mod_proxy_ajp settings, click Ok. This will reload Apache so that the new settings are read.
Make a note of these three "ProxyPass" directives:
ProxyPass /manager/ispmgr !
ProxyPass /manimg !
ProxPass /mancgi !
These are the directives that allow the ISPmanager 4 Control Panel to still be available, even if everything else is being forwarded to GlassFish. These must be included if you still want to use ISPmanager 4.
Using the command line
You can also add these lines to the correct VirtualHost block in the httpd.conf file using the File Manager, or from the command line.
GlassFish includes its own web server, so Apache is not technically needed. It is possible to run GlassFish without Apache. To do this, you will need to stop the Apache web server and disable it from starting again at boot time.
|
The only time this approach is useful is when you are running a commercial or open-source application and the developers of that application have specifically recommended this approach. In other words, the application was purpose built from the ground up to run using GlassFish in standalone mode, without Apache. |
If you use this approach, you will need to run the GlassFish server and application on a Virtual Server that does nothing other than run the application. This is because when you use standalone mode, any other application that relies on Apache or PHP, such as SquirrelMail, AWStats, phpMyAdmin, phpPgAdmin, etc, will not be available since Apache will be disabled.
This approach is for users who are very familiar with GlassFish and Linux server configuration. Most users will see no benefit by using this approach.
GlassFish cannot run on port 80 because root privileges are required. Since GlassFish does not have the ability to start as root, bind to port 80, then switch back to a user without administrative privileges it would have to run as root. This creates a security issue for your system.
For the GlassFish standalone approach you will need to use the xinetd service to keep GlassFish running on port 8080 and have requests to port 80 redirected to GlassFish. This requires you to stop and disable Apache.
|
All of the following must be done from the command line of the Virtual Server as the root user. Please see the SSH User Guide - http://support.eapps.com/ispmgr/ssh for more information if necessary. You will also need to be able to edit files using a text editor, and navigate the Linux filesystem. |
Stop and Disable Apache
You will need to stop and disable the httpd service, and prevent it from starting at system boot.
For CentOS 6, use the service httpd stop command to stop the service, and the chkconfig httpd off command to prevent it from starting at system boot:
[root@eapps-example ~]# service httpd stop
[root@eapps-example ~]# chkconfig httpd off
For CentOS 7, use the systemctl stop httpd command to stop the service, and the systemctl disable httpd command to prevent it from starting at system boot:
[root@eapps-example ~]# systemctl stop httpd
[root@eapps-example ~]# systemctl disable httpd
Now the Apache web server is stopped, and can only be started again manually.
Add the port 80 redirect
To redirect requests on port 80 to GlassFish on port 8080, you will need to add a file called glassfish to the /etc/xinetd.d directory that will handle the redirect. Note that the file name is in lowercase letters.
Using a text editor, create the file called glassfish with these lines:
| # Redirects any requests on port 80 # to port 8080 (where GlassFish is listening) service http { socket_type = stream user = root wait = no redirect = localhost 8080 disable = no } |
Save and exit the file, and restart the xinetd service for the changes to take effect.
For CentOS 6, use the service xinetd restart command:
[root@eapps-example ~]# service xinetd restart
For CentOS 7, use the systemctl restart xinetd command:
[root@eapps-example ~]# systemctl restart xinetd
Now requests on port 80 will be redirected to port 8080, and served by GlassFish.
In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://eapps-example.com/ or http://www.eapps-example.com/
Deploy your application using the steps from the Deploying applications using the GlassFish Admin Console section of this User Guide.
However, you will need to make one change to the standard deployment example for the Context Root so that the application will show at the correct URL - instead of the name of the application (which is set there by default), you will need to enter a forward slash " / " for the Context Root.
Since Apache will not be running, none of the apps normally served by Apache, such as AWStats or SquirrelMail, will be available. This means that there is no need for any kind of mod_jk or mod_proxy_ajp type settings to pass requests to those applications. All you will need to do is to deploy your application in the GlassFish Admin Console.
With GlassFish, you can have multiple sites, each serving a different application, all from the same GlassFish installation. To do this, you will need to create additional Virtual Servers in GlassFish, and deploy your additional application on the new Virtual Server.
You will also need domain names for any additional sites you wish to serve. For the standard deployment methods using Apache and mod-jk or mod-proxy-ajp, you will need to create web sites for each domain. If you are going to use the less common Standalone deployment method, you will need to make sure that each domain points to the IP address of the Virtual Server in your DNS.
In this example, the first application is a hello.war file that is deployed to eapps-example.com:8080/hello, and the second application is a sample.war file that is deployed to eapps-example.com.vm-host.net:8080/sample. Each application is only available on their respective hosts - meaning that if you were to try and go to eapps-example.com:8080/sample, you would get a 404 error from GlassFish.
Deploy your first application, using the steps from the Deploying applications using the GlassFish Admin Console section of this User Guide. Whether you use mod-jk or mod-proxy-ajp or leave the default port of 8080 in place is up to you.
Create a new Virtual Server in the GlassFish Admin Console
Deploy the second application, and select the new Virtual Server during the deployment process.
Step one has been covered in detail in the Deploying applications using the GlassFish Admin Console section of this User Guide. Please review if necessary.
For step two - Create a new Virtual Server, you will need to log in to the GlassFish Admin Console. Once you are logged in, go to Configurations, expand server-config, and then click on Virtual Servers.
This brings up the Virtual Servers screen, which lists the existing Virtual Servers. By default, there are two: __asadmin and server.
To add a new Virtual Server, click on New.
Id - this is the name of the new virtual server
Hosts - replace this text with the name of the web site
State - leave at the default value
SSO - leave at the default value
SSO Cookie Http Only - leave at the default value
Network Listeners - select both http-listener-1 and http-listener-2
Default Web Module - leave at the default
Log File - leave at the default value
Docroot - leave at the default value
Access Logging - leave at the default value
Directory - leave at the default value
You can also add Additional Properties if you wish.
Information about all of these options is available from the Help button at the top right of the screen.
Once you have entered your information, click OK. This creates the new Virtual Server.
As an example, here are the values for a new Virtual Server called server1, serving the domains of eapps-example.com.vm-host.net and www.eapps-example.com.vm-host.net, using both http-listener-1 and http-listener-2.
Now the Virtual Servers screen shows the new server1 in the list of Virtual Servers.
In the GlassFish Admin Console screen, click on Common Tasks in the left navigation pane to make sure you are on the correct screen. Then click on Deploy an Application in the Deployment section of the main screen.
This takes you to the Deploy Applications or Modules screen.
Location
Packaged File to Be Uploaded to the Server - click on Choose File to browse the file system on your local computer for the file to upload and deploy.
Local Packaged File or Directory That is Accessible from GlassFish Server - this allows you to browse the file system on the Virtual Server for the file to deploy.
Type - using the drop down menu, choose from one of the following:
Once you choose the packaged file to upload or deploy, the Deploy Applications or Modules screen expands. The options available will change depending on the Type chosen. This example uses the sample.war file, so Web Application is the default choice. Depending on the type of file you are uploading, you may have different options.
Rather than going over the settings in this screen, which have been covered previously, you simply need to note the one difference: in the Virtual Servers section, the new Virtual Server of server1 has been chosen.
Once you have chosen the correct file to deploy, and chosen the correct Virtual Server to deploy it on, click OK.
Now your second application will be available at the additional domain you have added. In this case, the application would be available at eapps-example.com.vm-host.net:8080/sample or www.eapps-example.com.vm-host.net:8080/sample. Remember that you can use mod_jk or mod_proxy_ajp to remove the 8080 from the URL.
The asadmin utility is the command line tool for making changes and adding configurations to GlassFish. This section will introduce some basic tasks that can be accomplished with asadmin. For more information on how to use asadmin, go to the GlassFish Server Documentation page, and download the All-in-one Documentation Zip Bundle. Information on using the asadmin utility is found in the adminstration-guide.pdf.
|
Since the GlassFish server is running as the gfish user, you will need to run the asadmin commands as the gfish user. If you run the commands as the root user, the GlassFish server will not be able to read and write to any files changed or created. |
The asadmin tool is mainly used by experienced Linux and GlassFish admins - you should be very familiar with working from the command line and navigating the Linux filesystem if you wish to use asadmin.
To create a new administrative domain, use the following command: asadmin create-domain --user admin1 --portbase 9000 --savelogin=true domain2 (note that the command is all on one line).
This creates a new domain called domain2, using the default admin1 user.
| [root@eapps-example ~]# su - gfish -bash-4.1$ asadmin create-domain --user admin1 --portbase 9000 --savelogin=true domain2 Enter the admin password [Enter to accept default of no password]> Using port 9048 for Admin. Using port 9080 for HTTP Instance. Using port 9076 for JMS. Using port 9037 for IIOP. Using port 9081 for HTTP_SSL. Using port 9038 for IIOP_SSL. Using port 9039 for IIOP_MUTUALAUTH. Using port 9086 for JMX_ADMIN. Using port 9066 for OSGI_SHELL. Using port 9009 for JAVA_DEBUGGER. Distinguished Name of the self-signed X.509 Server Certificate is: [CN=example.eapps-example.com,OU=GlassFish,O=Oracle Corporation,L=Santa Clara,ST=California,C=US] Distinguished Name of the self-signed X.509 Server Certificate is: [CN=example.eapps-example.com-instance,OU=GlassFish,O=Oracle Corporation,L=Santa Clara,ST=California,C=US] No domain initializers found, bypassing customization step Domain domain2 created. Domain domain2 admin port is 9048. Domain domain2 allows admin login as user "admin1" with no password. Login information relevant to admin user name [admin1] for this domain [domain2] stored at [/opt/glassfish4/glassfish/.asadminpass] successfully. Make sure that this file remains protected. Information stored in this file will be used by asadmin commands to manage this domain. Command create-domain executed successfully. -bash-4.1$ |
To start the new domain, use the asadmin start-domain domain2 command. This starts the new domain2.
| -bash-4.1$ asadmin start-domain domain2 Waiting for domain2 to start ..... Successfully started the domain : domain2 domain Location: /opt/glassfish4/glassfish/domains/domain2 Log File: /opt/glassfish4/glassfish/domains/domain2/logs/server.log Admin Port: 9048 Command start-domain executed successfully. -bash-4.1$ |
If you need to stop the domain, use the asadmin stop-domain domain2 command.
| -bash-4.1$ asadmin stop-domain domain2 Waiting for the domain to stop .... Command stop-domain executed successfully. -bash-4.1$ |
This creates a new Virtual Server called server2 on domain2 (port 9048), using the admin1 user, for the hosts eapps-example.com and www.eapps-example.com, using the default Network Listeners (httplisteners) of http-listener-1 and http-listener-2. Note that the command is all on one line.
asadmin --port 9048 --user admin1 create-virtual-server --hosts eapps-example.com,www.eapps-example.com --httplisteners http-listener-1,http-listener-2 server2
| [root@example ~]# su - gfish -bash-4.1$ -bash-4.1$ asadmin --port 9048 --user admin1 create-virtual-server --hosts eapps-example.com,www.eapps-example.com --httplisteners http-listener-1,http-listener-2 server2 Command create-virtual-server executed successfully. -bash-4.1$ |
To deploy an application to the new Virtual Server, in this example a file called hello.war use the asadmin deploy --port 9048 --virtualservers server2 /tmp/hello.war command. Note that the command is all on one line. The WAR file can be located anywhere on the system that the gfish user can read from.
| -bash-4.1$ asadmin deploy --port 9048 --virtualservers server2 /tmp/hello.war Application deployed with name hello. Command deploy executed successfully. -bash-4.1$ |
If you wish to go further with asadmin, please see the official documentation.
GlassFish 4 includes the pkg utility, which allows you to upgrade specific modules, packages, and libraries in GlassFish, without having to upgrade your entire GlassFish installation.
The pkg utility is a command line utility, and is not installed by default. You will need to install it before you can use it.
To do this, log in to your Virtual Server using SSH, and switch users to the gfish user. You will then need to change directories to the location of the pkg utility - /opt/glassfish4/bin/, and change the permissions on the utility so that it is executable.
| [root@eapps-example ~]# su - gfish -bash-4.1$ cd /opt/glassfish4/bin -bash-4.1$ chmod +x pkg -bash-4.1$ ll pkg -rwxr-xr-x 1 gfish gfish 7776 Jul 20 01:42 pkg -bash-4.1$ |
Now, run the pkg utility with the ./pkg command (dot slash pkg). This will install the utility.
| -bash-4.1$ ./pkg The software needed for this command (pkg) is not installed. When this tool interacts with package repositories, some system information such as your system's IP address and operating system type and version is sent to the repository server. For more information please see: http://wikis.sun.com/display/updatecenter/UsageMetricsUC2 Once installation is complete you may re-run this command. Would you like to install this software now (y/n): y Proxy: Using system proxy settings. Install image: /opt/glassfish4 Installing pkg packages. Downloading 2 packages. Downloading pkg (511 files, 6,237,782 bytes). File 511/511 Downloading python2.4-minimal (303 files, 6,531,277 bytes). File 303/303 Executing 933 install actions. Initialization complete. Software successfully installed. You may now re-run this command (pkg). -bash-4.1$ |
To use the pkg utility, you will need to reference the available help from the command line, with the ./pkg --help command. This lists the available options for the pkg utility.
| -bash-4.1$ ./pkg --help Usage: pkg [options] command [cmd_options][operands] Basic subcommands: pkg install [-nvq][--no-refresh] [--no-index] package... pkg uninstall [-nrvq][--no-index] package... pkg list [-Hafsuv][--no-refresh] [package...] pkg image-update [-fnvq][--be-name name] [--no-refresh][--no-index] pkg refresh [--full][publisher ...] pkg version Advanced subcommands: pkg info [-lr][--license] [pkg_fmri_pattern ...] pkg search [-alprI][-s server] query pkg verify [-Hqv][pkg_fmri_pattern ...] pkg fix [pkg_fmri_pattern ...] pkg contents [-Hmr][-o attribute ...] [-s sort_key] [-t action_type ... ][pkg_fmri_pattern ...] pkg image-create [-fFPUz][--force] [--full|--partial|--user][--zone] [-k ssl_key][-c ssl_cert] [--no-refresh] [--variant <variant_spec>=<instance>] (-p|--publisher) name=uri dir pkg change-variant [-nvq][--be-name name] <variant_spec>=<instance> [<variant_spec>=<instance> ...] pkg set-property propname propvalue pkg unset-property propname ... pkg property [-H][propname ...] pkg set-publisher [-Ped][-k ssl_key] [-c ssl_cert] [-O origin_uri][-m mirror_to_add | --add-mirror=mirror_to_add] [-M mirror_to_remove | --remove-mirror=mirror_to_remove] [--enable][--disable] [--no-refresh][--reset-uuid] publisher pkg unset-publisher publisher ... pkg publisher [-HPa][publisher ...] pkg history [-Hl] pkg purge-history pkg rebuild-index Options: -R dir --help or -? Environment: PKG_IMAGE -bash-3.2$ |
More information on the pkg utility can be found here:
Listing and adding components - http://download.oracle.com/docs/cd/E19226-01/820-7692/ghjhp/index.html
Updating installed components and entire GlassFish - http://download.oracle.com/docs/cd/E19226-01/820-7692/ghjlp/index.html
Removing components - http://download.oracle.com/docs/cd/E19226-01/820-7692/ghmws/index.html
One of the most important parts of tuning GlassFish for better performance is to optimize the Java Heap settings. The Java Heap size is the amount of memory allocated to the Java Virtual Machine (JVM). The heap is where Java objects live, and there must be enough memory allocated to the JVM to support the needs of the deployed GlassFish applications.
|
The most common issue with GlassFish, by far, is a lack of available resources. In many cases, this is due to the Java Heap size either not being configured at all, or not being configured correctly. |
If you run out of heap space, you might see the message java.lang.OutOfMemoryError in your /opt/glassfish4/glassfish/domains/domain1/logs/server.log file.
How to find the correct Java heap settings
To find the correct heap size, you will have to stop GlassFish, and use the Linux free -m command to see the available memory, and then multiply that value by two, and then subtract that result from the total RAM available for your plan. This number will be roughly what you need to set for the maximum heap size.
Note that the following must be done from the command line of the Virtual Server while logged in via SSH, as the root user.
[root@eapps-example ~]# free -m
total used free shared buffers cached
Mem: 1536 988 548 0 26 205
-/+ buffers/cache: 589 946
Swap: 1023 0 1023
In this example, there is 548 MB of free memory. Multiply that by two for 1096, and subtract that from the total available RAM for the Virtual Server, which in this example is 1536 MB. This puts the optimum Java heap size at 440 MB.
Remember, this is just a rough estimate. You may find that you need to adjust this number up or down as necessary, depending on how your application is configured and what other services your server is running.
Generally, the maximum heap size should be just under half the amount of memory available to your Virtual Server. You can of course adjust this value higher or lower, but you may have to experiment to determine the true optimum heap size. There is no hard and fast rule for the heap size, because there are many factors that can determine the best value in your specific situation.
Adjusting the GlassFish Heap Settings
The default heap size for GlassFish is 256 MB. If you need to change the heap size, you will need to log in to the GlassFish Admin Console.
Expand server-config, and click on JVM Settings. Then click on the JVM Options tab at the top of the screen.
The line for the Java heap size is -Xmx256m. Change 256 to your desired heap size, and click Save. Make sure to only change the number, do not change any other values on that line.
