[
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522249#comment-17522249
]
Gary D. Gregory commented on LOG4J2-3476:
-----------------------------------------
Ah, right. So the next question is why not add a level setting method to
log4j-api. This is one feature that all the apps I have worked on and up using.
> 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)
