GlassFish can be installed in various ways, including via installers for the standard operating systems. The entire download
is also available as a ZIP file. However GlassFish is installed, the installation process includes prompts for an administrator username (the default is admin)
and a password. GlassFish has a web console (localhost:4848 by default) and a command-line utility named asadmin (in Windows,
asadmin.bat) that can be used to administer the JAS. The web console (see Figure 7-2) can be used only if GlassFish
is already running.
During installation, it is possible to have GlassFish made into a system service so that GlassFish starts automatically whenever the system reboots. At startup, GlassFish checks for available ports on which to listen for connections. For example, if Tomcat or some other application is running and listening already on port 8080 for client connections, GlassFish notes this and asks for an alternative port to receive HTTP connections. (On my system, Tomcat listens on port 8080 for HTTP connections and GlassFish listens on port 8081.) By default, GlassFish listens for HTTPS connections on port 8181. GlassFish allows administrative overrides of all defaults.
The GlassFish web console is well organized and informative. GlassFish groups together, under the tab Applications, websites, web services, EJBs, and other deployed artifacts. This tab gives pertinent information about each deployed item and supports operations such as undeploy. The web console is particularly helpful because it lists, in the case of SOAP-based web services, the URLs for the WSDL; in the case of EJB-based services, GlassFish also provides a web-based test client. The use of plural URLs also deserves clarification: by default, GlassFish publishes a site or a service under HTTP and HTTPS. GlassFish comes with a keystore, although the self-signed certificates therein would need to be upgraded for production-level use.
The GlassFish Applications tab makes it easy to check whether a service has deployed. This tab also can be used to upload WAR files and deploy them. For that reason, my sample deployments under GlassFish use the web console rather than the Ant script familiar from earlier examples of Tomcat deployment.
In the web console, there is also a Resources tab in the same left panel as the Applications tab. The Resources tab
lists database connections, JMS message topics
and queues, email sessions, and other resources that GlassFish applications are likely to use. In this chapter, the section
on EJB-based services illustrates a database connection with two @Entity examples, one involving GlassFish and the other
involving TomEE.
If AS_HOME points to the GlassFish install directory, the AS_HOME/bin subdirectory has the asadmin utility that runs as a command-line application. This utility can be used, as can the web console, to administer GlassFish. At the asadmin prompt, the command:
asadmin>list-commands
gives a sorted list of the local and remote commands available. Some of these commands require administrator privilege. For example, the stop-instance command, which stops an executing instance of the GlassFish JAS, requires administrator status; hence, the asadmin utility would prompt for the administrator name and password given during the GlassFish installation.
GlassFish lets the administrator organize deployed applications into domains. At start-up, for example, it is common to have GlassFish create a domain named domain1; the domain names are arbitrary but, of course, each must be unique. A domain can be stopped:
%asadminstop-domaindomain1
and started again:
%asadminstart-domaindomain1
A domain also can be restarted with the restart-domain command.
GlassFish domains are implemented as subdirectories of the domains directory, and each domain, in turn, has an autodeploy subdirectory. Deploying an application is straightforward. Consider the predictions.war file RESTful service from Chapter 1, which is created using the Ant script. This file, with no changes, can be deployed to the GlassFish domain1 by copying the WAR file to:
AS_HOME/glassfish/domains/domain1/autodeploy
The copying can be done at the command line or through the GlassFish web console. To confirm a successful deployment, GlassFish creates an empty marker file:
AS_HOME/glassfish/domains/domain1/autodeploy/predictions.war_deployed
If the deployment fails, GlassFish indicates so with a marker file:
AS_HOME/glassfish/domains/domain1/autodeploy/predictions.war_deployedFailed
If the predictions service is undeployed by removing the file predictions.war from the autodeploy subdirectory, GlassFish likewise confirms with another marker file:
AS_HOME/glassfish/domains/domain1/autodeploy/predictions.war_undeployed
As noted earlier, the GlassFish web console is an easy way to deploy applications, including web services, to a specified domain. The deployed file (for instance, a WAR file or a web service) can be uploaded from a remote machine to the GlassFish server.
The Derby database system, which ships with GlassFish3, is not started automatically when a domain is activated. The database system can be started with the command:
%asadminstart-database
An EJB example in this chapter accesses Derby with JPA.