Can We Bridge JUL to Log4j in MIT App Inventor?

Hi everyone,

I'm working on the MIT App Inventor project and need some guidance regarding logging. Specifically, I'm trying to bridge java.util.logging (JUL) to Log4j for better log management and configuration.

Is it possible to integrate a JUL to Log4j bridge in the current MIT App Inventor setup? If so, could someone provide detailed steps or advice on how to implement it effectively?
do we need both:

  • jul-to-slf4j for redirecting JUL logs to SLF4J.
  • slf4j-log4j12 for connecting SLF4J with Log4j.

Any help or pointers would be greatly appreciated!

Thanks in advance!

You may have noticed i have changed the category of your last three topics to "Open Source Development" - which is the correct category for your questions.

Please select the correct category for your topic questions in future.

1 Like

What are you trying to accomplish? Generally I don't see a reason to reroute the standard logging stuff through log4j at this time.

I am trying to unify the logging system within the project. Currently, I see that java.util.logging (JUL) logs are being generated alongside Log4j logs. This creates inconsistency in the log management, formatting, and output. By bridging JUL to Log4j, I aim to ensure that all logs—regardless of their source—are handled by Log4j.

Current Logs:

The current logs mix JUL and Log4j, making them less readable and harder to interpret:

17-12-2024 03:02:02,128 DEBUG [org.keyczar.Crypter.decrypt:104] - Decrypting 89 bytes.
17-12-2024 03:02:03,461 DEBUG [org.keyczar.Crypter.decrypt:104] - Decrypting 89 bytes.
Dec 17, 2024 3:02:17 AM com.google.appengine.api.datastore.dev.LocalDatastoreService$11 run
INFO: Time to persist datastore: 9 ms

Current log4j.properties Configuration:

log4j.properties file with the following configuration:

# Set the root logger to TRACE and output to console (A1)
log4j.rootLogger=TRACE, A1

# Console appender configuration
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout

# Adjust the log pattern to include file name, method, and line number
log4j.appender.A1.layout.ConversionPattern=%d{dd-MM-yyyy HH:mm:ss,SSS} %-5p [%c.%M:%L] - %m%n

Despite this, JUL logs are not adhering to the above pattern, as seen in the output. This inconsistency undermines the utility of Log4j's configuration.

Why Bridge JUL to Log4j?

By bridging JUL to Log4j, I aim to:

  1. Centralize Log Management: Ensure all logs, including those from java.util.logging, adhere to the configurations defined in log4j.properties.
  2. Improve Readability: Unified and structured logs will make debugging easier.
  3. Simplify Configuration: Managing one logging framework (Log4j) is less error-prone than maintaining separate configurations for both Log4j and JUL.

If there’s no strong reason to keep JUL separate, bridging it to Log4j seems like the better approach for consistency and maintainability.

Would you agree with this approach, or is there any better way to see the logs so it gives me idea related debugging and code.please guide me.

I guess that makes sense. Just be aware that there are four separate platforms this is running on so in reality the logs you are looking at are only for the code under appengine/src/.../server. The log4j logging is mainly coming from the dev server itself (although I think the Keyczar library does use log4j. It might be better to have log4j go to JUL rather than the other way round).

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.