-
Feature Request
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
Overview
We are currently using the org.jboss.logmanager:jboss-logmanager:2.1.19.Final in WildFly and JBoss EAP. It would good to be able to upgrade to the 3.x version. This would align WildFly/EAP with Quarkus on the version being used.
API Changes
For the most part the users will not see many differences. If they don't use custom handlers. There have been removed API's, which were not supported. There has been one change that would affect any user using a org.jboss.logmanager.ExtHandler. This is the way locking works for the handler, see https://github.com/jboss-logging/jboss-logmanager/pull/380.
Removed API:
- The org.jboss.logmanager.config was removed. This was not intended to be exposed to users, but was used in the subsystem for it's configuration,
LOGMGR-217 - Removed the "protection' API,
LOGMGR-214. This was never used.
Changed API's
- User using a org.jboss.logmanager.ExtHandler to create their own handler, e.g. custom-handler, may need to make some changes. If they previously use the old outputLock for synchronization, they need to change to use the new lock.
Improvements
There are several improvements in this release as well. One example is a new ColorPatternFormatter which gives more robust color on the console. We could even log a logo ![]()
I would also like to remove the logging.properties file that is currently required for bootstrap logging. This has been something I've wanted to see removed for a very long time now. The idea would be to queue messages until the logging subsystem kicks in. While this could be done with 2.1.19.Final, there are improvements for this in 3.x.
The JsonFormatter has also been migrated to use the jakarta.json namespace.
Better 17 support. JUL has added new methods like LogRecord.getLongThreadId() in Java 17. Some LogRecord methods have also been removed and some added. We've managed some of this in 2.1.x, however it's becoming cumbersome to do so.
Better support for error handling. Handlers themselves can be defined in an ErrorManager instead of just writing to stderr.
- blocks
-
WFCORE-474 Custom formatter property changes not written to, but overriden by logging.properties
-
- Open
-
-
WFCORE-2516 Changes to the logging subsystem are not persisted to the logging.properties in offline CLI
-
- Open
-
-
WFCORE-5275 Socket handler is holding server to start
-
- Open
-
-
WFCORE-157 Write expressions to logging.properties configuration file
-
- Open
-