Logback in Hippo

[Brian Snijders]

Hi all!

I'm currently replacing Log4J with Logback in Hippo to automatically reload live logging configuration, have better rolling appenders and automatic log compression etc.

All seems well, however the master POM declares a hard dependency in the cargo.run-profile, including Log4J in the shared classpath by default, not allowing you to actually remove this dependency and have duplicate loggers etc.

To me, this is not the right place to include this dependency if (and you do) you're using SLF4J as a logging facade framework. SLF4J literally is a logging facade, but including a hard dependency on a logging implementation makes it hard to plug your own favorite logging framework behind that facade.

In my opinion, this can easily be solved by including Log4J in the archetype generated project, instead of the core product POM's. Then, you can easily strip the logging framework from Cargo (as a step 1, with Cargo logging nothing) and next inject Logback or any other framework.

I'm now plugging Logback by overruling the entire cargo.run profile, aggregated over release and project POM's, replacing Log4J by Logback.

WDYT?

Kind regards,

Brian

--

Brian Snijders
Consultant online

e:  brian.s...@incentro.com
t:  +31102020544
m:  +31645540083
w:  www.incentro.com

rotterdam office | van nelle ontwerpfabriek

van nelleweg 2429  |  3044 bc  |  rotterdam

[Brian Snijders]

Hi guys,

Following up on my post :)... I've got Logback installed and operational. The only downside is that the /logging/-servlet for runtime log management *fails* because apparently it can only control Log4J or JDK implementations. It shouldn't be too hard to extend this, but I'm "worrying" a bit if this is to go to OnDemand later on. I know you guys use the /logging/ servlet for inspection when errors occur in OnDemand. I'm happy to patch the logging servlet for Logback control, given that this is acceptable for OnDemand (by means of a code audit).

Kind regards,

Brian

[Jasper Floor]

Hi,

very nice improvement. 

On Tue, Jul 26, 2016 at 9:30 AM, Brian Snijders <brian.s...@incentro.com> wrote:

Hi guys,

Following up on my post :)... I've got Logback installed and operational. The only downside is that the /logging/-servlet for runtime log management *fails* because apparently it can only control Log4J or JDK implementations. It shouldn't be too hard to extend this, but I'm "worrying" a bit if this is to go to OnDemand later on. I know you guys use the /logging/ servlet for inspection when errors occur in OnDemand. I'm happy to patch the logging servlet for Logback control, given that this is acceptable for OnDemand (by means of a code audit).

This is not something I can comment on with any authority, but for on demand it is best to discuss this through official channels. For OnDemand the logging servlet is the only way to access the logs without bothering Infra. So it would certainly be necessary to fix the servlet. 

mvg,

Jasper

 

Kind regards,

Brian

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-c...@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-communi...@googlegroups.com.
Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

[Brian Snijders]

Hi Jasper,

The default LoggingServlet contains private utility methods, which I need access to to override them for Logback compatibility. I've created a full copy-paste in 'nl.xyz.repository.LoggingServlet' in which I've set the methods-to-be-overridden as protected. Next, I've created a Logback compatible implementation, by extending from this class and overriding accordingly. The reason I did this is that in case of an upgrade, we only need to replace nl.xyz.LoggingServlet with the latest and greatest LoggingServlet from the core, keeping Logback customizations separate from the default implementation.

However, an even better suggestion would be to include this in Hippo's Core:

private void setLoggerLevel(...) becomes protected void setLoggerLevel(...)

private SortedMap<String, String> getLoggerLevelMap() becomes protected SortedMap<String, String> getLoggerLevelMap()

private void printChangeLevelForm(...) becomes protected void printChangeLevelForm(...)

Just my 2 cents,

Brian