Configuration files
Trace configuration (definition of "logger", "appender" and "layout" components) uses a file.
In an Adelia Cloud execution context, this configuration can also be set up - dynamically - using the trace manager accessible from the Adelia Desktop.
- C/Windows: log4c.xml
The configuration file is called log4c.xml.
The file is searched for as a priority in the path entered by the LOG4C_PATH environment variable, then in the current directory, and finally in the Adelia Runtime C/Windows installation directory (ADELIWS environment variable).
A reference example file log4c.xml.new is provided when installing the product or Adelia Studio runtime as a potential basis configuration.
If there is no configuration file, the LOG4C_PRIORITY and LOG4C_APPENDER environment variables may be used to declare a severity level and an "appender" to the highest "logger" level ("root").
It is possible to set the SD_DEBUG and/or SD_ERROR environment variables in order to trace the Log4c initialization phase in a file called: "%temp%/ log4c_debug_file_<usr>_<pid>.log".
- AS/400 : *DTAARA LOG4AS | log4c.xml
Activation of traces on the AS/400 platform requires the presence of a DTAARA (TYPE (*CHAR) LEN (128) ) called LOG4AS in the execution context.
The DTAARA can be used in two forms:
A/
LEV[:JLOG[:format]]
LEV => 3 characters expressing the severity level:
FAT: FATAL
ERR: ERROR
WRN: WARNING
INF: INFO
DBG: DEBUG
TRC: TRACE
OFF: Deactivate
Example: DBG
Initialization of trace management automatically redirects the stdout output to the spool file called LOG4STDOUT.
In this case of simplified configuration, the traces are all produced in the LOG4STDOUT spool file.
It is also possible to produce traces in the work log. To do this, add the term JLOG after the severity level.
Example: DBG:JLOG
The resulting trace is then formatted by default with the following pattern: [%-5p][%-30c][%m] where p is the severity level, c is the logger name, and m is the message.
It is possible to modify the formatting by specifying a pattern after JLOG.
Example: DBG:JLOG:%p-%m
Note: the definition of reasons is given in the reference file log4c.xml.
B/
The string refers to the configuration file log4c.xml located in the IFS.
Example: '/conf_log/log4c.xml'
In this case, the configuration is identical to that of the C/Windows platform.
It should be noted that the standard output stdout is automatically redirected to the spool file called LOG4STDOUT.
Errors detected in the Log4c initialization phase are systematically traced in this spool file.
- Java – Adelia Web – Cloud
- Java – Adelia Web
The configuration file is called log4j.properties or log4j.xml.
The configuration file read is the first file encountered with regard to the CLASSPATH environment variable.
A specific file can be loaded by adding the directive –Dlog4j.configuration=<CfgFileName> when starting up the JVM.
A reference example file log4j.properties.new is provided when installing the product or Adelia Studio runtime as a potential basis configuration.
The log4j.debug environment variable can be added when starting up the JVM to trace the log4J initialization phase.
Example: java –Dlog4j.debug <package>.<mypgm>
- Java – Adelia Web
-
- Cloud
The configuration file is called log4j.lcf.
The file is read in the WEB-INF/conf directory of the application or externalized via a jndi resource called url/adeliaLog4jConfig.
- Cloud
Configuration spaces
DB Queries/Performances
The traces dedicated to the database layer use the following specific "loggers":
- hasqllogger.func: used to trace SQL errors (ERROR level) or SQL errors and internal API errors (WARN level).
- hasqllogger.dump: INFO level, in conjunction with the EnableLog4SessionDump key positioned at Runtime DB configuration file value 1, is used to trace all SQL activity in real time (queries, parameter values, read data).
- hasqllogger.counters: INFO level, in conjunction with the PerformanceInfoLevel key positioned at Runtime DB configuration file value > 0, is used to trace statistical information and general performance when disconnecting.
N.B.: DB layer traces (General performance and SessionDump) can also be enabled – completely �separately from unified trace management mode - via the runtime DB configuration file (apiva.properties for the Java platform and apiconf.ini for the C/Windows platform).
Example:
Apiconf.ini |
apiva.properties |
[Trace] ; SessionDump ; dumps all session information (use with caution - large files generated) SessionDumpFile=[file name]
; performance information ; 1/ general performance counters ; 2/ request performance counters PerformanceInfoLevel=1 PerformanceInfoFile=[file name] |
# SessionDump # dumps all session information (use with caution - large files generated) SessionDumpFile=[file name]
# performance information # 1/ general performance counters # 2/ request performance counters PerformanceInfoLevel=1 PerformanceInfoFile=[file name] |
Traces (request performance; PerformanceInfoLevel=2) producing a delimited ASCII file with detailed information for each request executed at the end of the session can only be enabled by the runtime DB configuration file.
Example:
Apiconf.ini |
apiva.properties |
[Trace] ; performance information ; 1/ general performance counters ; 2/ request performance counters PerformanceInfoLevel=2 PerformanceInfoRequestFile=[file name] |
# performance information # 1/ general performance counters # 2/ request performance counters PerformanceInfoLevel=2 PerformanceInfoRequestFile=[file name] |
Middleware
Information relating to the Middleware can be collected using the "logger" called com.hardis.middleware and severity levels:
-
- ERROR: errors detected when connecting to the service or when exchanging frames between the client part and the server part.
- INFO: information about the connection and exchange of data with the service.
- DEBUG: detail of frames exchanged between the client part and the service.
Information relating to:
-
- the Middleware session preparer can be traced using the "logger" called com.hardis.adelia.sessionPrep.
- the Middleware session pool can be traced using the "logger" called com.hardis.adelia.pool.
Web services
SOAP
- Consumption: the "logger" components called com.hardis.adelia.webservice (Java – Web – Cloud ) and com.hardis.adelia.varuntme.vrtcwebservice2 (C/Windows) are used to trace the SOAP web service consumption Adelia overlay.
Traces of the underlying Axis2 layer can be enabled via the "logger" components called:
- Consumption: the "logger" components called com.hardis.adelia.webservice (Java – Web – Cloud ) and com.hardis.adelia.varuntme.vrtcwebservice2 (C/Windows) are used to trace the SOAP web service consumption Adelia overlay.
Java – Web – Cloud platforms:
• org.apache.axis2
• org.apache.axiom
• org.apache.commons.http
C/Windows platform: org.apache.axis2c
- Production: the prerequisites for generating traces for a SOAP Web service as follows:
Deployment of the LoggingModule.mar module in the WEB-INF/modules sub-directory
Addition of <module ref="LoggingModule"/> to the WEB-INF/conf/Axis2.xml file
Addition of <phase name="loggingPhase"/> to the WEB-INF/conf/Axis2.xml file as the last sub-element of the four <phaseOrder> elements.
Once the prerequisites have been fulfilled, the DEBUG-level "logger" components called org.apache.axis2.soap.request and org.apache.axis2.soap.request_response can trace the request made to the service and, if favourable, the response returned to the client.
- REST (production): REST web service execution trace generation can be enabled in the WEB-INF/beans.xml file by removing the comments from the following lines:
<!--cxf:bus>
<cxf:features>
<cxf:logging />
</cxf:features>
</cxf:bus-->
Crystal Reports reports
Information relating to the production of Crystal Reports reports can be gathered using the "logger" component called com.hardis.adelia.vacrysrt.vacrysrtgen (or com.hardis.adelia.svcgenrap for the print service) and severity levels:
-
- ERROR: errors detected during report loading, translation, generation, preview, export or printing.
- INFO: information about the different steps of the report production process.
- DEBUG: detail of data populating the reports.
Miscellaneous
More generally, all the "logger" components:
-
- of Adelia runtime inherit from the "logger" called com.hardis.adelia,
- of Adelia middleware inherit from the "logger" called com.hardis.middleware,
- from Adelia VaToolBx inherit from the "logger" called com.hardis.vatoolbx (and com.hardis.adelia.cloud.vatoolbx in a Cloud context).
C/Windows platform
-
- The C source generated from a private visibility program declares the "logger": pgm.<DomainName>.<ObjectName>.<ModuleName>
-
- The C source generated from a public visibility program declares the "logger": pgm.env.<ObjectName>.<ModuleName>
AS/400 platform
-
- The RPG source generated from a private visibility program declares the "logger": pgm.<DomainName>.<ObjectName>.<ModuleName>
-
- The RPG source generated from a public visibility program declares the "logger": pgm.env.<ObjectName>.<ModuleName>
Java/Web/Cloud platforms
-
- The Java source generated from a program declares the "logger": <package>.<ObjectName>.<ClassName>