log4j config needs update

[wcooley]

I just ran into a full file system due to rundeck/rundeck#1175, which is fixed upstream and included in the latest RPM, but lost due to the template overwriting it. The easy solution is to just update the template with this and other changes from the upstream but this will likely be a problem again in the future and, in general, continues to limit users' flexibility.

Before I start coding anything, I would like to propose several options:

1. Just update the damn template and move on
2. Add a parameter to override the log4j template
3. Add a parameter to disable managing the log4j file altogether and let the user do it on his own if necessary.
4. Switch to a more granular way of managing the file, using ini_setting or augeas resources, and not disturb the stock config more than necessary.

Option 4 is my preference, encapsulating with a defined type. (I would probably use ini_setting, since that's already in use and people are generally more comfortable with that.)

[jyaworski]

@wcooley option 4 is also my preference. However, would a template override be the most straightforward way to do this?

[wcooley]

@jyaworski The template override would be the easiest, although I generally prefer to edit package-installed files rather than replace -- that way, if improvements are made upstream, you can get them automatically (depending on how they're packaged).

Rather than re-inventing log4j management, however, it might be worth looking into danielgil/log4j to see if it fits.

(When I first posted this, I was intending to implement this myself, but my role has changed at work making Puppet no longer my immediate duty, so I rescind that intention.)

[jyaworski]

@wcooley all right. I'm not entirely familiar with log4j, but I think I can refactor it to produce the same output at the very least.

I agree with the use of an upstream module, but we need to find out what the most common log4j solution is. I'm hesitant to introduce dependencies when I don't need to.

I may look at this.

[dalisch]

Proposed solution: #161, @jyaworski , your solution I believe is more elegant, but this may be a bit less intrusive to address @liamjbennett 's concerns, even if it is an intermediate solution.

[igalic]

thank y'all! i'll close this issue for now