Configuration
|
| < Day Day Up > |
|
Configuration of the highly flexible JServ environment is accomplished through the combination of the httpd.conf file that we looked at in Chapter 4 — Apache, the Jserv.properties and Jserv.conf file, and the zone.properties files and the smaller files that they call.
We can look at the jserv.properties file and the jserv.conf file to see the directives within them that you will find useful to understand.
Jserv.properties
The jserv.properties file should be either appended to the end of the httpd.conf file or, preferably, called from that file and maintained on its own for modularity and ease of configuration and debugging.
LoadModule
For Apache on Windows to know that it needs to load the JServ module into the system, you need to call it in with a LoadModule command:
LoadModule jserv_module "%s_topDir%\JServ\ApacheModuleJServ.dll"
For UNIX, use a similar LoadModule command:
#LoadModule jserv_module libexec/mod_jserv.so
Again, using containers to modularize the code, even within the Jserv.properties file, the following container (IfModule) will contain all of the logic that is in play until the ending of the container code:
<IfModule mod_jserv.c>
AppsJServManual
AppsJServManual instructs Apache whether or not to start the Apache JServ. Counterintuitively, default is off, meaning that JServ is autostarted. On means that it has to be started manually.
ApJServManual off
ApJServProperties
ApJServProperties provides you with the properties filename for the Apache JServ when it is running in automatic mode. If JServ is running in manual mode, the directive is ignored. It can be entered in absolute terms for added readability or in relative terms using the environment variables.
ApJServProperties "D:\visora\iAS\Apache\Jserv\conf\jserv.properties"
ApJServLogFile
ApJServLogFile is the log file that is relative to the Apache root directory. You can use environment variables to reference the location of this file, but absolute paths are recommended for readability and maintainability. Not to be confused with the log file that is referenced elsewhere in the jserv.properties file, this log file is specific to the C portion of the Apache JServ module. If you are running this tier on a UNIX environment, the owner of the JVM process must have write permissions on the directory that this directive points to. If this directive is disabled, the defaulting error log will be appended into the Apache error log.
ApJServLogFile "D:\visora\iAS\Apache\JServ\logs\mod_jserv.log"
ApJServLogLevel
ApJServLogLevel sets the logging level for this module. If unset, it defaults to info and can take on the values (in decreasing amounts of detail placed into the log) debug, info, notice, warn, error, critical, alert, emerg. As with other log levels, remember that all of the values from the lower levels are included in the upper levels of logging. It is recommended that this be set to at least error. Leaving it at info might cause you to accumulate very large logs and have to wade through irrelevant information in search of problems.
ApJServLogLevel notice
ApJServDefaultProtocol
ApJServDefaultProtocol signifies the protocol that is used by this host to connect to the Apache JServ module. Extensive information is available in the Oracle documentation on what values this directive can take on and what meanings are attached to each of those protocols. The default is ajpv12. Unless you have a pressing need to use a different protocol, it would be better to leave this as it is until you have a better handle on what your system is doing and how it is going to be used.
ApJServDefaultProtocol ajpv12
ApJServDefaultHost
ApJServDefaultHost is the default host on which the Apache JServ is running. This defaults to localhost and should probably be left at that unless you become comfortable with changing it. It can also be safely set to the name to which your machine is referred in the URL that starts your E-Business system session.
ApJServDefaultHost localhost
ApJServDefaultPort
ApJServDefaultPort is the port on which Apache JServ is listening. This port is protocol dependent, which is another reason to leave the protocol alone until you have a comfort level with the alterations that you can make to these files and directives. Mismatches between this port and its associated protocol can cause a system to be unaccessable. The default port for the ajpv12 protocol is 8007.
ApJServDefaultPort 8007
ApJServVMTimeout
ApJServVMTimeout is the amount of time that you should give the JVM to startup as well as the amount of time to wait to ping the JVM to make sure that it is running and alive. The default is 10 seconds, which may be sufficient in many cases. If you are running a slower server or a heavy workload, you may want to increase the value. This can be done safely within reason. Making incremental increases to determine when performance is acceptable is recommended when making alterations.
ApJServVMTimeout 10
ApJServProtocolParameter
ApJServProtocolParameter is currently a useless directive; it is provided to pass parameter values to specified protocols. Currently, its value defaults to none. When there are protocols built that can handle this functionality, the syntax will be in the form that follows:
# Syntax: ApJServProtocolParameter [protocol name] [parameter] [value]
This directive is only included to provide positioning for future protocols. At this time, do not attempt to edit the values if any are set.
ApJServSecretKey
The ApJServSecretKey directive provides the location of the Apache JServ secret key file relative to the Apache root directory. It is critical that you know what you are going to accomplish by changing this value. The default location of this file is within the conf directory within the jserv tree. It is very important to remember that if the authentication gets set to disabled, everyone on the machine (not just this module) will be able to connect to your servlet engine and execute a servlet. By bypassing the Web server's restrictions you may be accomplishing something that you fully intended to achieve, but you may be disabling many security features unintentionally. It is important that you examine Oracle's documentation closely before you make any alterations to this directive. For readability, you should make the path to the file absolute rather than using the environment variables.
ApJServSecretKey D:\visora\iAS\Apache\jserv\conf\jserv.secret.key
ApJServMount
ApJServMount defines the mount point for servlet zones in your implementation. The syntax is:
ApJServMount [name] [jserv-url]
The default is none. Name refers to the name of the Apache path to mount the jserv-url on and jserv-url is something similar to protocol://host:port/zone(http://myserver.my.company.com:8010/zone). If no protocol, host, or port is defined in this directive, the values from ApJServDefaultProtocol, ApJServDefaultHost, or ApJServDefaultPort are used to derive these values. If there is no zone specified, the zone name will be the very first subdirectory of the particular called servlet.
ApJServMount/servlets/root ApJServMount/servlet/root
ApJServMountCopy
The ApJServMountCopy directive's value determines whether the virtual host inherits the base host mount points or not. The default is on. This directive is only meaningful if virtual hosting is being used; if not, the directive is ignored.
ApJServMountCopy on
ApJServAction
ApJServAction allows for the execution of a servlet and the passing of filenames with the proper extensions in the PATH_TRANSLATED property of the referenced servlet's request. The default for this directive is none and the directive is used extensively if you are dealing with external tools in your configuration. If you do not know if you should alter these values, do not. You will soon be able to determine if the tools that you are dealing with require alteration.
#ApJServAction.jsp/servlets/org.gjt.jsp.JSPServlet #ApJServAction.gsp/servlets/com.bitme- chanic.gsp.GspServlet #ApJServAction.jhtml/servlets/org.apache. servlet.ssi.SSI #ApJServAction.xml/serv- lets/org.apache.cocoon.Cocoon
The following code enables the Apache JServ status handler of the URLs that you call (for example, http://myserver.my.company.com:8010/jserv/). Remember that status handlers provide information to be displayed to the Web page when the URL is accessed with the trailing slash. It is important that you take measures to secure this ability, particularly in a production environment. Either comment out the container completely (invoking the default behavior of deny all) or make sure that you change the deny directive to deny or restrict access to this page. Only set the allow, from a particular set of trusted (and innumerate) IP addresses, if you have need to monitor this for any reason to provide information to support. A better solution would be to allow only from the server console and secure access to that console. Not securing this directive could allow any user to access restricted information about your servlets, their initialization parameters, JDBC passwords, or other highly sensitive information. Only sysadmins and Apps administrators have the need to know any of this information.
<Location/jserv/> SetHandler jserv-status order deny,allow deny from all allow from 123.45.6.789 </Location>
You are now at the end of both the Jserv.properties file and the module container code.
</IfModule>
Apache JServ Configuration
Called from Apache's configuration file, the next JServ file that is of great importance to Applications is the JSERV.CONF file. This file has two significant differences compared to other configuration files. Commas are used in JSERV.CONF as token separators and directives can take on multiple values that are presented as a comma-separated list of values.
This file is separated into sections, similar to the way that httpd.conf was. The first provides information on the execution of JServ.
Execution Parameters
Wrapper.bin
The wrapper.bin directive points the environment to the Java executable in the configuration. This is the path to the JVM interpreter. The full path, as opposed to relative path, should be used if the interpreter location is not in your path. For maintainability and ease of understanding, it would be a good idea to provide the full path, as well:
wrapper.bin=d:\visora\iAS\Apache\jdk\bin\java.exe
There are optional parameters that can get passed to the Java interpreter. The default is none and should be sufficient for most configurations. Seek assistance from Oracle Support when making decisions about starting to add parameters to the file.
Apache JServ entry point class is included within this section and is a parameter that should not be changed. Identified as a wrapper.class directive with a default of org.apache.jserv.JServ, it often takes on that value and does not appear as a definitive parameter in the file.
Wrapper.path
The wrapper.path directive sets the path environment value that gets passed into the JVM. Values, if they are innumerated, are separated with a ":" on UNIX platforms and ";" on Windows. The default values for this are typically sufficient for most environments and carry general default values of:
UNIX
/bin:/usr/bin:/usr/local/bin
Windows
"c:\<windows-directory>;c:\<windows-system- directory>"
Under the Windows OS, the directories will have automatically been configured during setup of the system to match the relevant directories on your particular system.
Wrapper.classpath
The wrapper.classpath directive determines the environment variables that get passed to the JVM. The default is none as Sun's Java suite already includes a default classpath, but in this case there are often values that are included in even the most generic implementation. If you are operating on UNIX, values that are concatenated without being tagged with additional wrapper.classpath directives will be separated using a ":" and on Windows with ";". The JVM has to be able to find SDK, as well as the JServ classes, any utility classes that you have opted to use in your servlets, and any that your developers have chosen to add to the servlets that they have coded to customize your environment. If there are any classes that you want to be able to automatically reload after any modifications, the classes cannot be included within the classpath that gets passed into the JVM or in the classpath that you use to start the Apache server. Any modifications made to those classpaths that are included in that manner will require the restarting of the Apache Server to take effect.
wrapper.classpath=d:\ visora\iAS\Apache\jdk\lib\tools.jar wrapper.classpath=d:\ visora\iAS\Apache\JServ\ApacheJServ.jar wrapper.classpath=d:\ visora\iAS\Apache\Jsdk\lib\jsdk.jar
Wrapper.env
The wrapper.env directive allows for further passing of environment variables into the JVM. Typically, these variables will be passed in by appending their particular values by adding to the end of the already defined PATH variable. The default is none on UNIX systems and the default on Windows is SystemDrive and SystemRoot (again configured with the appropriate values for those parameters on the initial installation and configuration of the software). While the defaults may be sufficient, it is not uncommon for there to be added values, often because the PATH on Windows is getting long and adding these values here will allow the base PATH to maintain minimally long.
wrapper.env=PATH=d:\visora\iAS\bin
Wrapper.env.copy
In the case of the wrapper.env.copy directive, these are values that get copied from the caller (the calling program) into the JVM. The default is false and usually the default is all that is used.
Wrapper.env.copyall
Similar to wrapper.env.copy, the wrapper.env.copyall signifies that all values sent from the caller should be copied into the JVM. The default is false and it is often left at the default value until there is a pressing need to alter this action. In both wrapper.env.copy and the wrapper.env.copyall directives, false means that the environment variables of the calling environment are not copied in. If you are finding that you are having strange exceptions in your environment like UnsatisfiedLinkError errors, setting these two directives to true, at least temporarily, may help you find the problem and configure the other directives to include the missing variables.
Wrapper.protocol
The wrapper.protocol directive provides the protocol that is used for signal handling to the JVM. This should match the ApJServDefaultProtocol directive from the jserv.properties file. As with the ApJServDefaultProtocol, the default of ajpv12 should be used (unless you are sure of what you are doing) and should be sufficient in most implementations.
General Parameters
The parameters and directives in this section are general in nature and are typically overridden by other directives, but they provide the default values for many parameters.
BindAddress
BindAddress is the directive that provides Apache JServ with the information about what IP addresses or host name that it should listen to (or bind to). A machine that has multiple IP addresses would use this directive to set the value that would be the single IP address to be used by this instance of Apache. If you set its value to localhost, the IP will be resolved to the IP address that has been configured for your localhost on the machine. This will allow multiple instances of Apache JServ to listen on the same port number but can direct that port to different IP addresses. You should only change the BindAddress information if you are sure of what you are doing. It could allow JServ to be wide open on the Internet, opening an unintended security breech in the system. Understand that in this case, JServ should be allowed to answer only to Apache mod_jserv, so leaving it set to localhost (typically the same IP address on every machine and only reachable from internal to that machine) is a good choice.
bindaddress=localhost
Port
Port, in this case, is set to the port on which Apache JServ listens. It defaults to 8007 and typically Port can be left at its default, particularly if you have only one instance of JServ running on a server and it is set to localhost.
port=8007
Zones
Zones is the servlet zones parameter which lists the zones that Apache JServ manages. Typically in an Oracle E-Business Suite implementation, there is one zone per instance. However, if there is more than one, they will be provided in a comma-separated list. The default is none.
zones=root
Coupled closely with the Zones are the configuration files, one for each zone. The configuration files default to none, as the zones default to none. Typically, the file that is the configuration file for the zones in an Oracle E-Business Suite implementation is the zone.properties file. For maintenance and ease of understanding, you should make sure that you use absolute pathing in the value for this parameter.
root.properties=d:\visora\iAS\Apache\JServ\ servlets\zone.properties
Pool
The Pool directive enables or disables the use of a thread pool. Extreme care must be exercised if you are going to attempt to use this feature, as it has not been extensively tested in an Oracle E-Business Suite setting and it may generate deadlocks. Even if you can get it to work reliably in a test environment, you should be very careful using it in a production environment. While it defaults to false, it would be safer to make sure that it is deliberately set to false.
pool=false
Pool.capacity
If Pool is set to true, pool.capacity is set to the number of idle threads that the pool may contain. It is set to an integer value, as partial threads do not make a lot of sense. If used, it defaults to 10. If Pool is set to false, regardless of the value that this is set to, it is ignored. If you choose to use Pool, this number should be set fairly low based on server load. An extremely busy, loaded server could have it set somewhat higher to handle bursts of activity. But again great care should be taken before implementing these directives.
pool.capacity=10
Pool.controller
Only if you have chosen to set pool = true, does pool.controller come into play. Pool.controller indicates which controller should be used to control the level of recycled threads in the pool. Even if you have set Pool to true, it is safe to leave this at its default value, .apache.java.recycle.DefaultController, unless a specific recycle behavior is required. If Pool is set to false, pool.controller is ignored regardless of its value.
pool.controller=org.apache.java.recycle. DefaultController
Security.selfservlet
Security.selfservlet is the first security parameter that you are likely to encounter in your file. This directive enables or disables the execution of org.apache.jserv.JServ as a servlet. While it defaults to false because access to the information that it could provide should be restricted, it is often set to true in an Oracle E-Business Suite implementation. Take care when testing it if you choose to alter the behavior that is set up by the installation. Because execution of Apache JServ itself as a servlet is filtered by the Web server by default, for this service to work, you will have to make sure that it is enabled not only here, but within the Apache configuration files as well. This service is useful for installation and configuration information as it provides extensive feedback about the precise configuration of Apache JServ, which is why it should be disabled when installation and configuration processes are complete.
security.selfservlet=true
Security.maxConnections
The security.maxConnections directive gets set to the maximum number of socket connections that Apache JServ is to be permitted to handle simultaneously. When making alterations to this directive, you need to be sure that the OS has enough file descriptors to allow for the number to which this gets set. It defaults to 50 and this should be enough to handle most configurations.
security.maxConnections=50
Security.backlog
The security.backlog directive is another security setting that allows for extreme fine tuning of the JServ service. Until you have a comfortable familiarity with JServ and with the server load and inner workings of your server, it is wise to leave this directive commented out.
# security.backlog=5
Security.allowedAddresses
The security.allowedAddresses directive provides a list of IP addresses that are allowed to connect to the Apache JServ. This directive assists in security filtering of possibly unsecured connections and still avoids the overhead of connection authentication. Be careful if you choose to alter the settings of this directive if it is set. Use only security.allowedAddresses=DISABLED if you are sure of what you are doing as this setting could open up your JServ to connections from the entire Internet. There is always the need in E-Business Suite setups to allow your Apache Server the ability to make this connection. Default is 127.0.0.1 which is, in effect, setting it to localhost and only allowing the computer on which it is resident to run the JServ service. If more than one IP address is to be granted this access, they should be provided in a comma-separated list.
#security.allowedAddresses=127.0.0.1
Security.authentication
The security.authentication directive either enables or disables connection authentication. Unauthenticated connections tend to be a little faster since the authentication handshake has to be performed any time that an authenticated connection connects. Authentication is disabled by default because Apache and Oracle tend to believe that connection restriction from all IP addresses except the localhost reduces the time that it takes you to initially get JServ to run. If you anticipate other addresses connecting and you are not sure that you trust all of them, you should enable this parameter to prevent untrusted execution of your local servlets. If authentication is disabled and the IP address sending the request is trusted, then everyone on that machine can execute any of your servlets.
security.authentication=false
Security.secretKey
The security.secretKey directive provides the authentication secret key that is passed as a file that must be kept secure and must be exactly the same as those used by clients to authenticate themselves. Typically there is a secret key and a public key involved. This directive defaults to none and, if provided, should use absolute pathing to make maintenance and readability easier.
security.secretKey=d:\visora\iAS\Apache\JServ\ servlets\jserv.secret.key
Security.challengeSize
The security.challengeSize directive provides the length in bytes of a randomly generated challenge string that is used to authenticate connections. A value of 5 (also the default) is the lowest possible value to ensure a safe level of security while reducing connection creation overhead. The higher the number, the more secure the connection and the higher the overhead experience on every connection attempt.
security.challengeSize=5
Log
The Log directive is the first logging parameter, takes a value of true or false (true enables server logging by Apache JServ), and allows for the enabling and disabling of Apache JServ logging. Logging tends to be a resource expensive and intensive operation when looked at in comparison to performance. If fast execution is a high concern, you should severely limit the amount of logging that is allowed to take place and you may choose to turn it off entirely. If all log channels are enabled, this log may become extremely large, as each servlet request can generate many kilobytes of log. Some channels are provided for debugging purposes only and should always be disabled in production environments.
log=true
Log.file
Log.file provides the fully qualified path and filename to which to set the trace log file. To limit confusion and aid in maintainability, use absolute pathing when specifying the location of this file. This is not the log file that is specified in the jserv.conf file, but is the log file that is dedicated to the Java portion of Apache JServ.
On UNIX, the owner of the JVM process needs to have write permission to the location of this file. That means if Apache is running as nobody, then the file and its directory need to have their permissions set such that the nobody user is able to write to it consistently.
log.file=d:\visora\iAS\Apache\JServ\logs\jserv.log
Log.timestamp
Log.timestamp enables the time stamp to be presented in the log file before the log message is provided. This makes it easier to locate the time stamp of the message and to locate the end of one day and the beginning of the next. If you know that something happened on a specific day, you can quickly locate that day and examine the log file for messages in connection with the situation.
log.timestamp=true
Log.dateFormat
Log.dateFormat tells the Apache JServ logging mechanism the format in which to present the log.
log.dateFormat=[dd/MM/yyyy HH:mm:ss:SSS zz]
Log.queue.maxage and log.queue.maxsize
Since all messages are logged to the log file by means of a thread running with only mimimal priority at the OS level, it is critical that this thread periodically get its chance to run and log messages to the log file. If it never gets to process its messages, the queue will overflow and will typically result in an OutOfMemoryError situation. To help eliminate the possibility of this occurring, two directives are presented: log.queue.maxage and log.queue.maxsize.Log.queue.maxage defines the maximum time that a logged message is permitted to remain in the queue before it gets written out to the log file. Log.queue.maxsize defines the maximum number of messages that are permitted to be in the queue at any one time.
When one of these limits is exceeded, the log file message stating that fact is generated, and the log queue is flushed to the log in a separate thread. Seeing such a message in the log file means that your system is either not performing as anticipated or you have a runaway loop some-where and it is generating a lot of messages. The defaults are not optimal and you will likely need to do considerable tweaking.
# WARNING: Default values are lousy, you probably want to tweak them and # report the results back to the development team. log.queue.maxage = 5000 log.queue.maxsize = 1000
Log.channel
Log.channel enables or disables logging the channel name. It defaults to false, disabling the channel name.
log.channel=false
Log.channel.info
Log.channel.info provides a large volume of informational messages. It is unlikely that you would want to allow this to be enabled for an extended period of time in a production environment. It has limited usefulness in any environment unless you are using it to assist you with working through a problem. Default is to not log, meaning false.
log.channel.info=true
Log.channel.servletException
Log.channel.servletException signifies that all exceptions caught during servlet service will logged to the log. You would likely want to maintain this one as true in all environments so you can capture error conditions and determine the cause of an apparent ongoing problem.
log.channel.servletException=true
Log.channel.jservException
Log.channel.jservException is another useful exception logging channel. This one logs all exceptions that are raised internally to JServ. If this is set to true, it will assist with alerting you to trouble areas on your system.
log.channel.jservException=true
Log.channel.warning
Log.channel.warning allows logging of all of the important messages that may indicate a problem, but that allow JServ to continue running. Closer examination of these messages helps you determine if you have problem areas in your system. You should allow this one to continue to run in all environments.
log.channel.warning=true
Log.channel.servletLog
With log.channel.servletLog enabled, all messages that get generated by servlets will be logged in the log file. To help you determine if you have trouble areas in your environment, you should leave this one set to true in all environments.
log.channel.servletLog=true
Log.channel.critical
Log.channel.critical allows for the capture of all critical event errors that are raised by an issue that causes JServ to stop. This one should be enabled in all environments.
log.channel.critical=true
Log.channel.debug
The log.channel.debug channel is provided only for internal debugging purposes. It is unlikely that you would want this to be enabled in your production environment (or in any environment) during periods of normal operation. In the event that you have problems that require volumes of information to debug (usually this will be at the request of Oracle Support), you can always reenable it.
log.channel.debug=false
Wrapper.classpath Directives
The following are wrapper.classpath directives that allow the inclusion of many different components into your Applications environment. Typically these are installed either at installation time or at patching time and should be left intact. The only time that this may not be true is if there is an order problem with them and you have to reorder the order that the entries are found in the file.
Oracle XSQL Servlet
wrapper.classpath=d:\visora\iAS/lib/oraclexsql.jar
Oracle JDBC (8.1.7)
wrapper.classpath=d:\visora\iAS/jdbc/lib/classes12.zip
Oracle XML Parser V2 (with XSLT Engine)
wrapper.classpath=d:\visora\iAS/lib/xmlparserv2.jar
Oracle XML SQL Components for Java
wrapper.classpath=d:\visora\iAS/rdbms/jlib/xsu12.jar
XSQLConfig.xml File location
wrapper.classpath=d:\visora\iAS/xdk/lib
Oracle Servlet
wrapper.classpath=d:\visora\iAS\jsp\lib\servlet22.jar
Oracle Java Server Pages
wrapper.classpath=d:\visora\iAS\jsp\lib\ojsp.jar
Oracle Util
wrapper.classpath=d:\visora\iAS\jsp\lib\ojsputil.jar
Oracle Java SQL
wrapper.classpath=d:\visora\iAS\sqlj\lib\translator.zip
Oracle JDBC
wrapper.classpath=d:\visora\iAS\jdbc\lib\classes12.zip
Oracle Messaging
wrapper.classpath=d:\visora\iAS\rdbms\jlib\aqapi11.jar wrapper.classpath=d:\visora\iAS\rdbms\jlib\ jmscommon.jar
OJSP environment settings
wrapper.env=ORACLE_HOME=d:\visora\iAS
This directive should be modified to reflect the location of the SID for your Web server in your environment.
wrapper.env=LD_LIBRARY_PATH=d:\visora\iAS\lib wrapper.classpath=d:\visora\iAS\Apache\BC4J\ lib\oraclexmlsql.jar wrapper.classpath=d:\visora\iAS\Apache\BC4J\ lib\jboorasql.zip wrapper.classpath=d:\visora\iAS\Apache\BC4J\ lib\jndi.jar wrapper.classpath=d:\visora\iAS\Apache\BC4J\ lib\jbomt.zip wrapper.classpath=d:\visora\iAS\Apache\BC4J\ lib\javax_ejb.zip wrapper.classpath=d:\visora\iAS\Apache\BC4J\ lib\jdev-rt.zip wrapper.classpath=d:\visora\iAS\Apache\BC4J\ lib\jbohtml.zip wrapper.classpath=d:\visora\iAS\Apache\Apache\ htdocs\OnlineOrders_html wrapper.classpath=d:\visora\iAS\Apache\Apache\ htdocs\OnlineOrders_html\OnlineOrders.jar wrapper.classpath=d:\visora\iAS\Apache\BC4J\ lib\connectionmanager.zip wrapper.classpath=d:\visora\iAS\Apache\BC4J\lib\jb odatum12.zip
This is now the end of the jserv.properties file.
Zones.Properties
Remember the Zones directive and the configuration file for the zones? The next include, called in at that point in the jserv.properties file, is the zones.properties file. This section lays out the entries in the zones.properties file.
Repositories
The Repositories directive provides a list of servlet repositories that are controlled by the servlet zone. Recall that it is possible for there to be more than one zone in a configuration and that each zone is configured and controlled by its one properties file. Classes that you want the ability to load and reload upon modification should be placed in this repository.
repositories=d:\visora\iAS/Apache/JServ/ servlets,d:\oracle\devlcomn\java/apps.zip
Autoreload.classes
The autoreload.classes directive enables or disables the auto reloading of servlet classes. It defaults to true.
autoreload.classes=false
Autoreload.file
Autoreload.file allows or disallows for the auto reloading of properties and other loaded resources into the zone. It defaults to true. Most of these directives should only be altered from the Oracle configured values once you have become comfortable with what they do and how they perform.
autoreload.file=false
Init.timeout
The init.timeout directive sets the number of milliseconds that the server should allow to pass before it gives up on initializing the servlet. A value of zero indicates that it should never give up and that there is no limit to the number of milliseconds that should be allowed to pass. Default is 10,000 milliseconds or 10 seconds.
init.timeout=10000
Destroy.timeout
Destroy.timeout sets the number of milliseconds that the server should wait before giving up on destroying a servlet after it has performed its function or stopped functioning. Again, a value of zero indicates that it should never stop waiting and the default value of 10,000 means it should wait for 10 seconds.
destroy.timeout=10000
Session.useCookies
The session.useCookies directive instructs the server whether or not to allow the use of cookies to maintain session state. If set to false, the response.encodeUrl() method will always be the method used to maintain the state. If this directive is allowed to be set to true, the servlet engine will attempt to set a cookie when request.getSession(true) is called. Setting this to true is one of the reasons that you should always allow cookies to be enabled through your browser for the zones that are likely to be serving up your Oracle E-Business Suite.
session.useCookies=true
Session.topleveldomain
Session.topleveldomain is the domain in which the particular server responsible for this zone resides. It is likely the same domain in which all of your servers reside. If you are unsure if this location is correct double-check with your internal networking people.
session.topleveldomain=.domain.company.com
Session.timeout
Session.timeout sets the number of milliseconds that the server should wait before invalidating unused sessions. This directive allows for the graceful cleanup of sessions that have errored out and not been cleaned up as a part of an elegant shutdown. It defaults to 1,800,000 milliseconds or 30 minutes.
session.timeout=600000
Session.checkFrequency
Session.checkFrequency sets the frequency at which the server checks for timed out sessions. It defaults to 3000 milliseconds or 30 seconds.
session.checkFrequency=30000
Single Thread Model Servlets
Single Thread Model (STM) servlets allow programmers to not worry about multi-threading when they are writing their code. This is common when servlet programmers begin to program in multi-threaded manner, but do not take multi-threading into account. They rely on the STM mode, because they do not know how or do not want to learn how to write multi-thread safe code. This usually means that your system will get hit with performance issues, information sharing issues, or issues arising because your servlets are being used in a multi-user environment. While Oracle E-Business Suite (out of the box) takes multi-threaded environments into account, this is another place you have to be very careful when you start customizing your environment that you do not shoot yourself in the foot.
SingleThreadModelServlet.initialCapacity
SingleThreadModelServlet.initialCapacity sets the initial capacity of the STM servlets in your zone. It defaults to 5.
singleThreadModelServlet.initialCapacity=5
SingleThreadModelServlet.incrementCapacity
SingleThreadModelServlet.incrementCapacity allows you to set the number of servlet instances that should be added to the pool, if the pool should be found empty. Again, it defaults to 5.
singleThreadModelServlet.incrementCapacity=5
SingleThreadModelServlet.maximumCapacity
SingleThreadModelServlet.maximumCapacity sets the maximum capacity of the STM pool. This is a safety check feature that prevents runaway environments. Care should be taken on tuning this, particularly when customizations are involved.
singleThreadModelServlet.maximumCapacity=10
Servlet Properties
The following are servlet parameters. When keyword "classname" is specified, it means that a Java dot-formatter full classname should be used there without the .class extension. If you want to pass private initialization data to the servlet, Apache allows for the use of a separate file named <servlet classname>.initArgs in the same directory as the servlet.
Servlets.startup
Servlets.startup denotes a list of servlets that should be launched on startup. These can either be classnames or aliases and the default is none. The servlets can either be presented in a comma-separated list or with the servlets.startup directive on each line.
servlets.startup=oracle.apps.icx.common. InitSystemProperties servlets.startup=oracle.apps.ecx.oxta. TransportAgentMain
The following list defines aliases from which servlets are able to be invoked. Each alias allows for a new instance of the servlet. If a servlet is invoked by a classname and then invoked by an alias, it will result in two instances of the servlet being created. Make sure that this is the way you want this to work.
servlet.CatalogTemplates.code=oracle.apps.icx. catalog.ui.DownloadServlet servlet.ibyscheduler.code=oracle.apps.iby. scheduler.PSReqHandler servlet.ibyecapp.code=oracle.apps.iby. ecservlet.ECServlet servlet.oramipp_lop.code= oracle.apps.iby.bep.loop.LoopBackServlet
Servlets.default.initArgs
Servlets.default.initArgs lists out the parameters that are passed to each of the servlets called on your system. You should put configuration information in here that is common to all servlets on your system. The value of this property is a comma-delimited list of name=value pairs accessed by the servlet via the getInitParameter() method. Default is none. In Apps, FND_TOP parameters should be allowed to be placed into this directive.
servlets.default. initArgs=FND_TOP=d:\visappl\fnd\11.5.0
Servlet.oracle Properties
The following directive properties define the initialization parameters that are available for each servlet that gets invoked on the system by using its classname. Again, it defaults to none.
servlet.oracle.jsp.JspServlet.initArgs= translate_params=true,developer_mode=false,page_re pository_root= d:\viscomn/html/_pages servlet.oracle.jsp.JspServlet.ini- tArgs=alias_translation=true servlet.oracle.apps.icx.common.InitSystemProperties. initArgs=initFile= d:\visora\iAS/Apache/Jserv/etc/ssp_init.txt
Initialization Properties
The following directive properties define the initialization parameters that are available for each servlet that is invoked by its alias. This separation of these two sets of initialization parameters allows you to pass different parameters based on how the servlets are called.
Oracle Applications Manager
servlet.weboam.code=oracle.apps.oam. servlet.ui.OAMServlet
Manadatory Cabo settings; do not modify these.
servlet.weboam.initArgs=oracle.cabo.servlet. pageBroker=oracle.apps.oam.servlet.ui. oamUIXPageBroker servlet.weboam.initArgs=oracle.cabo.servlet. loginPage=oam/oamLogin servlet.weboam.initArgs=oracle.cabo.servlet. loggedInKey=oracle.apps.oam.oamUserData
End of mandatory settings.
servlet.weboam.initArgs=oracle.cabo.servlet. xml.UIXPATH=d:\viscomn/html servlet.weboam.initArgs=oracle.apps.oam.logger. path=d:\ viscom/html/oam servlet.weboam.initArgs=oracle.apps.oam.logger. filename=weboam.log servlet.weboam.initArgs=oracle.apps.oam.trace=off servlet.weboam.initArgs=oracle.apps.oam.logger. history=on servlet.weboam.initArgs=oracle.apps.oam. dbInitParams.path=d:\ viscom/html/oam/config servlet.weboam.initArgs=oracle.apps.oam. dbInitParams.filename=dbInitParams.xml servlet.weboam.initArgs=oracle.apps.oam. standalone=on servlet.weboam.initArgs=oracle. apps.oam.sqlplus_home=d:\visora\iAS servlet.framework.code=oracle.apps.fnd. framework.provider.OAFrameworkHttpProvider servlet.framework.initArgs=dbcFileName=d:\ visappl\fnd\11.5.0/secure/server_sid.dbc servlet.framework.initArgs=sessiontimeout=1800000 servlet.framework.initArgs=appPath=/OA_HTML servlet.framework.initArgs=appRealPath=d:\ viscomn/html
MapViewer OMSLauncher
servlet.oms.code=oracle.spatial.mapserver. omslauncher servlet.oms.initArgs=remote_name=mapviewer, oms_config_file=d:\visora\iAS/Apache/mapviewer/ conf/mapViewerConfig.xml,registry_port=9800
WEBADI Servlet
servlet.BneSnoopServlet.code=oracle. apps.bne.framework.BneSnoopServlet servlet.BneProxy.code=oracle. apps.bne.share.BneProxy servlet.BneComponentService.code=oracle. apps.bne.integrator.component.BneComponentService servlet.BneDocumentService.code= oracle. apps.bne.integrator.document.BneDocumentService servlet.BneApplicationService.code=oracle. apps.bne.webui.BneApplicationService servlet.BneCaboTestServlet.code=oracle. apps.bne.framework.BneCaboTestServlet servlet.BneUploaderService.code=oracle. apps.bne.integrator.upload.BneUploaderService
Sourcing Servlet
servlet.fndgfm.code=oracle.apps.pon.attachments. Fndgfm servlet.MonitorServlet.code=oracle.apps.pon.auctions. monitor.MonitorServlet
JServ can provide you with extensive flexibility and is a very powerful and maintainable service.
|
| < Day Day Up > |
|
EAN: 2147483647
Pages: 122