Support Janino in a native image #33758
Comments
spring-projects-issues
added
the
status: waiting-for-triage
philwebb
added
type: bug
wilkinsona
changed the title
|
https://stackoverflow.com/questions/75514151/spring-boot-native-image-does-not-print-logs-when-logback-is-configured-with-con contains another sample that exhibits slightly different faulty behaviour – this sample starts successfully but no logging output is produced. |
|
In the example from the stackoverflow question, I also get the exception from the original post if no metadata is added to |
|
Unfortunately, supporting Janino is non-trivial. It relies on generating One option that we could explore is generating the |
|
I've prototyped something in this branch. It's not a lot of code, but I'm not happy with |
wilkinsona
added
the
for: team-meeting
|
@wilkinsona Thanks for implementing #34315 so quickly! The sample application from the stackoverflow question now fails early and logs a meaningful exception. I've added it to the SO question. |
|
Do you have any workaround to write an equivalent programmatically and have a chance to make it work with spring native? |
|
I'm afraid not. #25847 is tracking support for programmatic configuration of Logback. |
wilkinsona
changed the title
wilkinsona
added
type: enhancement
|
@ceki would you consider making some changes to |
|
@wilkinsona Sure, I am open to changes. I have looked at your efforts to support logback with GraalVM which are quite impressive. For your information, I have started to explore a path for supporting GraalVM which you might find interesting: Note: experimental changes in 1.4.9 (commit bd11e72017941331f2c3ba5101429359aced5a47 not yet released)
Anyway, I am still experimenting and am not sure of the results, that is whether this will work with GraalVM without the need for an XML parser. Coming back to your original question, I understand that the experimental approach outlined above is different than the question raised by Janino. Update: the strategy outlined above is verified to work in a GraalVM native-image, at least in simple scenarios. |
|
@wilkinsona As of commit c440e08b, logback supports loading a model configuration file without ever loading JoranConfigurator and without including java.xml in a native image. I have verified this to work with GraalVM. |
|
That sounds great. Thanks, @ceki. Are Logback snapshots published anywhere? I'd like to give the new serialisation support a try and see if we can rip out the stuff that I wrote. |
|
@wilkinsona Logback snapshots are not published. You would need to check out from github source and build at your end using the JDK 11+ and Maven. I will be documenting the procedure for using serialized model (SMO) files shortly. The only "tricky" part is to remember to add Please note this is still work in progress. More testing is required before public release. Just fixed a silly bug this morning (24th of June). |
|
Hey, did the use of <?xml version="1.0" encoding="UTF-8"?>
<configuration debug="false">
<serializeModel file="src/main/resources/logback.scmo"/>
<include resource="org/springframework/boot/logging/logback/defaults.xml"/>
<include resource="org/springframework/boot/logging/logback/console-appender.xml"/>
<property name="LOGGING_LEVEL" value="${LOGGING_LEVEL:-INFO}"/>
<property name="CONSOLE_LOG_THRESHOLD" value="${CONSOLE_LOG_THRESHOLD:-INFO}"/>
<springProfile name="!dev">
<if condition='p("LOGGING_LAYOUT").toUpperCase().equals("TEXT")'>
<then>
<!-- use the default TEXT layout -->
</then>
<else>
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>${CONSOLE_LOG_THRESHOLD}</level>
</filter>
</appender>
<logger name="reactor.netty.http.server.AccessLog" level="INFO" additivity="false">
<appender-ref ref="CONSOLE"/>
</logger>
</else>
</if>
</springProfile>
<root level="${LOGGING_LEVEL}">
<appender-ref ref="CONSOLE"/>
</root>
</configuration>1- When not using 2- While when using the This error comes from HardenedModelInputStream hmis = new HardenedModelInputStream(is);
Model model = (Model) hmis.readObject();I cannot figure out if there is something wrong in my native configuration, or if it's related to |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
would it work if logback supported condition in a simple predicate class instead of compiling expressions on the fly with janino? |
|
@guai Sounds like a good idea. I encourage you to file an issue with the logback project. |
|
@gdrouet FYI, logback-tyler already translates janono-expressions into Java. It seems to me that the output generated logbaclk-tyler is an auto-loadable Configurator and shoulfd be quite suitable for a GraalVM application. Also, the next version of logback-tyler will support PropertiesConfigurator (new in logback 1,5,8) which allows setting logger levels from a properties file. |
|
hey @ceki, first of all: thanks for all your great work on logback-classic and logback-tyler. I just gave it a try and quickly found that the following requirement is not met in case of Spring Boot Applications:
I tried using version <?xml version="1.0" encoding="UTF-8"?>
<configuration>
<springProperty scope="context" name="consoleEnabled" source="logging.console.enabled"/>
<if condition='${consoleEnabled}'>
<then>
<include resource="logback-console-appender.xml"/>
<root level="info">
<appender-ref ref="CONSOLE"/>
</root>
</then>
</if>
</configuration>This is the resulting code from logback-tyler (which does not compile): @Override
public Configurator.ExecutionStatus configure(LoggerContext loggerContext) {
setContext(loggerContext);
if(${consoleEnabled}) { // <-------- 1. issue: broken if condition
IncludeModel includeModel = new IncludeModel();
includeModel.setResource(subst("logback-console-appender.xml"));
IncludeModelHandler includeModelHandler = new IncludeModelHandler(context);
try {
Model modelFromIncludedFile = includeModelHandler.buildModelFromIncludedFile(this, includeModel);
processModelFromIncludedFile(modelFromIncludedFile);
} catch(ModelHandlerException e) {
addError("Failed to process IncludeModelHandler", e);
}
Logger logger_ROOT = setupLogger("ROOT", "info", null);
logger_ROOT.addAppender(appenderCONSOLE); // <-------- 2. issue: broken appender reference
}
return ExecutionStatus.DO_NOT_INVOKE_NEXT_IF_ANY;
}
Also, the logback-tyler readme claims that:
However, IncludeModel includeModel = new IncludeModel();
includeModel.setResource(subst("logback-console-appender.xml"));
IncludeModelHandler includeModelHandler = new IncludeModelHandler(context);
try {
Model modelFromIncludedFile = includeModelHandler.buildModelFromIncludedFile(this, includeModel);
processModelFromIncludedFile(modelFromIncludedFile);
} catch(ModelHandlerException e) {
addError("Failed to process IncludeModelHandler", e);
}To me it seems like |
|
@DarkAtra Since the issue you describe is mostly logback-tyler related, would you mind creating a new issue in the logback project? Note at translation time logback-tyler usually does not have access to the included file. Thus, it should not be expected to translate the included file. The translation that logback-tyler produces currently seems likely to work at runtime when |
sure, here they are:
|
When building a native image with Spring Boot Maven plugin, Logback configuration relying on Janino leads to an error.
For instance, if we add to the
logback-spring.xmlfile the following if statement:Then running a native image lead to this error:
Note that a fat-jar run with
-Dspring.aot.enabled=truedoes not help to reproduce the issue.It would be great to have such support for native image.
The text was updated successfully, but these errors were encountered: