InfoCenter Home >
6: Administer applications >
6.6: Tools and resources quick reference >
6.6.3: Administering application servers (overview) >
6.6.3.0: Application server properties
Key:
Applies to Java administrative console of Advanced Edition Version 4.0
Applies to Web administrative console of Advanced Single Server Edition Version 4.0
Applies to Application Client Resource Configuration Tool
An application server contains a variety of configurations:
... as well as these additional settings:
-
Application Server Name
or Name
- A logical name for the application server. The name must unique within the node
(physical machine) containing the application server.
-
Execution State
or Node Startup State
- For the Advanced Single Server Edition: The state that you would like for the application
server to be in, the next time the product is stopped and started again.
For the Advanced Edition: The state you would like the application server to be in,
the next time the node containing the application server is stopped and started again.
Choices are Stopped, Running, and Last State (meaning the last state that the application
server was in, before node was stopped).
-
Module Visibility
- The classloader isolation mode to use for the application server. By changing the default visibility level,
it is possible to have visibility of classes in other modules, or even other
applications.
- Specify "SERVER" to allow all application classloaders on the system to have visibility of all other
application classloaders in the system. Search order is the same order as when the modules were
initialized into the system.
- Specify "APPLICATION" to allow all classloaders in a J2EE application to have visibility of other
classloaders in the same application. Search order is the order the modules are defined in the
application.xml for the EAR.
- Specify "MODULE" to use one classloader per module. Each module (EAR, JAR, or WAR) has its own
unique classloader. Visibility to other modules in the application is only achieved when MANIFEST
Class-Path entries are added to a module.
- Specify "COMPATIBILITY" for compatibility with applications from WebSphere Application Server
3.5.x and 3.0.2.x. In this mode, all EJB module classloaders have visibility of all other
EJB module classloaders and all Web Application modules have visibility of the EJB classloaders.
Search order for the EJB classloaders is determined by the order in which the EJB modules were
initialized.
Portable J2EE applications should be written with Module-level visibility. The other
modes are provided to accomodate applications that have different visibility requirements
that cannot be modified.
The default module visibility differs between Advanced Edition and
Advanced Single Server Edition.
- The Advanced Edition default is MODULE.
- The Advanced Single Server Edition default is APPLICATION.
Suppose you have a WAR module that depends on an EJB JAR installed in a different
application or the same application, but the WAR module lacks a manifest classpath entry.
Such a WAR module will run on
Advanced Single Server Edition using the default settings, but will not run on
Advanced Edition until you reset the Module Visibility field to COMPATIBILITY.
If you do
not want to run Advanced Edition WAR modules in COMPATABILITY mode, then specify the
classpath during assembly for the WAR module that you are going to run on Advanced Edition.
-
Name
- See Application Server Name
-
Node
- The administrative node on which the application server resides
-
Node Startup State
- See Execution State
|
|