Add support `maxdays` to DailyLogListener about jpos HOT 7 CLOSED

I don't think it's required, lastModificationTime is good enough.

from jpos.

Would it be ok to have a max-age property, and deleting files with old timestamps?
Difference with RotateLogListener is that e don't have the age (and is not really simple to derive from the name due to the format ability).

Anyway we could do simple patches to DailyLogListener but maybe it would need to be deprecated in favor of something like (Cron|Quartz)RoteateLogListener based on quartz or something similar like cron4j.

from jpos.

We have a quartz module in jPOS-EE, works great, but I'd like to keep it there and not add it to jPOS. Perhaps it's easier to deal with a copies and just keep the most recent n copies, like we do with RotateLogListener. For max-age I think we need to rely on the operating system to give us the creation date, if we can get that accurately across OSs, then I'm fine too. We'll have to experiment a bit.

from jpos.

from jpos.

Sure. Appreciate that. Wonder if we want to go with modification date. On a second thought, I talked about creation date, but modification date is good too, if for some reason an operator has edited the file, it might just mean she wants to keep it for a little longer, so no harm keeping it.

from jpos.

I tend to overthink, but would it be worthy to add an option to select the modification or creation date usage?

I don't know if all OSs have record of the two dates. At least it seems linux does not and the Basic File class only provides lastModificationTime, we could use java.nio.file.attribute and use the creationTime but at least in some basic testing I did in my machine it returns the same for the two attributes.

So I don't know if it worthy the extra code to obtain that attributes from the java.nio.file package.

from jpos.

This has been implemented in PR181 (#181). Property is actually called maxage.

from jpos.