|JaxcentConfigXML||Path to a config XML file, which will contain the path mappings for Jaxcent. Similar
to the servlet mappings, Jaxcent maps URLs to Java classes that it then loads, to process
If the file specified by the path is not found, and if Jaxcent is running in a servlet container, the container will be asked for a stream to the resource specified. This mechanism allows the config files to be packaged as part of J2EE apps.
|ReloadableClasses||Classpath for Jaxcent. Other mechanisms for providing the classes - such as CLASSPATH variable or
a servlet container's lib folder - continue to be available. This is simply an additional
mechanism for specifying classes. Unlike standard CLASSPATH components, classes in this classpath are reloaded by Jaxcent
whenver they change.
Note that the changes made to the classes will take effect only when the page is refreshed in the browser (until the page is refreshed, the old class and any related objects will continue to handle the page.)
Some application servers also reload classes when the classes change, but during development it is recommended that you give the Jaxcent classes to Jaxcent directly using this mechanism. (If you reload classes using the application server, the application server context may get reloaded, which will break any existing Jaxcent connections. If Jaxcent does the reloading, existing web pages will continue using the old code, but when the page gets loaded again or refreshed, the new code is used.)
The elements of the classpath are absolute, and not container specific. If packaged as part of a J2EE app, the classes should be packaged along with the app rather than being specified via this mechanism.
|DisplayServletMessage||This can be set to true or false. If set to false, when the servlet URL is typed directly in a browser, it will generate a 404 error code. The default is true.|
|RefreshULRMap||This can be set to true or false. If set to false, Jaxcent will not re-read the XML configuration file whenever it changes. The default is true.|
|KeepAliveTimeout||This can be set to a specific number of seconds after which Jaxcent will send a client-server refresh message if nothing happens in the meanwhile. The default is 145. Note that this is different from the HTTP keep-alive timeout. The Jaxcent keepalive timeout is to tell any servers (e.g. Apache) or gateways that might be in the middle of the client-server connection and might have timeouts, that the Jaxcent connection is still alive and should not be discarded.|
In addition, the following init parameters apply only to the connectors:
|JVM||Path to the Java JVM DLL or library file.|
|Classpath||The (non-reloadable) classpath for the JVM.|
|LogFile||The log file for redirecting Java standard output or standard error messages.|
|SessionInactivityTimeout||Session inactivity timeout, in seconds. Default is 600.|
|PagePath||Specifies the path to map, e.g. "/test/MyTest.html". The path can contain query strings, e.g. "/test/MyTest.html?option1". In this case, Jaxcent will only match incoming requests with that exact query string. If the query string doesn't match, Jaxcent will then remove the query string from the request, and will attempt to match without the query string.|
|PageClass||Specifies fully qualified class name for serving the specified path.|
|UseSession||This can be true or false. The default is false. If set to true, the HTTP session object from the servlet request will be available via the JaxcentPage class. If a session doesn't exist, it will be created. Note that the underlying HTML page doesn't have to be a JSP or a servlet. Even if it is a static page, a session will be added if it doesn't exist, and will be available via Jaxcent.||AutoSessionData||This can be set to true or false. The default is false.
If set to true, this tells Jaxcent to automatically populate fields of forms from
session data during page loading, and to automatically save fields of forms into
session data during page unloading.
The Jaxcent session data is stored at the key jaxcent.SessionData in the session object. It can be retrieved for direct use, but should not be modified. The retrieved data should be cast to java.util.Hashtable. The hash table contains entries for all data items found on the forms so far. The data names or ids are used as keys, and are lower-cased before storing the data in the hashtable. If multiple entries on the same page were found for a data name (e.g. if there are multiple checkboxes with the same name), the values will be comma separated. If checkboxes were not selected, an empty string will be stored for them. For dropdown (SELECT) lists, the value stored is in the form
<selected-index>:<Selected-text>If AutoSessionData is set to true, UseSession is automatically set to true.