RollingFileManager not removed when RollingFileAppender is stopped, using DirectWriteRolloverStrategy

When programmatically creating an instance of RollingFileAppender using RollingFileAppender.newBuilder.(config options).build(), an instance of RollingFileManager is created in AbstractManager.getManager(...), and this instance is stored in the hashmap AbstractManager.MAP as well as on the instance of RollingFileAppender in the super class AbstractOutputStreamAppender. This manager is created and stored in the AbstractManager.MAP with the name FILE_PATTERN (since we cannot create an instance of RollingFileAppender with a file name using the DirectWriteRolloverStrategy). However, the same manager is created with a NAME of NULL since it is trying to use file name as the name of the manager, but this parameter is not allowed using DirectWriteRolloverStrategy.

The problem here is that the RollingFileManager is created with a name of FILE NAME (i.e., NULL when using DirectWriteRolloverStrategy) and added to the hashmap with a key of FILE PATTERN, but when the rolling file appender is stopped, it attempts to remove its manager from this MAP using RollingFileManager.name, which equates to FILE NAME which is NULL.

Consider the following example:

• create a rolling file appender using the DirectWriteRolloverStrategy with a file pattern of 'output.%i.log'
• a RollingFileManager is created with the name NULL, but put in AbstractManager.MAP with the name 'output.%i.log'
• the rolling file appender is used to write a few line of log file
• the rolling file appender is stopped using RollingFileAppender.stop(..)
• the RollingFileManager is NOT removed from AbstractManager.MAP since it is trying to remove FILE NAME but it is keyed on FILE PATTERN
• a NEW instance of rolling file appender is created using the DirectWriteRolloverStrategy with the SAME file pattern of 'output.%i.log'.
• a new instance of RollingFileManager is NOT created, as it already exists in the MAP, so the old instance is simply returned
• the instance of RollingFileManager for the new instance of RollingFileAppender has a closed output stream, meaning that no logging is possible.

In the above example you can see that if the old rolling file appender's output stream is closed, and a new instance created with the same file pattern, then the old manager will be used. I see no easy way of recreating this output stream.

I found no documentation regarding why one cannot set the FILE NAME for a RollingFileAppender using DirectWriteRolloverStrategy. Being able to configure this may also solve the problem (unless it causes issues elsewhere), but another possible fix to this issue is to create the RollingFileManager with the name FILE PATTERN when using the DirectWriteRolloverStrategy. This way we add to the MAP the instance of RollingFileManager with the key FILE PATTERN, and we remove from the MAP RollingFileManager.name which equals FILE PATTERN