[ https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17523001#comment-17523001 ]
ASF subversion and git services commented on LOG4J2-3476: --------------------------------------------------------- Commit e865c9ad7bd9601fda6010a12dd48bbd61b005a6 in logging-log4j2's branch refs/heads/release-2.x from Remko Popma [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=e865c9ad7b ] LOG4J2-3476 ignore JUL ApiLogger.setLevel without error > 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)