You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Volkan Yazici (Jira)" <ji...@apache.org> on 2022/05/02 21:14:00 UTC

[jira] [Closed] (LOG4J2-3476) Support JUL ApiLogger::setLevel

     [ https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Volkan Yazici closed LOG4J2-3476.
---------------------------------
    Resolution: Fixed

> 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.18.0
>
>
> 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.7#820007)