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
>
>

Reply via email to