While using IBM WAS as an application server, there might be a need to understand certain artifacts here.
This helps in understanding the internal behavior and identifying the components in IBM WAS.
IBM WAS stores its configuration to set of XML files.
When you use the Administrative console to configure IBM WebSphere, certain XML files are updated internally. Here are the details:
Contains the roles set for administration of the Admin console.
Contains a list of profiles and profile configuration data
Defines operating cell scope environmental resources, including JDBC, JMS, JavaMail, URL end point configuration, and so on.
Contains security data , including all user ID and password information.
Contains virtual host and Multipurpose Internet Mail Extensions (MIME)-type configurations.
Contains cell level WebSphere variables
Contains the federated repository configurations for global security
Provides persistent JNDI namespace binding data
Defines node scope environmental resources, including JDBC, JMS, JavaMail, URL end point configuration, and so on
Specifies all the ports used by servers on this node
Contains node level WebSphere variables
Contains the configuration of resources, such as, JDBC, JMS, JavaMail, and URL end points at server scope
Contains application server configuration data
Contains server level variables
If the global security is enabled WebSphere Application Server cell, you need to manually enter the username and password every time you run the wsadmin tool. By editing the sas.client.props and the soap.client.props files, you can specify the username and password you have configured for global security so you are not prompted to enter the username and password every time you run administrative scripts.
Optionally, set the following property:
Also, set the following property:
stdout and stderr streams are redirected to log files at application server startup, which contain text written to the stdout and stderr streams by native modules, that is, Linux Modules, and so on. In normal error-free operations, these logs files are typically empty.
It is created in your logs directory when the server starts up. This log is very useful to determine JVM parameters used in the start-up process, the server’s process id, and also the date and time in which the server was started. If there are errors experienced during the start-up (for example, security configuration errors where the application server cannot start), then log information will exist for problem determination.
when server was stopped via a command line, the log will be written to this. If the server has trouble stopping, then Java stack traces will be written to the log which can be used in determining why a given application server failed to stop.
contains Java exceptions and stack traces. An empty SystemErr.log file does not necessarily indicate a successfully running application server JVM. You may need to consult the other logs in this directory.
This log file contains messages as generated by the JVM during runtime. Some messages are informational, some are warnings or status updates. Applications can be configured to write to the log and so it is very common for the SystemOut.log to be your first port of call in application debugging.
contains the process id of the server. In Linux, this is the actual process id assigned to the JVM process.
FFDC directory contains detailed logs of exceptions found during the runtime of the WebSphere Application Server. Can be found at WAS_ROOT/profiles/logs/ffdc