A developer posted the following question
Logback is our current choice of a logging framework; however, technologies evolve over time and this may change in the future. For example, log4j 2 seems to be a promising alternative and a further improvement over logback. To this end, it would be great if Apprenda did not restrict the choice of logging frameworks (or other libraries) used by the web applications, while still providing ability to view the logs via a convenient web interface. I imagine this could be achieved if applications were allowed to configure logging into a particular local directory that would be accessible via the log browser?
In 5.5.1, Apprenda will not restrict the type of logging framework that the application wants to use. The application can use whatever it chooses for logging. However, in 5.5.1, Apprenda would not do anything special for any framework , other than log4j. The platform provides the operator with the ability to write Bootstrap policies that can set up facilities similar to our log4j “centralized logging” approach – e.g. if the platform operator wants to have better support for logback, they can write a BSP that wires in appenders that put log files on a file share. You would also have the option to forward the logs from the “other” logging framework to the SOC (e.g. using log4j as a backend (binding) or directly using the guest app logging API).
Specifically for logback, there is no “out of the box” way to configure it to send its log entries to log4j as a backend solution. Logback is intended to be a “successor” to log4j, and thus makes zero effort to interoperate back with log4j, their only approach to working with log4j is “move away from it to logback”.
Other logging frameworks (e.g. such as slf4j) allow to be configured with a log4j backend that would automatically send the events to log4j.
Over time, and as needed by clients, we might support more frameworks; however, at this time log4j is the only one that we treat specially.