Add support for subsystem logging.properties

[edewata]

The CMSEngine, ACMEEngine, and ESTEngine have been modified to support subsystem logging.properties. If the file exists, it can be used to configure the logging level in various libraries (e.g. RESTEasy) to help troubleshooting.

The CA, ACME, and EST tests have been modified to create the subsystem logging.properties then check the debug log.

https://github.com/dogtagpki/pki/wiki/Configuring-Subsystem-Debug-Log

If RESTEasy logging is enabled, it will show something like this:

2025-02-20 17:06:11 [main] INFO: RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.dogtagpki.acme.server.ACMEApplication
2025-02-20 17:06:11 [main] INFO: RESTEASY002200: Adding class resource org.dogtagpki.acme.server.ACMELoginService from Application class org.dogtagpki.acme.server.ACMEApplication
2025-02-20 17:06:11 [main] INFO: RESTEASY002200: Adding class resource org.dogtagpki.acme.server.ACMELogoutService from Application class org.dogtagpki.acme.server.ACMEApplication
2025-02-20 17:06:11 [main] INFO: RESTEASY002200: Adding class resource org.dogtagpki.acme.server.ACMEEnableService from Application class org.dogtagpki.acme.server.ACMEApplication
...

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
64.2% Duplication on New Code

See analysis details on SonarQube Cloud

[fmarco76]

For testing purpose I think it is as quicker as modify the logging.properties in the webapp.

If this is a was to allow different customisation in case of multiple instances running in the same server then we should provide a full customisation of the logger.

[fmarco76]

Since we call the file logging.properties I am expecting that the provided values should overwrite the existing to modify the logs. So I would try to update the full configuration

[edewata]

OK, I can try that. I wasn't sure whether the LogManager will override just the params specified in the custom logging.properties or replace the entire logging config with the custom logging.properties (meaning the handlers need to be redefined in the custom logging.properties).

[fmarco76]

See above

[fmarco76]

See above

[edewata]

For testing purpose I think it is as quicker as modify the logging.properties in the webapp.

Yes, for testing we can just modify the default logging.properties but the changes are temporary (will be lost after upgrade).

If this is a was to allow different customisation in case of multiple instances running in the same server then we should provide a full customisation of the logger.

Even with a single instance, the custom logging.properties can be used to permanently customize the logging config (e.g. only log error messages) just like setting the debug.level in CS.cfg which won't be affected by upgrade. Let me try the LogManager as you suggested. Thanks!