GlassFish

Oracle Application Express Listener Standalone Mode

One of the nice features of Oracle Application Express Listener is Standalone Mode. Standalone Mode enables the Listener to run outside of an application server, starting Standalone Mode is as simple as typing the following in a command prompt:

java -jar apex.war standalone

Seconds later a functioning Listener instance is up and running. It’s a lot quicker and more convenient than the multiple steps involved in deploying Listener to an application server.

And that’s the whole reason Standalone Mode exists, ease of use, speed, and convenience, it saves developers time, compared to the overhead involved in deploying to an application server.

So it’s an extremely useful feature for development use cases, but when you start Standalone Mode, the following message is displayed:

NOTE:

Standalone mode is designed for use in development and test environments. It is not supported for use in production environments.

Naturally customers ask: ‘Why isn’t Standalone Mode supported in production environments?’. Well, even though Standalone Mode uses the fantastic Oracle Grizzly framework to provide a robust JEE environment, there are still many features it lacks compared to GlassFish or WebLogic:

• Standalone Mode does not support HTTPS

• Standalone Mode has never been stress/load tested. We don’t test to see how far Standalone Mode will scale, how many concurrent requests it can serve, how it will behave under high loads, etc.

  GlasshFish and WebLogic have huge engineering focus on performance and scalability, they are engineered to cope with high load scenarios.

  Since we leverage Grizzly (which is a component of GlassFish), we get the benefits of some of that engineering effort, but still there’s many many orders more effort put into GlassFish and WebLogic.

• Standalone mode is not tunable.

  Want to change the number of HTTP listen threads? You can’t do that. Want to change the keep-alive timeout? You can’t do that. Want to change the size of the request queue? You can’t do that. Limit the maximum URL length? Nope.

  You get the picture, important common tweaks that you can do on WebLogic and GlassFish, are not possible in Standalone Mode

• You can’t monitor Standalone Mode. No JMX endpoints, no Enterprise Manager integration, no statistics, nothing.
• You can’t even change the logging level on the fly
• You can’t integrate with any of the Oracle Fusion Middleware stack

To conclude, we strongly encourage you to use Standalone Mode in development environments, it will save you time and effort, but hopefully now you can appreciate that when it comes time to deploy to production, you need to deploy Listener on WebLogic or GlassFish.

Configuring Logging with Oracle Application Express Listener and GlassFish

In the previous post, we showed how Listener can use the Java Logging Service to configure where diagnostic information is logged and how it is filtered. We also showed how you can configure the logging service in Standalone Mode using the -Djava.util.logging.config.file JVM option. Configuring logging via the JVM option works perfectly well for Standalone Mode, because in that case Listener is the only application running in the JVM. Conversely using the JVM option does not work so well when using a proper application server like GlassFish or WebLogic, for a couple of reasons:

• The JVM option only allows the logging configuration to be specified at JVM startup, there’s no way to change the log configuration on the fly
• There will often be many applications deployed on the application server at the one time, changing the configuration can end up affecting every application on the server, not just the Listener

Fortunately application servers enhance the Java Logging service and provide facilities to change the Listener logging configuration on the fly. In this post we’ll be looking at the logging configuration facilities that GlassFish provides and how they can be leveraged to control Listener logging.

For the examples below we are going to assume your Listener is instance is deployed at:

http://localhost:8080/apex/

and your GlassFish Administration Console is deployed at:

http://localhost:4848

Adjust these values for your local environment.

Disable debug.debug

As mentioned in the previous post, when using the Java Logging Service with Listener, it’s important that the defaults.xml debug.debugger configuration setting is disabled, as when it is enabled it overrides the Java Logging Service and log messages are printed directly to the console. Refer to the previous post for instructions on how to do this.

Access the GlassFish Administration Console

Enter the following URL in your browser:

http://localhost:4848

If you have configured a password, enter your credentials.

Navigate to the Logging Configuration Pages

In the navigation tree on the left of the page, expand the Configurations node, then expand the server-config node. Now click the Logger settings node. On the General tab you can configure the basic logging parameters, we’re not going to change anything here, consult your GlassFish documentation if you want to learn more.

Next click on the Log Levels tab. Click the Add Logger button. Enter oracle.dbtools as the Logger Name and then set the log level you want, for example to show all messages choose ALL and then press the save button.

Now to try out your changes, open another browser window and enter the following URL:

http://localhost:8080/apex/

Keep an eye on the GlassFish console, you should see lots of information being printed as the APEX login page appears. Now switch back to the GlassFish Administration console and switch the log level for oracle.dbtools to OFF. Next try accessing the URL above again, this time nothing should be printed to the console, thus demonstrating how you reconfigure Listener logging on the fly without needing an application restart, just one of the benefits of deploying Listener in an application server, versus running in standalone mode.

Configuring Application Express Static Resources with Listener 2.0

