Ralph, any objection to making the write methods public? Sent from my iPhone
> On 2016/06/16, at 9:05, Leon Finker <leon...@gmail.com> wrote: > > As I remember they are not visible (protected). >> On Jun 15, 2016 7:59 PM, "Remko Popma" <remko.po...@gmail.com> wrote: >> >> I would not use the drain(ByteBuffer) method directly because it would >> cause that message to appear in the log file ahead of the messages that are >> currently in the buffer but haven't been flushed yet. >> >> Have you looked at the parent OutputStreamManager class? >> Why not use one of the write(byte[], ...) methods? They correctly append >> to any existing messages. >> >> Remko >> >> Sent from my iPhone >> >>> On 2016/06/16, at 2:40, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>> >>> Yes, the drain method should write whatever is in the ByteBuffer to the >> file. >>> >>> Ralph >>> >>>> On Jun 15, 2016, at 9:34 AM, Leon Finker <leon...@gmail.com> wrote: >>>> >>>> An option to roll even empty files would be great. Because in our case >> we always want to roll the previous log file. >>>> >>>>> Actually, the triggering policy could write to the file since it has >> access to the Manager. >>>> >>>> I've looked through all the possible methods on RollingFileManager and >> nothing jumped out that allows us to write to the log file. I only see >> drain(ByteBuffer), is that the one to use? Writing from triggering policy >> seems to be the easiest way in our case. >>>> >>>>> On 2016-06-15 12:25 (-0400), Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >>>>> I can add an option to the OnStartupTriggeringPolicy to only roll if >> the file meets or exceeds a minimum value. The default would be 1 byte. >>>>> >>>>> Also, I believe I introduced another bug. The file is now going to >> roll every time a reconfiguration takes place, which is obviously >> incorrect. I need to fix that asap. >>>>> >>>>> The PatternLayout does not support interpolation of the header and >> footer but the Configuration does. All attributes are interpolated as the >> configuration is read. You could create your own custom Lookup to get the >> processId, but that may be something we should add to the standard set of >> properties. >>>>> >>>>> Actually, the triggering policy could write to the file since it has >> access to the Manager. >>>>> >>>>> Ralph >>>>> >>>>> >>>>> >>>>>> On Jun 15, 2016, at 8:17 AM, Leon Finker <leon...@gmail.com> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> What would be the best way to implement the following: >>>>>> 1. Always roll log file once on JVM startup (and only on JVM >> startup). - This could be done with implementing another >> OnStartupTriggeringPolicy (the one from 2.6.1+ doesn't roll empty files >> anymore). >>>>>> 2. Log an entry in the new log file (after the roll) with something >> like: >>>>>> Constants.LINE_SEPARATOR + "---------- " + DateTime.now() + " >> STARTING " + service_instance_Name + " " + getProcessId() + " ----------" >>>>>> - Does PatternLayout's header support system property lookup >> variables (i.e.: service instance name and date time now)? >>>>>> - Not sure how to allow for custom method call to get the >> getProcessId() into the header >>>>>> - It could've been easy if I could do it from >> OnStartupTriggeringPolicy, but there is no way to write to the new rolled >> log file from there. >>>>>> >>>>>> Is there a way? >>>>>> >>>>>> Thank you >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>> For additional commands, e-mail: log4j-user-h...@logging.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-user-h...@logging.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
