[
https://issues.apache.org/jira/browse/LOG4J2-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16897461#comment-16897461
]
Adam Gent commented on LOG4J2-2649:
-----------------------------------
{quote}
It is hard to find any meaning in your startup time numbers since we have no
idea what your programmatic configuration does. It would be helpful to be a
little more specific in pointing out the areas where reflection is a problem.
{quote}
It's pretty hard to get performance times (ie JMH) on boot/load performance.
Anyway I don't think reflection is the performance problem and I'm just
conjecturing as to why given my brief look at the code (and no I don't think it
sucks).
Anyway here is the code:
{code}
public static Configuration createConfiguration(
final String name,
ConfigurationBuilder<BuiltConfiguration> builder) {
builder.setConfigurationName(name);
builder.setStatusLevel(Level.ERROR);
AppenderComponentBuilder appenderBuilder =
builder.newAppender("Stdout", "CONSOLE")
.addAttribute("target", ConsoleAppender.Target.SYSTEM_OUT);
appenderBuilder.add(builder.newLayout("PatternLayout")
.addAttribute("pattern", "%d{HH:mm:ss.SSS} [%t] %-5level
%logger{36} - %msg%n"));
builder.add(appenderBuilder);
Level level = Level.INFO;
builder.add(builder.newLogger("com.snaphop", level));
builder.add(builder.newRootLogger(Level.ERROR)
.add(builder.newAppenderRef("Stdout")));
return builder.build();
}
public static void initialize() {
Configurator.initialize(createConfiguration("root",
ConfigurationBuilderFactory.newConfigurationBuilder()));
}
{code}
As you can see the code is following the Configurator.initialize approach.
Here is logback:
{code}
public class CustomLogbackConfigurator extends BasicConfigurator {
@Override
public void configure(
LoggerContext lc) {
addInfo("Setting up default configuration.");
ConsoleAppender<ILoggingEvent> ca = new
ConsoleAppender<ILoggingEvent>();
ca.setContext(lc);
ca.setName("console");
LayoutWrappingEncoder<ILoggingEvent> encoder = new
LayoutWrappingEncoder<ILoggingEvent>();
encoder.setContext(lc);
// same as
// PatternLayout layout = new PatternLayout();
// layout.setPattern("%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -
// %msg%n");
TTLLLayout layout = new TTLLLayout();
layout.setContext(lc);
layout.start();
encoder.setLayout(layout);
ca.setEncoder(encoder);
ca.start();
Logger rootLogger = lc.getLogger(Logger.ROOT_LOGGER_NAME);
rootLogger.setLevel(Level.INFO);
rootLogger.addAppender(ca);
}
}
{code}
Then register that with
META-INF/services/ch.qos.logback.classic.spi.Configurator
{quote}
Creating your own SLF4J bindings is certainly one way to solve the problem.
Offering suggestions or patches is another. Just saying the code sucks doesn't
help anyone.
{quote}
I think you took this more personal than I intended. I never said the code
sucked. I even complimented the work on the garbage free portion. I certainly
can and will look into doing PRs as I did that for logback but regardless there
is a gap in logging implementations between full featured logback/log4j2 and
pure static loggers like microlog. I think most microservices don't need what
current logging libraries are doing. Furthermore I think annotation processing
and code generation might lead to some interesting performance enhancements
that are probably out of scope for log4j2.
I'm also just pretty jaded with past experiences with logging libraries. We are
in a microservice world and yet we have libraries doing way too much. So yeah I
was being a little bit of an asshole. Sorry.
{quote}
If you are talking about how plugins are loaded, in master all plugins are now
all loaded with help of the ServiceLoader.
{quote}
I didn't see that as I was browsing the current release code via IDE code
download. I will certainly check it out.
I also thought you might not be aware of the ServiceLoader given you were not
aware of GraalVM. Again don't take it personal.
> Is Log4j2 considered to support successful static compilation under GraalVM?
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-2649
> URL: https://issues.apache.org/jira/browse/LOG4J2-2649
> Project: Log4j 2
> Issue Type: New Feature
> Reporter: YangGuanchao
> Priority: Blocker
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Oracle released GraalVM [https://github.com/oracle/graal] to support the
> static compilation of Java applications to Native Image, which can increase
> the startup speed of Java by at least 10 times. In the cloud native field,
> this basic technology is believed to be in the near future. Will be supported
> by more and more vendors, such as the Spring/Spring Boot community has
> supported or plans to support the feature of GraalVM, see this issue:
> [https://github.com/spring-projects/spring-framework/search?q=Graalvm&type=Issues]
> can support static compilation, so it is recommended that Log4j2 also need
> to support static compilation as soon as possible, and can be compiled
> correctly under GraalVM.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
