[
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522499#comment-17522499
]
Ralph Goers commented on LOG4J2-3476:
-------------------------------------
This is where you start to cross the line between API and implementation in my
opinion. It was bad enough when we added shutdown, but manipulating the logging
configuration is an implementation feature IMO.
> Support JUL ApiLogger::setLevel
> -------------------------------
>
> Key: LOG4J2-3476
> URL: https://issues.apache.org/jira/browse/LOG4J2-3476
> Project: Log4j 2
> Issue Type: New Feature
> Components: JUL adapter
> Affects Versions: 2.17.2
> Reporter: Remko Popma
> Assignee: Remko Popma
> Priority: Major
> Fix For: 2.17.3
>
>
> The current implementation of ApiLogger::setLevel is to throw an
> UnsupportedOperation Exception.
> It turns out that Gradle's internal logging tries to call this method under
> some configurations, and it cannot deal gracefully with that Exception, so
> the build fails.
> -[~mattsicker] I was wondering if there is any reason why the implementation
> could not be like this:-
> {code}
> @Override
> public void setLevel(final Level newLevel) throws SecurityException {
> doSetLevel(newLevel);
> Configurator.setLevel(logger, LevelTranslator.toLevel(newLevel));
> }
> {code}
> -I will try this in a test project.-
> (5 minutes later...) Looking at LOG4J2-1110, I understand that this can be
> done in CoreLogger but not in ApiLogger.
> Still, would it be possible to silently ignore this call to setLevel, rather
> than throwing an UnsupportedOperationException?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