A problem sometimes encountered when using Oracle Application Express Listener, is getting a blank page displayed when attempting to access an Oracle Application Express (APEX) page. For example getting a blank page when trying to display http://server:port/apex/. The cause of this problem is not having the APEX static resources configured properly. This leads to the JavaScript and CSS resources required by APEX not being found, and the APEX page failing to render correctly.

Possible Causes

Any of the following can cause this issue to occur:

1. Forgetting to deploy i.war on WebLogic/GlassFish
2. Specifying an incorrect path when using the java -jar apex.war static command to generate i.war
3. Configuring APEX to use a non default context path for static resources (/i) and not specifying the same context path (via the --context-path option) when using java -jar apex.war static.
4. Moving, renaming or deleting the folder pointed to by i.war after deploying i.war
5. When running in Standalone Mode, entering an incorrect path (or skipping specifying a path) when prompted, on the first run of Standalone Mode
6. When running in Standalone Mode, entering an incorrect path via the --static-images option
7. And last, the one I most often forget myself, upgrading to a new version of APEX and forgetting to reconfigure and redeploy i.war to point to the static resources for the new APEX version, or in Standalone Mode forgetting to update the location by using the --apex-images option.

Confirming the problem

Assume your APEX deployment is located at http://example.com/apex/ and your static resources have been deployed at http://example.com/i/, then try accessing the following url:

http://example.com/i/apex_version.txt

If you get a 404 Not Found error then you need to double check points 1-6 in the list above, i.war is not deployed or is not pointing at a folder containing APEX static resources.

Otherwise a plain text file will be displayed with contents like the following:

Application Express Version:  4.2.1

Pay close attention to the version number displayed, it must match the version of APEX deployed on the database. If they differ then check point 7 on the list above, the Listener is not configured to use the correct version of APEX static resources to match the APEX version in the database.

Curing the problem

Consult the Oracle Application Express Listener for detailed documentation on how to create and deploy i.war. See instructions for WebLogic here, and GlassFish here.

You can get detailed help on the static listener command by typing the following at a command prompt:

java -jar apex.war help static

Listener 2.0 picks up changes to APEX static resources immediately

For Listener 1.1.x the deployment process for i.war required zipping all the APEX static resources into i.war and then deploying the resultant i.war.

The problem with this approach is that if the contents of the APEX static resources are updated (for example to add some custom style sheets), then i.war needs to be recreated and redeployed.

In 2.0 we leverage capabilities in WebLogic and GlassFish (described in more detail in a previous post) to create an i.war which does not actually contain the static resources, but instead points to the folder containing the static resources.

The advantage of this approach is that the static resources can be updated and the updates are immediately picked up by the server without requiring any restarting or redeploying of i.war

Serving Static Content on WebLogic and GlassFish

Both Oracle WebLogic and Oracle GlassFish provide mechanisms to mix-in static content located outside a Web Application Archive (WAR). We can leverage these facilities to create a simple WAR that can be used on either WebLogic or GlassFish for serving static content.

This provides an easier to use approach for serving Oracle Application Express static resources when using Oracle Application Express Listener, compared to zipping all the Application Express resources into a large WAR. An added benefit of this approach is that changes within the static resources folder are picked up immediately, no need to restart or update the WAR.

Let’s get started, we’re going to create a small WAR that contains the necessary deployment descriptors. First create a folder to work in.

mkdir static
cd static
mkdir WEB-INF
cd WEB-INF

Now create the JEE WAR descriptor, named: web.xml with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">
<web-app/>

Next create the WebLogic specific deployment descriptor, named: weblogic.xml with the following contents:

<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
 <!-- This element specifies the context path the static resources are served from -->
 <context-root>/i</context-root>
 <virtual-directory-mapping>
  <!-- This element specifies the location on disk where the static resources are located -->
  <local-path>/path/to/apex/images</local-path>
  <url-pattern>/*</url-pattern>
 </virtual-directory-mapping>
</weblogic-web-app>

Note the values of the context-root and local-path elements, adjust these values to match your requirements.

Next create the GlassFish specific deployment descriptor, named: sun-web.xml with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD GlassFish Application Server 3.0 Servlet 3.0//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_3_0-0.dtd">
<sun-web-app>
 <!-- This element specifies the context path the static resources are served from --> 
 <context-root>/i</context-root>
 <!-- This element specifies the location on disk where the static resources are located -->
 <property name="alternatedocroot_1" value="from=/* dir=/path/to/apex/images"/>
</sun-web-app>

Note the values of the context-root element and the dir field within the value attribute of the property element, adjust these values to match your requirements.

Next create the WAR from these files:

cd ..
jar cvf ../static.war .

Finally deploy the static.war file to your WebLogic or GlassFish server.

One point to note is when using the Administration UI in GlassFish to deploy the WAR, the context root field is auto-filled by the UI based on the name of the WAR. Clear the contents of this field to ensure the context-root value specified in the sun-web.xml is used.