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 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
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.
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:
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:
and your GlassFish Administration Console is deployed at:
Adjust these values for your local environment.
As mentioned in the previous post, when using the Java Logging Service with Listener, it’s important that the
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.
Enter the following URL in your browser:
If you have configured a password, enter your credentials.
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:
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
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.
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
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.