[
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522494#comment-17522494
]
Carter Kozak commented on LOG4J2-3476:
--------------------------------------
I agree with the api/implementation separation and would prefer not to add
level/configuration-mutation features to the api logger. In fact, I consider it
a feature that JUL backed by log4j cannot override my configuration
unexpectedly, although I can understand why it is desirable and wouldn't be
opposed to supporting it :-)
It sounds reasonable that the CoreLogger could support level updates, while the
ApiLogger would not (if log4j-core is not available, some other facade like
slf4j may not support level updates)
> 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)
