Application Servers

Flux does not require an application server to run, but if you have one, Flux can easily integrate with it. These sections contain information on configuring Flux to run with the supported application servers.

Flux Application Server Compatibility

Three configuration settings that directly involve Flux’s interaction with an application server are tested for compatibility across application server versions in order to deem Flux as being supported with a certain application server.

  • Data sources can be configured in application servers to leverage connection pooling and transactions configuration. Flux supports this using a Flux engine’s configuration property DATA_SOURCE, which usually is a JNDI binding to a JDBC resource. Data sources can be configured to support JTA, which requires JTA-enabled JDBC drivers. If JTA is enabled on the data source, Flux can participate in the global transaction by default. If you need Flux to manage database transactions, Flux should be configured by setting DATA_SOURCE_USER_TRANSACTIONS to true.
  • Flux uses its internal thread pooling mechanism for different purposes. In a managed environment as with application servers, threads are a scarce resource and should be efficiently dealt with. This support is usually provided by Work Manager API (JCA or CommonJ) in application servers.
  • Flux can be configured to use a WorkManager configuration by setting the WORK_MANAGER_RESOURCE_NAME property on the engine.

Flux downloads releases of applications server software from the vendors’ websites. Flux then configures the application server — using its default configuration. A Flux servlet is deployed, embedded in a war file as documented in the Servlet software developers example. The application server is started and the proper functioning of the deployed servlet is reviewed and assured.

A sample Flux configuration for a test is shown below.

Configuration config = new Configuration();
config.setServer(true);
config.setDatabaseType(DatabaseType.ORACLE);
config.setDataSource("jdbc/flux");
config.setWorkManagerResourceName("wm/flux");
config.setOracleLargeObjectAdapter("flux.WebSphereOracleAdapter");
config.setDataSourceCaching(true);

Running the Engine

The following techniques work across all application servers, in both clustered and non-clustered environments. Refer to the subsequent sections on WebLogic, WebSphere, JBoss, and Tomcat for more information on running in those specific servers.

  • Servlet. You can configure the Flux engine to start automatically in a servlet. For more information on this technique (including sample code), see Embedding Flux as a Servlet.
  • Singleton. Flux can run as a singleton class in your application server. Note that when using this technique, you must initialize and configure the engine the first an EJB accesses it. You must also be sure that the singleton is accessed and initialized — the engine will not be usable (and workflows will not fire) if the singleton is not initialized.

It is not advisable to initialize Flux in the static initializer block of the singleton class, as application servers use many different class loaders.

Since application servers automatically load and unload EJBs, along with their associated classes and objects, you should carefully consider how this approach will work in your own architecture. While this technique has worked successfully with several Flux users, you should be aware of the issues involved before attempting this technique.

  • Separate JVM. You can instantiate Flux in a JVM separate from the application server while still allowing Flux to communicate with that server. EJBs from the application server can communicate with Flux using standard APIs.

In particular, to allow Flux to integrate with the application server from a separate JVM (for instance, to use a data source from that server), you will need to configure the PROVIDER_URL, INITIAL_CONTEXT_FACTORY, and (if the initial context requires it) INITIAL_CONTEXT_USERNAME and INITIAL_CONTEXT_PASSWORD. For example, the configuration below might be used if Flux is attempting to access a JBoss server from a different JVM:

PROVIDER_URL=jnp://localhost:1099
INITIAL_CONTEXT_FACTORY=org.jnp.interfaces.NamingContextFactory
INITIAL_CONTEXT_USERNAME=admin
INITIAL_CONTEXT_PASSWORD=admin

Running the Web App (Operations Console)

The Flux web application is included as a WAR archive with the Flux release (located in the /webapp directory). You run the Operations Console from your application server by deploying this WAR in the usual way.

The Flux Operations Console will not load properly after being deployed if there are any spaces in the application server’s classpath entries.

File Triggers and Actions Using SFTP, FTPS, SMB, or ZIP file locations

When performing file operations (whether using a simple file source/target or a file criteria), Flux’s File Triggers and Actions must internally convert file locations to URLs in order to complete certain operations. Unfortunately, Java does not support SFTP, FTPS, SMB, or ZIP URLs directly, so in order to handle files in these locations, Flux must use a special protocol handler in order to translate these URLs.

If you are running Flux standalone (from the command line, from a service, or from a Java application), Flux will automatically configure itself to use its custom protocol handlers. If you are starting Flux in a container, however, you’ll need to perform some configuration to support these URL types.

First, you’ll need to set the following Java system property somewhere in your container startup:

-Djava.protocol.handler.pkgs=fluximpl

Secondly, you’ll need to be sure that the following four classes are available on the container’s system class path:

fluximpl.sftp.Handler
fluximpl.ftps.Handler
fluximpl.smb.Handler
fluximpl.zip.Handler

You can either place flux.jar on the class path, or copy those class files to a new location (like customurlhandlers.jar) and place that location on the class path.

Once those two items are done, Flux should be able to recognize these file locations with no problem while running within your container.