That would be nice. Also, I confirmed and drain(ByteBuffer) works in my case. On Jun 15, 2016 8:24 PM, "Remko Popma" <remko.po...@gmail.com> wrote:
> 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 > >
