You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Tim Perry <ti...@gmail.com> on 2021/04/19 19:17:28 UTC
Re: What is going on with Master?
I rewrote this to shut down listeners based on the contextName. In testing,
I discovered that the StatusConsoleListener is created in
StatusConfiguration, but neither StatusConfiguration nor
StatusConsoleListener receive events to indicate when they should stop.
It appears that only one StatusConsoleListener object is ever created and
it is never shut down. Looking at the api XmlConfiguration, it calls
StatusConfiguration.initilize() which then either changes the log level to
match the config being parsed or creates a new StatusLogger directed to the
file indicated in the XML configuration. Unless I'm reading the code wrong,
this means that the status logger output location depends on if a previous
app was loaded. If so, then that location will continue to receive
StatusLogger messages but at the log level of the new application's config.
Am I reading this correctly? If I am, is this the intended behaviour?
On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <bo...@gmail.com> wrote:
> The StatusLogger has various listeners attached. I think adding and
> removing listeners on startup and shutdown of a LoggerContext might be
> a potential way to do this?
>
> On Wed, 24 Feb 2021 at 01:07, Tim Perry <ti...@gmail.com> wrote:
> >
> > Ralph,
> >
> > Thanks for the review. Yep, that *is* a problem...I knew it was a
> singleton
> > but didn't think through the use case you describe. This is ironic since
> a
> > few months ago I recommended that one of my clients bundle log4j in each
> > war rather than on Tomcat's classpath so there would be less chance of
> > instances walking on each other. Sigh.
> >
> >
> > What is the correct behaviour if:
> >
> > - log4j is on Tomcat's classpath
> > - App A has status_A.log
> > - App B has status_B.log
> >
> > Now assume both apps are started. At this point I assume we should be
> > writing to both status_A.log and status_B.log. Now we stop App B. I
> assume
> > we should stop writing to status_B.log but not status_A.log. Further, I
> > assume that if both apps are unloaded from Tomcat, but Tomcat is left
> > running, then the status logger should send its messages to standard out.
> > If my assumptions are correct, then maybe we need to keep track of what
> > file, if any, each web app requested messages to be written to. On top of
> > that, I think we need a Callback in Log4j's shutdown registry and we need
> > to run it last.
> >
> >
> > In some ways this seems like an XY problem. Is the correct question how
> do
> > we reconfigure the logging when a web app shuts down? Or should it be:
> > should the StatusLogger be shared across multiple LoggerContexts?
> >
> >
> > This will be more interesting than I first realized!
> >
> > Tim
> >
> >
> > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <ralph.goers@dslextreme.com
> >
> > wrote:
> >
> > > Yeah, I started a review but then I thought it probably would be
> better to
> > > respond here.
> > >
> > > You are on the right track but there is a problem. StatusLogger is a
> > > singleton - there is one instance anchored in a static. You are
> invoking
> > > the shutdown logic from the shutdown of the LoggerContext which is not
> a
> > > singleton. Log4j supports multiple LoggerContexts in an application.
> For
> > > example, if you are old school and running multiple web applications in
> > > Tomcat and have Log4j on Tomcat’s class path then you will have
> multiple
> > > LoggerContexts with a single StatusLogger. So if one web app gets
> > > redeployed then its LoggerContext will be shutdown and a new one
> created
> > > all while another app is continuing to run.
> > >
> > > If you’ll notice the StatusConfiguration class in log4j-core tries to
> > > accommodate for this during startup, but it doesn’t do anything at
> > > shutdown. StatusLogger currently isn’t smart enough to handle one app
> > > writing to one destination and a different on writing to a different
> one.
> > > Since StatusLogger is a singleton it can’t really know which app a
> status
> > > log event is for.
> > >
> > > There are a couple of ways I can think of to handle this but none of
> them
> > > is perfect.
> > > Modify StatusConfiguration to keep track of what each
> StatusConfiguration
> > > set up and reset to whatever the prior StatusConfiguration had. The
> problem
> > > with this is that applications might shutdown in a different order than
> > > they were started, so figuring out what the prior configuration was
> could
> > > be difficult.
> > > Add the call to prepareToStop() as a new Callback to Log4j’s shutdown
> > > registry. However, this callback would need to run last. The shutdown
> > > registry currently doesn’t support a way to specify the order of
> callbacks.
> > > Support for that would need to be added for this to work.
> > >
> > > Ralph
> > >
> > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <ti...@gmail.com> wrote:
> > > >
> > > > Ralph,
> > > >
> > > > I implemented what you suggested. Feel free to suggest improvements.
> > > > https://github.com/apache/logging-log4j2/pull/469
> > > >
> > > > Tim
> > > >
> > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers <
> ralph.goers@dslextreme.com>
> > > > wrote:
> > > >
> > > >> I would suggest that if it is writing to something other than
> System.out
> > > >> that it be redirected back there and then the OutputStream be
> closed.
> > > >> However, I’ve not looked at the code recently so I am not sure what
> it
> > > >> takes to do that.
> > > >>
> > > >> Ralph
> > > >>
> > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <ti...@gmail.com> wrote:
> > > >>>
> > > >>> Thank you, Volkan.
> > > >>>
> > > >>> I'm not quite ready to submit a PR. I was hoping some of you with
> more
> > > >>> knowledge of log4j-core would weigh in on what we should do about
> > > >> shutting
> > > >>> down the StatusLogger.
> > > >>>
> > > >>> My thought is we choose one of two options:
> > > >>>
> > > >>> Option A:
> > > >>> 1) check if any StatusLogger is writing to standard out or standard
> > > >> error.
> > > >>> If not, add one.
> > > >>> 2) stop any loggers that don't write to standard out or standard
> error.
> > > >>>
> > > >>> Option B:
> > > >>> 1) stop any loggers that don't write to standard out or standard
> error.
> > > >>>
> > > >>> Option A could cause the log messages to be split across two
> > > >> destinations,
> > > >>> but they all get sent somewhere. Option B could lose shutdown
> messages
> > > >> when
> > > >>> writing to a file, but by that point it may not matter.
> > > >>>
> > > >>> If any of you have a better idea, I'm happy to implement it. If
> nobody
> > > >>> weighs in on the best option, I'll probably submit Option A as a
> pull
> > > >>> request on Friday or Saturday.
> > > >>>
> > > >>> Tim
> > > >>>
> > > >>
> > > >>
> > > >>
> > >
> > >
>
Re: What is going on with Master?
Posted by Sixx XT <si...@gmail.com>.
I finally with the great help from you and apache.org friends ❤ 🙏 thanks
they killed my credibility
On Mon, Apr 19, 2021, 4:41 PM Tim Perry <ti...@gmail.com> wrote:
> After further thought, I am threading the context name into the location
> where the StatusConfiguration creates the StatusConsoleListener and
> registering the context name there.
>
> In addition, if the new logger would write to a destination other than
> standard out or standard error then I do not reconfigure the existing
> logger in StatusConfiguration.configureExistingStatusConsoleListener(),
> instead I have the
>
> I am now correctly closing the status logger when the context is stopped.
>
> I'll push the changes to github after I do a full build
>
> On Mon, Apr 19, 2021 at 12:17 PM Tim Perry <ti...@gmail.com> wrote:
>
> > I rewrote this to shut down listeners based on the contextName. In
> > testing, I discovered that the StatusConsoleListener is created in
> > StatusConfiguration, but neither StatusConfiguration nor
> > StatusConsoleListener receive events to indicate when they should stop.
> >
> > It appears that only one StatusConsoleListener object is ever created and
> > it is never shut down. Looking at the api XmlConfiguration, it calls
> > StatusConfiguration.initilize() which then either changes the log level
> to
> > match the config being parsed or creates a new StatusLogger directed to
> the
> > file indicated in the XML configuration. Unless I'm reading the code
> wrong,
> > this means that the status logger output location depends on if a
> previous
> > app was loaded. If so, then that location will continue to receive
> > StatusLogger messages but at the log level of the new application's
> config.
> > Am I reading this correctly? If I am, is this the intended behaviour?
> >
> >
> >
> > On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <bo...@gmail.com> wrote:
> >
> >> The StatusLogger has various listeners attached. I think adding and
> >> removing listeners on startup and shutdown of a LoggerContext might be
> >> a potential way to do this?
> >>
> >> On Wed, 24 Feb 2021 at 01:07, Tim Perry <ti...@gmail.com> wrote:
> >> >
> >> > Ralph,
> >> >
> >> > Thanks for the review. Yep, that *is* a problem...I knew it was a
> >> singleton
> >> > but didn't think through the use case you describe. This is ironic
> >> since a
> >> > few months ago I recommended that one of my clients bundle log4j in
> each
> >> > war rather than on Tomcat's classpath so there would be less chance of
> >> > instances walking on each other. Sigh.
> >> >
> >> >
> >> > What is the correct behaviour if:
> >> >
> >> > - log4j is on Tomcat's classpath
> >> > - App A has status_A.log
> >> > - App B has status_B.log
> >> >
> >> > Now assume both apps are started. At this point I assume we should be
> >> > writing to both status_A.log and status_B.log. Now we stop App B. I
> >> assume
> >> > we should stop writing to status_B.log but not status_A.log. Further,
> I
> >> > assume that if both apps are unloaded from Tomcat, but Tomcat is left
> >> > running, then the status logger should send its messages to standard
> >> out.
> >> > If my assumptions are correct, then maybe we need to keep track of
> what
> >> > file, if any, each web app requested messages to be written to. On top
> >> of
> >> > that, I think we need a Callback in Log4j's shutdown registry and we
> >> need
> >> > to run it last.
> >> >
> >> >
> >> > In some ways this seems like an XY problem. Is the correct question
> how
> >> do
> >> > we reconfigure the logging when a web app shuts down? Or should it be:
> >> > should the StatusLogger be shared across multiple LoggerContexts?
> >> >
> >> >
> >> > This will be more interesting than I first realized!
> >> >
> >> > Tim
> >> >
> >> >
> >> > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <
> >> ralph.goers@dslextreme.com>
> >> > wrote:
> >> >
> >> > > Yeah, I started a review but then I thought it probably would be
> >> better to
> >> > > respond here.
> >> > >
> >> > > You are on the right track but there is a problem. StatusLogger is a
> >> > > singleton - there is one instance anchored in a static. You are
> >> invoking
> >> > > the shutdown logic from the shutdown of the LoggerContext which is
> >> not a
> >> > > singleton. Log4j supports multiple LoggerContexts in an application.
> >> For
> >> > > example, if you are old school and running multiple web applications
> >> in
> >> > > Tomcat and have Log4j on Tomcat’s class path then you will have
> >> multiple
> >> > > LoggerContexts with a single StatusLogger. So if one web app gets
> >> > > redeployed then its LoggerContext will be shutdown and a new one
> >> created
> >> > > all while another app is continuing to run.
> >> > >
> >> > > If you’ll notice the StatusConfiguration class in log4j-core tries
> to
> >> > > accommodate for this during startup, but it doesn’t do anything at
> >> > > shutdown. StatusLogger currently isn’t smart enough to handle one
> app
> >> > > writing to one destination and a different on writing to a different
> >> one.
> >> > > Since StatusLogger is a singleton it can’t really know which app a
> >> status
> >> > > log event is for.
> >> > >
> >> > > There are a couple of ways I can think of to handle this but none of
> >> them
> >> > > is perfect.
> >> > > Modify StatusConfiguration to keep track of what each
> >> StatusConfiguration
> >> > > set up and reset to whatever the prior StatusConfiguration had. The
> >> problem
> >> > > with this is that applications might shutdown in a different order
> >> than
> >> > > they were started, so figuring out what the prior configuration was
> >> could
> >> > > be difficult.
> >> > > Add the call to prepareToStop() as a new Callback to Log4j’s
> shutdown
> >> > > registry. However, this callback would need to run last. The
> shutdown
> >> > > registry currently doesn’t support a way to specify the order of
> >> callbacks.
> >> > > Support for that would need to be added for this to work.
> >> > >
> >> > > Ralph
> >> > >
> >> > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <ti...@gmail.com>
> wrote:
> >> > > >
> >> > > > Ralph,
> >> > > >
> >> > > > I implemented what you suggested. Feel free to suggest
> improvements.
> >> > > > https://github.com/apache/logging-log4j2/pull/469
> >> > > >
> >> > > > Tim
> >> > > >
> >> > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers <
> >> ralph.goers@dslextreme.com>
> >> > > > wrote:
> >> > > >
> >> > > >> I would suggest that if it is writing to something other than
> >> System.out
> >> > > >> that it be redirected back there and then the OutputStream be
> >> closed.
> >> > > >> However, I’ve not looked at the code recently so I am not sure
> >> what it
> >> > > >> takes to do that.
> >> > > >>
> >> > > >> Ralph
> >> > > >>
> >> > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <ti...@gmail.com>
> >> wrote:
> >> > > >>>
> >> > > >>> Thank you, Volkan.
> >> > > >>>
> >> > > >>> I'm not quite ready to submit a PR. I was hoping some of you
> with
> >> more
> >> > > >>> knowledge of log4j-core would weigh in on what we should do
> about
> >> > > >> shutting
> >> > > >>> down the StatusLogger.
> >> > > >>>
> >> > > >>> My thought is we choose one of two options:
> >> > > >>>
> >> > > >>> Option A:
> >> > > >>> 1) check if any StatusLogger is writing to standard out or
> >> standard
> >> > > >> error.
> >> > > >>> If not, add one.
> >> > > >>> 2) stop any loggers that don't write to standard out or standard
> >> error.
> >> > > >>>
> >> > > >>> Option B:
> >> > > >>> 1) stop any loggers that don't write to standard out or standard
> >> error.
> >> > > >>>
> >> > > >>> Option A could cause the log messages to be split across two
> >> > > >> destinations,
> >> > > >>> but they all get sent somewhere. Option B could lose shutdown
> >> messages
> >> > > >> when
> >> > > >>> writing to a file, but by that point it may not matter.
> >> > > >>>
> >> > > >>> If any of you have a better idea, I'm happy to implement it. If
> >> nobody
> >> > > >>> weighs in on the best option, I'll probably submit Option A as a
> >> pull
> >> > > >>> request on Friday or Saturday.
> >> > > >>>
> >> > > >>> Tim
> >> > > >>>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > >
> >> > >
> >>
> >
>
Re: What is going on with Master?
Posted by Sixx XT <si...@gmail.com>.
I approve the message and that is permanent apache.org has any time in need
i got u. And I need a job lol
On Mon, Apr 19, 2021, 4:41 PM Tim Perry <ti...@gmail.com> wrote:
> After further thought, I am threading the context name into the location
> where the StatusConfiguration creates the StatusConsoleListener and
> registering the context name there.
>
> In addition, if the new logger would write to a destination other than
> standard out or standard error then I do not reconfigure the existing
> logger in StatusConfiguration.configureExistingStatusConsoleListener(),
> instead I have the
>
> I am now correctly closing the status logger when the context is stopped.
>
> I'll push the changes to github after I do a full build
>
> On Mon, Apr 19, 2021 at 12:17 PM Tim Perry <ti...@gmail.com> wrote:
>
> > I rewrote this to shut down listeners based on the contextName. In
> > testing, I discovered that the StatusConsoleListener is created in
> > StatusConfiguration, but neither StatusConfiguration nor
> > StatusConsoleListener receive events to indicate when they should stop.
> >
> > It appears that only one StatusConsoleListener object is ever created and
> > it is never shut down. Looking at the api XmlConfiguration, it calls
> > StatusConfiguration.initilize() which then either changes the log level
> to
> > match the config being parsed or creates a new StatusLogger directed to
> the
> > file indicated in the XML configuration. Unless I'm reading the code
> wrong,
> > this means that the status logger output location depends on if a
> previous
> > app was loaded. If so, then that location will continue to receive
> > StatusLogger messages but at the log level of the new application's
> config.
> > Am I reading this correctly? If I am, is this the intended behaviour?
> >
> >
> >
> > On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <bo...@gmail.com> wrote:
> >
> >> The StatusLogger has various listeners attached. I think adding and
> >> removing listeners on startup and shutdown of a LoggerContext might be
> >> a potential way to do this?
> >>
> >> On Wed, 24 Feb 2021 at 01:07, Tim Perry <ti...@gmail.com> wrote:
> >> >
> >> > Ralph,
> >> >
> >> > Thanks for the review. Yep, that *is* a problem...I knew it was a
> >> singleton
> >> > but didn't think through the use case you describe. This is ironic
> >> since a
> >> > few months ago I recommended that one of my clients bundle log4j in
> each
> >> > war rather than on Tomcat's classpath so there would be less chance of
> >> > instances walking on each other. Sigh.
> >> >
> >> >
> >> > What is the correct behaviour if:
> >> >
> >> > - log4j is on Tomcat's classpath
> >> > - App A has status_A.log
> >> > - App B has status_B.log
> >> >
> >> > Now assume both apps are started. At this point I assume we should be
> >> > writing to both status_A.log and status_B.log. Now we stop App B. I
> >> assume
> >> > we should stop writing to status_B.log but not status_A.log. Further,
> I
> >> > assume that if both apps are unloaded from Tomcat, but Tomcat is left
> >> > running, then the status logger should send its messages to standard
> >> out.
> >> > If my assumptions are correct, then maybe we need to keep track of
> what
> >> > file, if any, each web app requested messages to be written to. On top
> >> of
> >> > that, I think we need a Callback in Log4j's shutdown registry and we
> >> need
> >> > to run it last.
> >> >
> >> >
> >> > In some ways this seems like an XY problem. Is the correct question
> how
> >> do
> >> > we reconfigure the logging when a web app shuts down? Or should it be:
> >> > should the StatusLogger be shared across multiple LoggerContexts?
> >> >
> >> >
> >> > This will be more interesting than I first realized!
> >> >
> >> > Tim
> >> >
> >> >
> >> > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <
> >> ralph.goers@dslextreme.com>
> >> > wrote:
> >> >
> >> > > Yeah, I started a review but then I thought it probably would be
> >> better to
> >> > > respond here.
> >> > >
> >> > > You are on the right track but there is a problem. StatusLogger is a
> >> > > singleton - there is one instance anchored in a static. You are
> >> invoking
> >> > > the shutdown logic from the shutdown of the LoggerContext which is
> >> not a
> >> > > singleton. Log4j supports multiple LoggerContexts in an application.
> >> For
> >> > > example, if you are old school and running multiple web applications
> >> in
> >> > > Tomcat and have Log4j on Tomcat’s class path then you will have
> >> multiple
> >> > > LoggerContexts with a single StatusLogger. So if one web app gets
> >> > > redeployed then its LoggerContext will be shutdown and a new one
> >> created
> >> > > all while another app is continuing to run.
> >> > >
> >> > > If you’ll notice the StatusConfiguration class in log4j-core tries
> to
> >> > > accommodate for this during startup, but it doesn’t do anything at
> >> > > shutdown. StatusLogger currently isn’t smart enough to handle one
> app
> >> > > writing to one destination and a different on writing to a different
> >> one.
> >> > > Since StatusLogger is a singleton it can’t really know which app a
> >> status
> >> > > log event is for.
> >> > >
> >> > > There are a couple of ways I can think of to handle this but none of
> >> them
> >> > > is perfect.
> >> > > Modify StatusConfiguration to keep track of what each
> >> StatusConfiguration
> >> > > set up and reset to whatever the prior StatusConfiguration had. The
> >> problem
> >> > > with this is that applications might shutdown in a different order
> >> than
> >> > > they were started, so figuring out what the prior configuration was
> >> could
> >> > > be difficult.
> >> > > Add the call to prepareToStop() as a new Callback to Log4j’s
> shutdown
> >> > > registry. However, this callback would need to run last. The
> shutdown
> >> > > registry currently doesn’t support a way to specify the order of
> >> callbacks.
> >> > > Support for that would need to be added for this to work.
> >> > >
> >> > > Ralph
> >> > >
> >> > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <ti...@gmail.com>
> wrote:
> >> > > >
> >> > > > Ralph,
> >> > > >
> >> > > > I implemented what you suggested. Feel free to suggest
> improvements.
> >> > > > https://github.com/apache/logging-log4j2/pull/469
> >> > > >
> >> > > > Tim
> >> > > >
> >> > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers <
> >> ralph.goers@dslextreme.com>
> >> > > > wrote:
> >> > > >
> >> > > >> I would suggest that if it is writing to something other than
> >> System.out
> >> > > >> that it be redirected back there and then the OutputStream be
> >> closed.
> >> > > >> However, I’ve not looked at the code recently so I am not sure
> >> what it
> >> > > >> takes to do that.
> >> > > >>
> >> > > >> Ralph
> >> > > >>
> >> > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <ti...@gmail.com>
> >> wrote:
> >> > > >>>
> >> > > >>> Thank you, Volkan.
> >> > > >>>
> >> > > >>> I'm not quite ready to submit a PR. I was hoping some of you
> with
> >> more
> >> > > >>> knowledge of log4j-core would weigh in on what we should do
> about
> >> > > >> shutting
> >> > > >>> down the StatusLogger.
> >> > > >>>
> >> > > >>> My thought is we choose one of two options:
> >> > > >>>
> >> > > >>> Option A:
> >> > > >>> 1) check if any StatusLogger is writing to standard out or
> >> standard
> >> > > >> error.
> >> > > >>> If not, add one.
> >> > > >>> 2) stop any loggers that don't write to standard out or standard
> >> error.
> >> > > >>>
> >> > > >>> Option B:
> >> > > >>> 1) stop any loggers that don't write to standard out or standard
> >> error.
> >> > > >>>
> >> > > >>> Option A could cause the log messages to be split across two
> >> > > >> destinations,
> >> > > >>> but they all get sent somewhere. Option B could lose shutdown
> >> messages
> >> > > >> when
> >> > > >>> writing to a file, but by that point it may not matter.
> >> > > >>>
> >> > > >>> If any of you have a better idea, I'm happy to implement it. If
> >> nobody
> >> > > >>> weighs in on the best option, I'll probably submit Option A as a
> >> pull
> >> > > >>> request on Friday or Saturday.
> >> > > >>>
> >> > > >>> Tim
> >> > > >>>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > >
> >> > >
> >>
> >
>
Re: What is going on with Master?
Posted by Sixx XT <si...@gmail.com>.
You will let treyhaziq@gmail.com join again and thank you
On Mon, Apr 19, 2021, 4:41 PM Tim Perry <ti...@gmail.com> wrote:
> After further thought, I am threading the context name into the location
> where the StatusConfiguration creates the StatusConsoleListener and
> registering the context name there.
>
> In addition, if the new logger would write to a destination other than
> standard out or standard error then I do not reconfigure the existing
> logger in StatusConfiguration.configureExistingStatusConsoleListener(),
> instead I have the
>
> I am now correctly closing the status logger when the context is stopped.
>
> I'll push the changes to github after I do a full build
>
> On Mon, Apr 19, 2021 at 12:17 PM Tim Perry <ti...@gmail.com> wrote:
>
> > I rewrote this to shut down listeners based on the contextName. In
> > testing, I discovered that the StatusConsoleListener is created in
> > StatusConfiguration, but neither StatusConfiguration nor
> > StatusConsoleListener receive events to indicate when they should stop.
> >
> > It appears that only one StatusConsoleListener object is ever created and
> > it is never shut down. Looking at the api XmlConfiguration, it calls
> > StatusConfiguration.initilize() which then either changes the log level
> to
> > match the config being parsed or creates a new StatusLogger directed to
> the
> > file indicated in the XML configuration. Unless I'm reading the code
> wrong,
> > this means that the status logger output location depends on if a
> previous
> > app was loaded. If so, then that location will continue to receive
> > StatusLogger messages but at the log level of the new application's
> config.
> > Am I reading this correctly? If I am, is this the intended behaviour?
> >
> >
> >
> > On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <bo...@gmail.com> wrote:
> >
> >> The StatusLogger has various listeners attached. I think adding and
> >> removing listeners on startup and shutdown of a LoggerContext might be
> >> a potential way to do this?
> >>
> >> On Wed, 24 Feb 2021 at 01:07, Tim Perry <ti...@gmail.com> wrote:
> >> >
> >> > Ralph,
> >> >
> >> > Thanks for the review. Yep, that *is* a problem...I knew it was a
> >> singleton
> >> > but didn't think through the use case you describe. This is ironic
> >> since a
> >> > few months ago I recommended that one of my clients bundle log4j in
> each
> >> > war rather than on Tomcat's classpath so there would be less chance of
> >> > instances walking on each other. Sigh.
> >> >
> >> >
> >> > What is the correct behaviour if:
> >> >
> >> > - log4j is on Tomcat's classpath
> >> > - App A has status_A.log
> >> > - App B has status_B.log
> >> >
> >> > Now assume both apps are started. At this point I assume we should be
> >> > writing to both status_A.log and status_B.log. Now we stop App B. I
> >> assume
> >> > we should stop writing to status_B.log but not status_A.log. Further,
> I
> >> > assume that if both apps are unloaded from Tomcat, but Tomcat is left
> >> > running, then the status logger should send its messages to standard
> >> out.
> >> > If my assumptions are correct, then maybe we need to keep track of
> what
> >> > file, if any, each web app requested messages to be written to. On top
> >> of
> >> > that, I think we need a Callback in Log4j's shutdown registry and we
> >> need
> >> > to run it last.
> >> >
> >> >
> >> > In some ways this seems like an XY problem. Is the correct question
> how
> >> do
> >> > we reconfigure the logging when a web app shuts down? Or should it be:
> >> > should the StatusLogger be shared across multiple LoggerContexts?
> >> >
> >> >
> >> > This will be more interesting than I first realized!
> >> >
> >> > Tim
> >> >
> >> >
> >> > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <
> >> ralph.goers@dslextreme.com>
> >> > wrote:
> >> >
> >> > > Yeah, I started a review but then I thought it probably would be
> >> better to
> >> > > respond here.
> >> > >
> >> > > You are on the right track but there is a problem. StatusLogger is a
> >> > > singleton - there is one instance anchored in a static. You are
> >> invoking
> >> > > the shutdown logic from the shutdown of the LoggerContext which is
> >> not a
> >> > > singleton. Log4j supports multiple LoggerContexts in an application.
> >> For
> >> > > example, if you are old school and running multiple web applications
> >> in
> >> > > Tomcat and have Log4j on Tomcat’s class path then you will have
> >> multiple
> >> > > LoggerContexts with a single StatusLogger. So if one web app gets
> >> > > redeployed then its LoggerContext will be shutdown and a new one
> >> created
> >> > > all while another app is continuing to run.
> >> > >
> >> > > If you’ll notice the StatusConfiguration class in log4j-core tries
> to
> >> > > accommodate for this during startup, but it doesn’t do anything at
> >> > > shutdown. StatusLogger currently isn’t smart enough to handle one
> app
> >> > > writing to one destination and a different on writing to a different
> >> one.
> >> > > Since StatusLogger is a singleton it can’t really know which app a
> >> status
> >> > > log event is for.
> >> > >
> >> > > There are a couple of ways I can think of to handle this but none of
> >> them
> >> > > is perfect.
> >> > > Modify StatusConfiguration to keep track of what each
> >> StatusConfiguration
> >> > > set up and reset to whatever the prior StatusConfiguration had. The
> >> problem
> >> > > with this is that applications might shutdown in a different order
> >> than
> >> > > they were started, so figuring out what the prior configuration was
> >> could
> >> > > be difficult.
> >> > > Add the call to prepareToStop() as a new Callback to Log4j’s
> shutdown
> >> > > registry. However, this callback would need to run last. The
> shutdown
> >> > > registry currently doesn’t support a way to specify the order of
> >> callbacks.
> >> > > Support for that would need to be added for this to work.
> >> > >
> >> > > Ralph
> >> > >
> >> > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <ti...@gmail.com>
> wrote:
> >> > > >
> >> > > > Ralph,
> >> > > >
> >> > > > I implemented what you suggested. Feel free to suggest
> improvements.
> >> > > > https://github.com/apache/logging-log4j2/pull/469
> >> > > >
> >> > > > Tim
> >> > > >
> >> > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers <
> >> ralph.goers@dslextreme.com>
> >> > > > wrote:
> >> > > >
> >> > > >> I would suggest that if it is writing to something other than
> >> System.out
> >> > > >> that it be redirected back there and then the OutputStream be
> >> closed.
> >> > > >> However, I’ve not looked at the code recently so I am not sure
> >> what it
> >> > > >> takes to do that.
> >> > > >>
> >> > > >> Ralph
> >> > > >>
> >> > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <ti...@gmail.com>
> >> wrote:
> >> > > >>>
> >> > > >>> Thank you, Volkan.
> >> > > >>>
> >> > > >>> I'm not quite ready to submit a PR. I was hoping some of you
> with
> >> more
> >> > > >>> knowledge of log4j-core would weigh in on what we should do
> about
> >> > > >> shutting
> >> > > >>> down the StatusLogger.
> >> > > >>>
> >> > > >>> My thought is we choose one of two options:
> >> > > >>>
> >> > > >>> Option A:
> >> > > >>> 1) check if any StatusLogger is writing to standard out or
> >> standard
> >> > > >> error.
> >> > > >>> If not, add one.
> >> > > >>> 2) stop any loggers that don't write to standard out or standard
> >> error.
> >> > > >>>
> >> > > >>> Option B:
> >> > > >>> 1) stop any loggers that don't write to standard out or standard
> >> error.
> >> > > >>>
> >> > > >>> Option A could cause the log messages to be split across two
> >> > > >> destinations,
> >> > > >>> but they all get sent somewhere. Option B could lose shutdown
> >> messages
> >> > > >> when
> >> > > >>> writing to a file, but by that point it may not matter.
> >> > > >>>
> >> > > >>> If any of you have a better idea, I'm happy to implement it. If
> >> nobody
> >> > > >>> weighs in on the best option, I'll probably submit Option A as a
> >> pull
> >> > > >>> request on Friday or Saturday.
> >> > > >>>
> >> > > >>> Tim
> >> > > >>>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > >
> >> > >
> >>
> >
>
Re: What is going on with Master?
Posted by Remko Popma <re...@gmail.com>.
No it’s fine you can stay.
“Ban me i can't get him off she'll” is just pure poetry. More please. :-)
> On Apr 20, 2021, at 10:03, Sixx XT <si...@gmail.com> wrote:
>
> Ban me i can't get him off she'll
Re: What is going on with Master?
Posted by Sixx XT <si...@gmail.com>.
Ban me i can't get him off she'll
On Mon, Apr 19, 2021, 9:01 PM Remko Popma <re...@gmail.com> wrote:
> Sixx XT appears to be a robot.
> Ban?
>
> Sixx XT, you can redeem yourself with an intelligent response to this
> message.
>
> On Tue, Apr 20, 2021 at 6:04 Sixx XT <si...@gmail.com> wrote:
>
> > They figured it out through the drive the guy that was hacking me and
> stole
> > my dev in 2016 Oct yyyy is under apache 2.2
> >
> > On Mon, Apr 19, 2021, 4:53 PM Sixx XT <si...@gmail.com> wrote:
> >
> > > Look out for dup() files
> > >
> > > On Mon, Apr 19, 2021, 4:52 PM Sixx XT <si...@gmail.com> wrote:
> > >
> > >> Thank you im sorry when I find a job ill pay u
> > >>
> > >> On Mon, Apr 19, 2021, 4:48 PM Sixx XT <si...@gmail.com> wrote:
> > >>
> > >>> Do I need to disable drive
> > >>>
> > >>> On Mon, Apr 19, 2021, 4:41 PM Tim Perry <ti...@gmail.com> wrote:
> > >>>
> > >>>> After further thought, I am threading the context name into the
> > location
> > >>>> where the StatusConfiguration creates the StatusConsoleListener and
> > >>>> registering the context name there.
> > >>>>
> > >>>> In addition, if the new logger would write to a destination other
> than
> > >>>> standard out or standard error then I do not reconfigure the
> existing
> > >>>> logger in
> > StatusConfiguration.configureExistingStatusConsoleListener(),
> > >>>> instead I have the
> > >>>>
> > >>>> I am now correctly closing the status logger when the context is
> > >>>> stopped.
> > >>>>
> > >>>> I'll push the changes to github after I do a full build
> > >>>>
> > >>>> On Mon, Apr 19, 2021 at 12:17 PM Tim Perry <ti...@gmail.com>
> > wrote:
> > >>>>
> > >>>> > I rewrote this to shut down listeners based on the contextName. In
> > >>>> > testing, I discovered that the StatusConsoleListener is created in
> > >>>> > StatusConfiguration, but neither StatusConfiguration nor
> > >>>> > StatusConsoleListener receive events to indicate when they should
> > >>>> stop.
> > >>>> >
> > >>>> > It appears that only one StatusConsoleListener object is ever
> > created
> > >>>> and
> > >>>> > it is never shut down. Looking at the api XmlConfiguration, it
> calls
> > >>>> > StatusConfiguration.initilize() which then either changes the log
> > >>>> level to
> > >>>> > match the config being parsed or creates a new StatusLogger
> directed
> > >>>> to the
> > >>>> > file indicated in the XML configuration. Unless I'm reading the
> code
> > >>>> wrong,
> > >>>> > this means that the status logger output location depends on if a
> > >>>> previous
> > >>>> > app was loaded. If so, then that location will continue to receive
> > >>>> > StatusLogger messages but at the log level of the new
> application's
> > >>>> config.
> > >>>> > Am I reading this correctly? If I am, is this the intended
> > behaviour?
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> > On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <bo...@gmail.com>
> > wrote:
> > >>>> >
> > >>>> >> The StatusLogger has various listeners attached. I think adding
> and
> > >>>> >> removing listeners on startup and shutdown of a LoggerContext
> might
> > >>>> be
> > >>>> >> a potential way to do this?
> > >>>> >>
> > >>>> >> On Wed, 24 Feb 2021 at 01:07, Tim Perry <ti...@gmail.com>
> > wrote:
> > >>>> >> >
> > >>>> >> > Ralph,
> > >>>> >> >
> > >>>> >> > Thanks for the review. Yep, that *is* a problem...I knew it
> was a
> > >>>> >> singleton
> > >>>> >> > but didn't think through the use case you describe. This is
> > ironic
> > >>>> >> since a
> > >>>> >> > few months ago I recommended that one of my clients bundle
> log4j
> > >>>> in each
> > >>>> >> > war rather than on Tomcat's classpath so there would be less
> > >>>> chance of
> > >>>> >> > instances walking on each other. Sigh.
> > >>>> >> >
> > >>>> >> >
> > >>>> >> > What is the correct behaviour if:
> > >>>> >> >
> > >>>> >> > - log4j is on Tomcat's classpath
> > >>>> >> > - App A has status_A.log
> > >>>> >> > - App B has status_B.log
> > >>>> >> >
> > >>>> >> > Now assume both apps are started. At this point I assume we
> > should
> > >>>> be
> > >>>> >> > writing to both status_A.log and status_B.log. Now we stop App
> > B. I
> > >>>> >> assume
> > >>>> >> > we should stop writing to status_B.log but not status_A.log.
> > >>>> Further, I
> > >>>> >> > assume that if both apps are unloaded from Tomcat, but Tomcat
> is
> > >>>> left
> > >>>> >> > running, then the status logger should send its messages to
> > >>>> standard
> > >>>> >> out.
> > >>>> >> > If my assumptions are correct, then maybe we need to keep track
> > of
> > >>>> what
> > >>>> >> > file, if any, each web app requested messages to be written to.
> > On
> > >>>> top
> > >>>> >> of
> > >>>> >> > that, I think we need a Callback in Log4j's shutdown registry
> and
> > >>>> we
> > >>>> >> need
> > >>>> >> > to run it last.
> > >>>> >> >
> > >>>> >> >
> > >>>> >> > In some ways this seems like an XY problem. Is the correct
> > >>>> question how
> > >>>> >> do
> > >>>> >> > we reconfigure the logging when a web app shuts down? Or should
> > it
> > >>>> be:
> > >>>> >> > should the StatusLogger be shared across multiple
> LoggerContexts?
> > >>>> >> >
> > >>>> >> >
> > >>>> >> > This will be more interesting than I first realized!
> > >>>> >> >
> > >>>> >> > Tim
> > >>>> >> >
> > >>>> >> >
> > >>>> >> > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <
> > >>>> >> ralph.goers@dslextreme.com>
> > >>>> >> > wrote:
> > >>>> >> >
> > >>>> >> > > Yeah, I started a review but then I thought it probably would
> > be
> > >>>> >> better to
> > >>>> >> > > respond here.
> > >>>> >> > >
> > >>>> >> > > You are on the right track but there is a problem.
> StatusLogger
> > >>>> is a
> > >>>> >> > > singleton - there is one instance anchored in a static. You
> are
> > >>>> >> invoking
> > >>>> >> > > the shutdown logic from the shutdown of the LoggerContext
> which
> > >>>> is
> > >>>> >> not a
> > >>>> >> > > singleton. Log4j supports multiple LoggerContexts in an
> > >>>> application.
> > >>>> >> For
> > >>>> >> > > example, if you are old school and running multiple web
> > >>>> applications
> > >>>> >> in
> > >>>> >> > > Tomcat and have Log4j on Tomcat’s class path then you will
> have
> > >>>> >> multiple
> > >>>> >> > > LoggerContexts with a single StatusLogger. So if one web app
> > gets
> > >>>> >> > > redeployed then its LoggerContext will be shutdown and a new
> > one
> > >>>> >> created
> > >>>> >> > > all while another app is continuing to run.
> > >>>> >> > >
> > >>>> >> > > If you’ll notice the StatusConfiguration class in log4j-core
> > >>>> tries to
> > >>>> >> > > accommodate for this during startup, but it doesn’t do
> anything
> > >>>> at
> > >>>> >> > > shutdown. StatusLogger currently isn’t smart enough to handle
> > >>>> one app
> > >>>> >> > > writing to one destination and a different on writing to a
> > >>>> different
> > >>>> >> one.
> > >>>> >> > > Since StatusLogger is a singleton it can’t really know which
> > app
> > >>>> a
> > >>>> >> status
> > >>>> >> > > log event is for.
> > >>>> >> > >
> > >>>> >> > > There are a couple of ways I can think of to handle this but
> > >>>> none of
> > >>>> >> them
> > >>>> >> > > is perfect.
> > >>>> >> > > Modify StatusConfiguration to keep track of what each
> > >>>> >> StatusConfiguration
> > >>>> >> > > set up and reset to whatever the prior StatusConfiguration
> had.
> > >>>> The
> > >>>> >> problem
> > >>>> >> > > with this is that applications might shutdown in a different
> > >>>> order
> > >>>> >> than
> > >>>> >> > > they were started, so figuring out what the prior
> configuration
> > >>>> was
> > >>>> >> could
> > >>>> >> > > be difficult.
> > >>>> >> > > Add the call to prepareToStop() as a new Callback to Log4j’s
> > >>>> shutdown
> > >>>> >> > > registry. However, this callback would need to run last. The
> > >>>> shutdown
> > >>>> >> > > registry currently doesn’t support a way to specify the order
> > of
> > >>>> >> callbacks.
> > >>>> >> > > Support for that would need to be added for this to work.
> > >>>> >> > >
> > >>>> >> > > Ralph
> > >>>> >> > >
> > >>>> >> > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <
> tim.v2.0@gmail.com>
> > >>>> wrote:
> > >>>> >> > > >
> > >>>> >> > > > Ralph,
> > >>>> >> > > >
> > >>>> >> > > > I implemented what you suggested. Feel free to suggest
> > >>>> improvements.
> > >>>> >> > > > https://github.com/apache/logging-log4j2/pull/469
> > >>>> >> > > >
> > >>>> >> > > > Tim
> > >>>> >> > > >
> > >>>> >> > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers <
> > >>>> >> ralph.goers@dslextreme.com>
> > >>>> >> > > > wrote:
> > >>>> >> > > >
> > >>>> >> > > >> I would suggest that if it is writing to something other
> > than
> > >>>> >> System.out
> > >>>> >> > > >> that it be redirected back there and then the OutputStream
> > be
> > >>>> >> closed.
> > >>>> >> > > >> However, I’ve not looked at the code recently so I am not
> > sure
> > >>>> >> what it
> > >>>> >> > > >> takes to do that.
> > >>>> >> > > >>
> > >>>> >> > > >> Ralph
> > >>>> >> > > >>
> > >>>> >> > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <
> tim.v2.0@gmail.com
> > >
> > >>>> >> wrote:
> > >>>> >> > > >>>
> > >>>> >> > > >>> Thank you, Volkan.
> > >>>> >> > > >>>
> > >>>> >> > > >>> I'm not quite ready to submit a PR. I was hoping some of
> > you
> > >>>> with
> > >>>> >> more
> > >>>> >> > > >>> knowledge of log4j-core would weigh in on what we should
> do
> > >>>> about
> > >>>> >> > > >> shutting
> > >>>> >> > > >>> down the StatusLogger.
> > >>>> >> > > >>>
> > >>>> >> > > >>> My thought is we choose one of two options:
> > >>>> >> > > >>>
> > >>>> >> > > >>> Option A:
> > >>>> >> > > >>> 1) check if any StatusLogger is writing to standard out
> or
> > >>>> >> standard
> > >>>> >> > > >> error.
> > >>>> >> > > >>> If not, add one.
> > >>>> >> > > >>> 2) stop any loggers that don't write to standard out or
> > >>>> standard
> > >>>> >> error.
> > >>>> >> > > >>>
> > >>>> >> > > >>> Option B:
> > >>>> >> > > >>> 1) stop any loggers that don't write to standard out or
> > >>>> standard
> > >>>> >> error.
> > >>>> >> > > >>>
> > >>>> >> > > >>> Option A could cause the log messages to be split across
> > two
> > >>>> >> > > >> destinations,
> > >>>> >> > > >>> but they all get sent somewhere. Option B could lose
> > shutdown
> > >>>> >> messages
> > >>>> >> > > >> when
> > >>>> >> > > >>> writing to a file, but by that point it may not matter.
> > >>>> >> > > >>>
> > >>>> >> > > >>> If any of you have a better idea, I'm happy to implement
> > it.
> > >>>> If
> > >>>> >> nobody
> > >>>> >> > > >>> weighs in on the best option, I'll probably submit
> Option A
> > >>>> as a
> > >>>> >> pull
> > >>>> >> > > >>> request on Friday or Saturday.
> > >>>> >> > > >>>
> > >>>> >> > > >>> Tim
> > >>>> >> > > >>>
> > >>>> >> > > >>
> > >>>> >> > > >>
> > >>>> >> > > >>
> > >>>> >> > >
> > >>>> >> > >
> > >>>> >>
> > >>>> >
> > >>>>
> > >>>
> >
>
Re: What is going on with Master?
Posted by Remko Popma <re...@gmail.com>.
Sixx XT appears to be a robot.
Ban?
Sixx XT, you can redeem yourself with an intelligent response to this
message.
On Tue, Apr 20, 2021 at 6:04 Sixx XT <si...@gmail.com> wrote:
> They figured it out through the drive the guy that was hacking me and stole
> my dev in 2016 Oct yyyy is under apache 2.2
>
> On Mon, Apr 19, 2021, 4:53 PM Sixx XT <si...@gmail.com> wrote:
>
> > Look out for dup() files
> >
> > On Mon, Apr 19, 2021, 4:52 PM Sixx XT <si...@gmail.com> wrote:
> >
> >> Thank you im sorry when I find a job ill pay u
> >>
> >> On Mon, Apr 19, 2021, 4:48 PM Sixx XT <si...@gmail.com> wrote:
> >>
> >>> Do I need to disable drive
> >>>
> >>> On Mon, Apr 19, 2021, 4:41 PM Tim Perry <ti...@gmail.com> wrote:
> >>>
> >>>> After further thought, I am threading the context name into the
> location
> >>>> where the StatusConfiguration creates the StatusConsoleListener and
> >>>> registering the context name there.
> >>>>
> >>>> In addition, if the new logger would write to a destination other than
> >>>> standard out or standard error then I do not reconfigure the existing
> >>>> logger in
> StatusConfiguration.configureExistingStatusConsoleListener(),
> >>>> instead I have the
> >>>>
> >>>> I am now correctly closing the status logger when the context is
> >>>> stopped.
> >>>>
> >>>> I'll push the changes to github after I do a full build
> >>>>
> >>>> On Mon, Apr 19, 2021 at 12:17 PM Tim Perry <ti...@gmail.com>
> wrote:
> >>>>
> >>>> > I rewrote this to shut down listeners based on the contextName. In
> >>>> > testing, I discovered that the StatusConsoleListener is created in
> >>>> > StatusConfiguration, but neither StatusConfiguration nor
> >>>> > StatusConsoleListener receive events to indicate when they should
> >>>> stop.
> >>>> >
> >>>> > It appears that only one StatusConsoleListener object is ever
> created
> >>>> and
> >>>> > it is never shut down. Looking at the api XmlConfiguration, it calls
> >>>> > StatusConfiguration.initilize() which then either changes the log
> >>>> level to
> >>>> > match the config being parsed or creates a new StatusLogger directed
> >>>> to the
> >>>> > file indicated in the XML configuration. Unless I'm reading the code
> >>>> wrong,
> >>>> > this means that the status logger output location depends on if a
> >>>> previous
> >>>> > app was loaded. If so, then that location will continue to receive
> >>>> > StatusLogger messages but at the log level of the new application's
> >>>> config.
> >>>> > Am I reading this correctly? If I am, is this the intended
> behaviour?
> >>>> >
> >>>> >
> >>>> >
> >>>> > On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <bo...@gmail.com>
> wrote:
> >>>> >
> >>>> >> The StatusLogger has various listeners attached. I think adding and
> >>>> >> removing listeners on startup and shutdown of a LoggerContext might
> >>>> be
> >>>> >> a potential way to do this?
> >>>> >>
> >>>> >> On Wed, 24 Feb 2021 at 01:07, Tim Perry <ti...@gmail.com>
> wrote:
> >>>> >> >
> >>>> >> > Ralph,
> >>>> >> >
> >>>> >> > Thanks for the review. Yep, that *is* a problem...I knew it was a
> >>>> >> singleton
> >>>> >> > but didn't think through the use case you describe. This is
> ironic
> >>>> >> since a
> >>>> >> > few months ago I recommended that one of my clients bundle log4j
> >>>> in each
> >>>> >> > war rather than on Tomcat's classpath so there would be less
> >>>> chance of
> >>>> >> > instances walking on each other. Sigh.
> >>>> >> >
> >>>> >> >
> >>>> >> > What is the correct behaviour if:
> >>>> >> >
> >>>> >> > - log4j is on Tomcat's classpath
> >>>> >> > - App A has status_A.log
> >>>> >> > - App B has status_B.log
> >>>> >> >
> >>>> >> > Now assume both apps are started. At this point I assume we
> should
> >>>> be
> >>>> >> > writing to both status_A.log and status_B.log. Now we stop App
> B. I
> >>>> >> assume
> >>>> >> > we should stop writing to status_B.log but not status_A.log.
> >>>> Further, I
> >>>> >> > assume that if both apps are unloaded from Tomcat, but Tomcat is
> >>>> left
> >>>> >> > running, then the status logger should send its messages to
> >>>> standard
> >>>> >> out.
> >>>> >> > If my assumptions are correct, then maybe we need to keep track
> of
> >>>> what
> >>>> >> > file, if any, each web app requested messages to be written to.
> On
> >>>> top
> >>>> >> of
> >>>> >> > that, I think we need a Callback in Log4j's shutdown registry and
> >>>> we
> >>>> >> need
> >>>> >> > to run it last.
> >>>> >> >
> >>>> >> >
> >>>> >> > In some ways this seems like an XY problem. Is the correct
> >>>> question how
> >>>> >> do
> >>>> >> > we reconfigure the logging when a web app shuts down? Or should
> it
> >>>> be:
> >>>> >> > should the StatusLogger be shared across multiple LoggerContexts?
> >>>> >> >
> >>>> >> >
> >>>> >> > This will be more interesting than I first realized!
> >>>> >> >
> >>>> >> > Tim
> >>>> >> >
> >>>> >> >
> >>>> >> > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <
> >>>> >> ralph.goers@dslextreme.com>
> >>>> >> > wrote:
> >>>> >> >
> >>>> >> > > Yeah, I started a review but then I thought it probably would
> be
> >>>> >> better to
> >>>> >> > > respond here.
> >>>> >> > >
> >>>> >> > > You are on the right track but there is a problem. StatusLogger
> >>>> is a
> >>>> >> > > singleton - there is one instance anchored in a static. You are
> >>>> >> invoking
> >>>> >> > > the shutdown logic from the shutdown of the LoggerContext which
> >>>> is
> >>>> >> not a
> >>>> >> > > singleton. Log4j supports multiple LoggerContexts in an
> >>>> application.
> >>>> >> For
> >>>> >> > > example, if you are old school and running multiple web
> >>>> applications
> >>>> >> in
> >>>> >> > > Tomcat and have Log4j on Tomcat’s class path then you will have
> >>>> >> multiple
> >>>> >> > > LoggerContexts with a single StatusLogger. So if one web app
> gets
> >>>> >> > > redeployed then its LoggerContext will be shutdown and a new
> one
> >>>> >> created
> >>>> >> > > all while another app is continuing to run.
> >>>> >> > >
> >>>> >> > > If you’ll notice the StatusConfiguration class in log4j-core
> >>>> tries to
> >>>> >> > > accommodate for this during startup, but it doesn’t do anything
> >>>> at
> >>>> >> > > shutdown. StatusLogger currently isn’t smart enough to handle
> >>>> one app
> >>>> >> > > writing to one destination and a different on writing to a
> >>>> different
> >>>> >> one.
> >>>> >> > > Since StatusLogger is a singleton it can’t really know which
> app
> >>>> a
> >>>> >> status
> >>>> >> > > log event is for.
> >>>> >> > >
> >>>> >> > > There are a couple of ways I can think of to handle this but
> >>>> none of
> >>>> >> them
> >>>> >> > > is perfect.
> >>>> >> > > Modify StatusConfiguration to keep track of what each
> >>>> >> StatusConfiguration
> >>>> >> > > set up and reset to whatever the prior StatusConfiguration had.
> >>>> The
> >>>> >> problem
> >>>> >> > > with this is that applications might shutdown in a different
> >>>> order
> >>>> >> than
> >>>> >> > > they were started, so figuring out what the prior configuration
> >>>> was
> >>>> >> could
> >>>> >> > > be difficult.
> >>>> >> > > Add the call to prepareToStop() as a new Callback to Log4j’s
> >>>> shutdown
> >>>> >> > > registry. However, this callback would need to run last. The
> >>>> shutdown
> >>>> >> > > registry currently doesn’t support a way to specify the order
> of
> >>>> >> callbacks.
> >>>> >> > > Support for that would need to be added for this to work.
> >>>> >> > >
> >>>> >> > > Ralph
> >>>> >> > >
> >>>> >> > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <ti...@gmail.com>
> >>>> wrote:
> >>>> >> > > >
> >>>> >> > > > Ralph,
> >>>> >> > > >
> >>>> >> > > > I implemented what you suggested. Feel free to suggest
> >>>> improvements.
> >>>> >> > > > https://github.com/apache/logging-log4j2/pull/469
> >>>> >> > > >
> >>>> >> > > > Tim
> >>>> >> > > >
> >>>> >> > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers <
> >>>> >> ralph.goers@dslextreme.com>
> >>>> >> > > > wrote:
> >>>> >> > > >
> >>>> >> > > >> I would suggest that if it is writing to something other
> than
> >>>> >> System.out
> >>>> >> > > >> that it be redirected back there and then the OutputStream
> be
> >>>> >> closed.
> >>>> >> > > >> However, I’ve not looked at the code recently so I am not
> sure
> >>>> >> what it
> >>>> >> > > >> takes to do that.
> >>>> >> > > >>
> >>>> >> > > >> Ralph
> >>>> >> > > >>
> >>>> >> > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <tim.v2.0@gmail.com
> >
> >>>> >> wrote:
> >>>> >> > > >>>
> >>>> >> > > >>> Thank you, Volkan.
> >>>> >> > > >>>
> >>>> >> > > >>> I'm not quite ready to submit a PR. I was hoping some of
> you
> >>>> with
> >>>> >> more
> >>>> >> > > >>> knowledge of log4j-core would weigh in on what we should do
> >>>> about
> >>>> >> > > >> shutting
> >>>> >> > > >>> down the StatusLogger.
> >>>> >> > > >>>
> >>>> >> > > >>> My thought is we choose one of two options:
> >>>> >> > > >>>
> >>>> >> > > >>> Option A:
> >>>> >> > > >>> 1) check if any StatusLogger is writing to standard out or
> >>>> >> standard
> >>>> >> > > >> error.
> >>>> >> > > >>> If not, add one.
> >>>> >> > > >>> 2) stop any loggers that don't write to standard out or
> >>>> standard
> >>>> >> error.
> >>>> >> > > >>>
> >>>> >> > > >>> Option B:
> >>>> >> > > >>> 1) stop any loggers that don't write to standard out or
> >>>> standard
> >>>> >> error.
> >>>> >> > > >>>
> >>>> >> > > >>> Option A could cause the log messages to be split across
> two
> >>>> >> > > >> destinations,
> >>>> >> > > >>> but they all get sent somewhere. Option B could lose
> shutdown
> >>>> >> messages
> >>>> >> > > >> when
> >>>> >> > > >>> writing to a file, but by that point it may not matter.
> >>>> >> > > >>>
> >>>> >> > > >>> If any of you have a better idea, I'm happy to implement
> it.
> >>>> If
> >>>> >> nobody
> >>>> >> > > >>> weighs in on the best option, I'll probably submit Option A
> >>>> as a
> >>>> >> pull
> >>>> >> > > >>> request on Friday or Saturday.
> >>>> >> > > >>>
> >>>> >> > > >>> Tim
> >>>> >> > > >>>
> >>>> >> > > >>
> >>>> >> > > >>
> >>>> >> > > >>
> >>>> >> > >
> >>>> >> > >
> >>>> >>
> >>>> >
> >>>>
> >>>
>
Re: What is going on with Master?
Posted by Sixx XT <si...@gmail.com>.
They figured it out through the drive the guy that was hacking me and stole
my dev in 2016 Oct yyyy is under apache 2.2
On Mon, Apr 19, 2021, 4:53 PM Sixx XT <si...@gmail.com> wrote:
> Look out for dup() files
>
> On Mon, Apr 19, 2021, 4:52 PM Sixx XT <si...@gmail.com> wrote:
>
>> Thank you im sorry when I find a job ill pay u
>>
>> On Mon, Apr 19, 2021, 4:48 PM Sixx XT <si...@gmail.com> wrote:
>>
>>> Do I need to disable drive
>>>
>>> On Mon, Apr 19, 2021, 4:41 PM Tim Perry <ti...@gmail.com> wrote:
>>>
>>>> After further thought, I am threading the context name into the location
>>>> where the StatusConfiguration creates the StatusConsoleListener and
>>>> registering the context name there.
>>>>
>>>> In addition, if the new logger would write to a destination other than
>>>> standard out or standard error then I do not reconfigure the existing
>>>> logger in StatusConfiguration.configureExistingStatusConsoleListener(),
>>>> instead I have the
>>>>
>>>> I am now correctly closing the status logger when the context is
>>>> stopped.
>>>>
>>>> I'll push the changes to github after I do a full build
>>>>
>>>> On Mon, Apr 19, 2021 at 12:17 PM Tim Perry <ti...@gmail.com> wrote:
>>>>
>>>> > I rewrote this to shut down listeners based on the contextName. In
>>>> > testing, I discovered that the StatusConsoleListener is created in
>>>> > StatusConfiguration, but neither StatusConfiguration nor
>>>> > StatusConsoleListener receive events to indicate when they should
>>>> stop.
>>>> >
>>>> > It appears that only one StatusConsoleListener object is ever created
>>>> and
>>>> > it is never shut down. Looking at the api XmlConfiguration, it calls
>>>> > StatusConfiguration.initilize() which then either changes the log
>>>> level to
>>>> > match the config being parsed or creates a new StatusLogger directed
>>>> to the
>>>> > file indicated in the XML configuration. Unless I'm reading the code
>>>> wrong,
>>>> > this means that the status logger output location depends on if a
>>>> previous
>>>> > app was loaded. If so, then that location will continue to receive
>>>> > StatusLogger messages but at the log level of the new application's
>>>> config.
>>>> > Am I reading this correctly? If I am, is this the intended behaviour?
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <bo...@gmail.com> wrote:
>>>> >
>>>> >> The StatusLogger has various listeners attached. I think adding and
>>>> >> removing listeners on startup and shutdown of a LoggerContext might
>>>> be
>>>> >> a potential way to do this?
>>>> >>
>>>> >> On Wed, 24 Feb 2021 at 01:07, Tim Perry <ti...@gmail.com> wrote:
>>>> >> >
>>>> >> > Ralph,
>>>> >> >
>>>> >> > Thanks for the review. Yep, that *is* a problem...I knew it was a
>>>> >> singleton
>>>> >> > but didn't think through the use case you describe. This is ironic
>>>> >> since a
>>>> >> > few months ago I recommended that one of my clients bundle log4j
>>>> in each
>>>> >> > war rather than on Tomcat's classpath so there would be less
>>>> chance of
>>>> >> > instances walking on each other. Sigh.
>>>> >> >
>>>> >> >
>>>> >> > What is the correct behaviour if:
>>>> >> >
>>>> >> > - log4j is on Tomcat's classpath
>>>> >> > - App A has status_A.log
>>>> >> > - App B has status_B.log
>>>> >> >
>>>> >> > Now assume both apps are started. At this point I assume we should
>>>> be
>>>> >> > writing to both status_A.log and status_B.log. Now we stop App B. I
>>>> >> assume
>>>> >> > we should stop writing to status_B.log but not status_A.log.
>>>> Further, I
>>>> >> > assume that if both apps are unloaded from Tomcat, but Tomcat is
>>>> left
>>>> >> > running, then the status logger should send its messages to
>>>> standard
>>>> >> out.
>>>> >> > If my assumptions are correct, then maybe we need to keep track of
>>>> what
>>>> >> > file, if any, each web app requested messages to be written to. On
>>>> top
>>>> >> of
>>>> >> > that, I think we need a Callback in Log4j's shutdown registry and
>>>> we
>>>> >> need
>>>> >> > to run it last.
>>>> >> >
>>>> >> >
>>>> >> > In some ways this seems like an XY problem. Is the correct
>>>> question how
>>>> >> do
>>>> >> > we reconfigure the logging when a web app shuts down? Or should it
>>>> be:
>>>> >> > should the StatusLogger be shared across multiple LoggerContexts?
>>>> >> >
>>>> >> >
>>>> >> > This will be more interesting than I first realized!
>>>> >> >
>>>> >> > Tim
>>>> >> >
>>>> >> >
>>>> >> > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <
>>>> >> ralph.goers@dslextreme.com>
>>>> >> > wrote:
>>>> >> >
>>>> >> > > Yeah, I started a review but then I thought it probably would be
>>>> >> better to
>>>> >> > > respond here.
>>>> >> > >
>>>> >> > > You are on the right track but there is a problem. StatusLogger
>>>> is a
>>>> >> > > singleton - there is one instance anchored in a static. You are
>>>> >> invoking
>>>> >> > > the shutdown logic from the shutdown of the LoggerContext which
>>>> is
>>>> >> not a
>>>> >> > > singleton. Log4j supports multiple LoggerContexts in an
>>>> application.
>>>> >> For
>>>> >> > > example, if you are old school and running multiple web
>>>> applications
>>>> >> in
>>>> >> > > Tomcat and have Log4j on Tomcat’s class path then you will have
>>>> >> multiple
>>>> >> > > LoggerContexts with a single StatusLogger. So if one web app gets
>>>> >> > > redeployed then its LoggerContext will be shutdown and a new one
>>>> >> created
>>>> >> > > all while another app is continuing to run.
>>>> >> > >
>>>> >> > > If you’ll notice the StatusConfiguration class in log4j-core
>>>> tries to
>>>> >> > > accommodate for this during startup, but it doesn’t do anything
>>>> at
>>>> >> > > shutdown. StatusLogger currently isn’t smart enough to handle
>>>> one app
>>>> >> > > writing to one destination and a different on writing to a
>>>> different
>>>> >> one.
>>>> >> > > Since StatusLogger is a singleton it can’t really know which app
>>>> a
>>>> >> status
>>>> >> > > log event is for.
>>>> >> > >
>>>> >> > > There are a couple of ways I can think of to handle this but
>>>> none of
>>>> >> them
>>>> >> > > is perfect.
>>>> >> > > Modify StatusConfiguration to keep track of what each
>>>> >> StatusConfiguration
>>>> >> > > set up and reset to whatever the prior StatusConfiguration had.
>>>> The
>>>> >> problem
>>>> >> > > with this is that applications might shutdown in a different
>>>> order
>>>> >> than
>>>> >> > > they were started, so figuring out what the prior configuration
>>>> was
>>>> >> could
>>>> >> > > be difficult.
>>>> >> > > Add the call to prepareToStop() as a new Callback to Log4j’s
>>>> shutdown
>>>> >> > > registry. However, this callback would need to run last. The
>>>> shutdown
>>>> >> > > registry currently doesn’t support a way to specify the order of
>>>> >> callbacks.
>>>> >> > > Support for that would need to be added for this to work.
>>>> >> > >
>>>> >> > > Ralph
>>>> >> > >
>>>> >> > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <ti...@gmail.com>
>>>> wrote:
>>>> >> > > >
>>>> >> > > > Ralph,
>>>> >> > > >
>>>> >> > > > I implemented what you suggested. Feel free to suggest
>>>> improvements.
>>>> >> > > > https://github.com/apache/logging-log4j2/pull/469
>>>> >> > > >
>>>> >> > > > Tim
>>>> >> > > >
>>>> >> > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers <
>>>> >> ralph.goers@dslextreme.com>
>>>> >> > > > wrote:
>>>> >> > > >
>>>> >> > > >> I would suggest that if it is writing to something other than
>>>> >> System.out
>>>> >> > > >> that it be redirected back there and then the OutputStream be
>>>> >> closed.
>>>> >> > > >> However, I’ve not looked at the code recently so I am not sure
>>>> >> what it
>>>> >> > > >> takes to do that.
>>>> >> > > >>
>>>> >> > > >> Ralph
>>>> >> > > >>
>>>> >> > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <ti...@gmail.com>
>>>> >> wrote:
>>>> >> > > >>>
>>>> >> > > >>> Thank you, Volkan.
>>>> >> > > >>>
>>>> >> > > >>> I'm not quite ready to submit a PR. I was hoping some of you
>>>> with
>>>> >> more
>>>> >> > > >>> knowledge of log4j-core would weigh in on what we should do
>>>> about
>>>> >> > > >> shutting
>>>> >> > > >>> down the StatusLogger.
>>>> >> > > >>>
>>>> >> > > >>> My thought is we choose one of two options:
>>>> >> > > >>>
>>>> >> > > >>> Option A:
>>>> >> > > >>> 1) check if any StatusLogger is writing to standard out or
>>>> >> standard
>>>> >> > > >> error.
>>>> >> > > >>> If not, add one.
>>>> >> > > >>> 2) stop any loggers that don't write to standard out or
>>>> standard
>>>> >> error.
>>>> >> > > >>>
>>>> >> > > >>> Option B:
>>>> >> > > >>> 1) stop any loggers that don't write to standard out or
>>>> standard
>>>> >> error.
>>>> >> > > >>>
>>>> >> > > >>> Option A could cause the log messages to be split across two
>>>> >> > > >> destinations,
>>>> >> > > >>> but they all get sent somewhere. Option B could lose shutdown
>>>> >> messages
>>>> >> > > >> when
>>>> >> > > >>> writing to a file, but by that point it may not matter.
>>>> >> > > >>>
>>>> >> > > >>> If any of you have a better idea, I'm happy to implement it.
>>>> If
>>>> >> nobody
>>>> >> > > >>> weighs in on the best option, I'll probably submit Option A
>>>> as a
>>>> >> pull
>>>> >> > > >>> request on Friday or Saturday.
>>>> >> > > >>>
>>>> >> > > >>> Tim
>>>> >> > > >>>
>>>> >> > > >>
>>>> >> > > >>
>>>> >> > > >>
>>>> >> > >
>>>> >> > >
>>>> >>
>>>> >
>>>>
>>>
Re: What is going on with Master?
Posted by Sixx XT <si...@gmail.com>.
Look out for dup() files
On Mon, Apr 19, 2021, 4:52 PM Sixx XT <si...@gmail.com> wrote:
> Thank you im sorry when I find a job ill pay u
>
> On Mon, Apr 19, 2021, 4:48 PM Sixx XT <si...@gmail.com> wrote:
>
>> Do I need to disable drive
>>
>> On Mon, Apr 19, 2021, 4:41 PM Tim Perry <ti...@gmail.com> wrote:
>>
>>> After further thought, I am threading the context name into the location
>>> where the StatusConfiguration creates the StatusConsoleListener and
>>> registering the context name there.
>>>
>>> In addition, if the new logger would write to a destination other than
>>> standard out or standard error then I do not reconfigure the existing
>>> logger in StatusConfiguration.configureExistingStatusConsoleListener(),
>>> instead I have the
>>>
>>> I am now correctly closing the status logger when the context is stopped.
>>>
>>> I'll push the changes to github after I do a full build
>>>
>>> On Mon, Apr 19, 2021 at 12:17 PM Tim Perry <ti...@gmail.com> wrote:
>>>
>>> > I rewrote this to shut down listeners based on the contextName. In
>>> > testing, I discovered that the StatusConsoleListener is created in
>>> > StatusConfiguration, but neither StatusConfiguration nor
>>> > StatusConsoleListener receive events to indicate when they should stop.
>>> >
>>> > It appears that only one StatusConsoleListener object is ever created
>>> and
>>> > it is never shut down. Looking at the api XmlConfiguration, it calls
>>> > StatusConfiguration.initilize() which then either changes the log
>>> level to
>>> > match the config being parsed or creates a new StatusLogger directed
>>> to the
>>> > file indicated in the XML configuration. Unless I'm reading the code
>>> wrong,
>>> > this means that the status logger output location depends on if a
>>> previous
>>> > app was loaded. If so, then that location will continue to receive
>>> > StatusLogger messages but at the log level of the new application's
>>> config.
>>> > Am I reading this correctly? If I am, is this the intended behaviour?
>>> >
>>> >
>>> >
>>> > On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <bo...@gmail.com> wrote:
>>> >
>>> >> The StatusLogger has various listeners attached. I think adding and
>>> >> removing listeners on startup and shutdown of a LoggerContext might be
>>> >> a potential way to do this?
>>> >>
>>> >> On Wed, 24 Feb 2021 at 01:07, Tim Perry <ti...@gmail.com> wrote:
>>> >> >
>>> >> > Ralph,
>>> >> >
>>> >> > Thanks for the review. Yep, that *is* a problem...I knew it was a
>>> >> singleton
>>> >> > but didn't think through the use case you describe. This is ironic
>>> >> since a
>>> >> > few months ago I recommended that one of my clients bundle log4j in
>>> each
>>> >> > war rather than on Tomcat's classpath so there would be less chance
>>> of
>>> >> > instances walking on each other. Sigh.
>>> >> >
>>> >> >
>>> >> > What is the correct behaviour if:
>>> >> >
>>> >> > - log4j is on Tomcat's classpath
>>> >> > - App A has status_A.log
>>> >> > - App B has status_B.log
>>> >> >
>>> >> > Now assume both apps are started. At this point I assume we should
>>> be
>>> >> > writing to both status_A.log and status_B.log. Now we stop App B. I
>>> >> assume
>>> >> > we should stop writing to status_B.log but not status_A.log.
>>> Further, I
>>> >> > assume that if both apps are unloaded from Tomcat, but Tomcat is
>>> left
>>> >> > running, then the status logger should send its messages to standard
>>> >> out.
>>> >> > If my assumptions are correct, then maybe we need to keep track of
>>> what
>>> >> > file, if any, each web app requested messages to be written to. On
>>> top
>>> >> of
>>> >> > that, I think we need a Callback in Log4j's shutdown registry and we
>>> >> need
>>> >> > to run it last.
>>> >> >
>>> >> >
>>> >> > In some ways this seems like an XY problem. Is the correct question
>>> how
>>> >> do
>>> >> > we reconfigure the logging when a web app shuts down? Or should it
>>> be:
>>> >> > should the StatusLogger be shared across multiple LoggerContexts?
>>> >> >
>>> >> >
>>> >> > This will be more interesting than I first realized!
>>> >> >
>>> >> > Tim
>>> >> >
>>> >> >
>>> >> > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <
>>> >> ralph.goers@dslextreme.com>
>>> >> > wrote:
>>> >> >
>>> >> > > Yeah, I started a review but then I thought it probably would be
>>> >> better to
>>> >> > > respond here.
>>> >> > >
>>> >> > > You are on the right track but there is a problem. StatusLogger
>>> is a
>>> >> > > singleton - there is one instance anchored in a static. You are
>>> >> invoking
>>> >> > > the shutdown logic from the shutdown of the LoggerContext which is
>>> >> not a
>>> >> > > singleton. Log4j supports multiple LoggerContexts in an
>>> application.
>>> >> For
>>> >> > > example, if you are old school and running multiple web
>>> applications
>>> >> in
>>> >> > > Tomcat and have Log4j on Tomcat’s class path then you will have
>>> >> multiple
>>> >> > > LoggerContexts with a single StatusLogger. So if one web app gets
>>> >> > > redeployed then its LoggerContext will be shutdown and a new one
>>> >> created
>>> >> > > all while another app is continuing to run.
>>> >> > >
>>> >> > > If you’ll notice the StatusConfiguration class in log4j-core
>>> tries to
>>> >> > > accommodate for this during startup, but it doesn’t do anything at
>>> >> > > shutdown. StatusLogger currently isn’t smart enough to handle one
>>> app
>>> >> > > writing to one destination and a different on writing to a
>>> different
>>> >> one.
>>> >> > > Since StatusLogger is a singleton it can’t really know which app a
>>> >> status
>>> >> > > log event is for.
>>> >> > >
>>> >> > > There are a couple of ways I can think of to handle this but none
>>> of
>>> >> them
>>> >> > > is perfect.
>>> >> > > Modify StatusConfiguration to keep track of what each
>>> >> StatusConfiguration
>>> >> > > set up and reset to whatever the prior StatusConfiguration had.
>>> The
>>> >> problem
>>> >> > > with this is that applications might shutdown in a different order
>>> >> than
>>> >> > > they were started, so figuring out what the prior configuration
>>> was
>>> >> could
>>> >> > > be difficult.
>>> >> > > Add the call to prepareToStop() as a new Callback to Log4j’s
>>> shutdown
>>> >> > > registry. However, this callback would need to run last. The
>>> shutdown
>>> >> > > registry currently doesn’t support a way to specify the order of
>>> >> callbacks.
>>> >> > > Support for that would need to be added for this to work.
>>> >> > >
>>> >> > > Ralph
>>> >> > >
>>> >> > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <ti...@gmail.com>
>>> wrote:
>>> >> > > >
>>> >> > > > Ralph,
>>> >> > > >
>>> >> > > > I implemented what you suggested. Feel free to suggest
>>> improvements.
>>> >> > > > https://github.com/apache/logging-log4j2/pull/469
>>> >> > > >
>>> >> > > > Tim
>>> >> > > >
>>> >> > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers <
>>> >> ralph.goers@dslextreme.com>
>>> >> > > > wrote:
>>> >> > > >
>>> >> > > >> I would suggest that if it is writing to something other than
>>> >> System.out
>>> >> > > >> that it be redirected back there and then the OutputStream be
>>> >> closed.
>>> >> > > >> However, I’ve not looked at the code recently so I am not sure
>>> >> what it
>>> >> > > >> takes to do that.
>>> >> > > >>
>>> >> > > >> Ralph
>>> >> > > >>
>>> >> > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <ti...@gmail.com>
>>> >> wrote:
>>> >> > > >>>
>>> >> > > >>> Thank you, Volkan.
>>> >> > > >>>
>>> >> > > >>> I'm not quite ready to submit a PR. I was hoping some of you
>>> with
>>> >> more
>>> >> > > >>> knowledge of log4j-core would weigh in on what we should do
>>> about
>>> >> > > >> shutting
>>> >> > > >>> down the StatusLogger.
>>> >> > > >>>
>>> >> > > >>> My thought is we choose one of two options:
>>> >> > > >>>
>>> >> > > >>> Option A:
>>> >> > > >>> 1) check if any StatusLogger is writing to standard out or
>>> >> standard
>>> >> > > >> error.
>>> >> > > >>> If not, add one.
>>> >> > > >>> 2) stop any loggers that don't write to standard out or
>>> standard
>>> >> error.
>>> >> > > >>>
>>> >> > > >>> Option B:
>>> >> > > >>> 1) stop any loggers that don't write to standard out or
>>> standard
>>> >> error.
>>> >> > > >>>
>>> >> > > >>> Option A could cause the log messages to be split across two
>>> >> > > >> destinations,
>>> >> > > >>> but they all get sent somewhere. Option B could lose shutdown
>>> >> messages
>>> >> > > >> when
>>> >> > > >>> writing to a file, but by that point it may not matter.
>>> >> > > >>>
>>> >> > > >>> If any of you have a better idea, I'm happy to implement it.
>>> If
>>> >> nobody
>>> >> > > >>> weighs in on the best option, I'll probably submit Option A
>>> as a
>>> >> pull
>>> >> > > >>> request on Friday or Saturday.
>>> >> > > >>>
>>> >> > > >>> Tim
>>> >> > > >>>
>>> >> > > >>
>>> >> > > >>
>>> >> > > >>
>>> >> > >
>>> >> > >
>>> >>
>>> >
>>>
>>
Re: What is going on with Master?
Posted by Sixx XT <si...@gmail.com>.
Thank you im sorry when I find a job ill pay u
On Mon, Apr 19, 2021, 4:48 PM Sixx XT <si...@gmail.com> wrote:
> Do I need to disable drive
>
> On Mon, Apr 19, 2021, 4:41 PM Tim Perry <ti...@gmail.com> wrote:
>
>> After further thought, I am threading the context name into the location
>> where the StatusConfiguration creates the StatusConsoleListener and
>> registering the context name there.
>>
>> In addition, if the new logger would write to a destination other than
>> standard out or standard error then I do not reconfigure the existing
>> logger in StatusConfiguration.configureExistingStatusConsoleListener(),
>> instead I have the
>>
>> I am now correctly closing the status logger when the context is stopped.
>>
>> I'll push the changes to github after I do a full build
>>
>> On Mon, Apr 19, 2021 at 12:17 PM Tim Perry <ti...@gmail.com> wrote:
>>
>> > I rewrote this to shut down listeners based on the contextName. In
>> > testing, I discovered that the StatusConsoleListener is created in
>> > StatusConfiguration, but neither StatusConfiguration nor
>> > StatusConsoleListener receive events to indicate when they should stop.
>> >
>> > It appears that only one StatusConsoleListener object is ever created
>> and
>> > it is never shut down. Looking at the api XmlConfiguration, it calls
>> > StatusConfiguration.initilize() which then either changes the log level
>> to
>> > match the config being parsed or creates a new StatusLogger directed to
>> the
>> > file indicated in the XML configuration. Unless I'm reading the code
>> wrong,
>> > this means that the status logger output location depends on if a
>> previous
>> > app was loaded. If so, then that location will continue to receive
>> > StatusLogger messages but at the log level of the new application's
>> config.
>> > Am I reading this correctly? If I am, is this the intended behaviour?
>> >
>> >
>> >
>> > On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <bo...@gmail.com> wrote:
>> >
>> >> The StatusLogger has various listeners attached. I think adding and
>> >> removing listeners on startup and shutdown of a LoggerContext might be
>> >> a potential way to do this?
>> >>
>> >> On Wed, 24 Feb 2021 at 01:07, Tim Perry <ti...@gmail.com> wrote:
>> >> >
>> >> > Ralph,
>> >> >
>> >> > Thanks for the review. Yep, that *is* a problem...I knew it was a
>> >> singleton
>> >> > but didn't think through the use case you describe. This is ironic
>> >> since a
>> >> > few months ago I recommended that one of my clients bundle log4j in
>> each
>> >> > war rather than on Tomcat's classpath so there would be less chance
>> of
>> >> > instances walking on each other. Sigh.
>> >> >
>> >> >
>> >> > What is the correct behaviour if:
>> >> >
>> >> > - log4j is on Tomcat's classpath
>> >> > - App A has status_A.log
>> >> > - App B has status_B.log
>> >> >
>> >> > Now assume both apps are started. At this point I assume we should be
>> >> > writing to both status_A.log and status_B.log. Now we stop App B. I
>> >> assume
>> >> > we should stop writing to status_B.log but not status_A.log.
>> Further, I
>> >> > assume that if both apps are unloaded from Tomcat, but Tomcat is left
>> >> > running, then the status logger should send its messages to standard
>> >> out.
>> >> > If my assumptions are correct, then maybe we need to keep track of
>> what
>> >> > file, if any, each web app requested messages to be written to. On
>> top
>> >> of
>> >> > that, I think we need a Callback in Log4j's shutdown registry and we
>> >> need
>> >> > to run it last.
>> >> >
>> >> >
>> >> > In some ways this seems like an XY problem. Is the correct question
>> how
>> >> do
>> >> > we reconfigure the logging when a web app shuts down? Or should it
>> be:
>> >> > should the StatusLogger be shared across multiple LoggerContexts?
>> >> >
>> >> >
>> >> > This will be more interesting than I first realized!
>> >> >
>> >> > Tim
>> >> >
>> >> >
>> >> > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <
>> >> ralph.goers@dslextreme.com>
>> >> > wrote:
>> >> >
>> >> > > Yeah, I started a review but then I thought it probably would be
>> >> better to
>> >> > > respond here.
>> >> > >
>> >> > > You are on the right track but there is a problem. StatusLogger is
>> a
>> >> > > singleton - there is one instance anchored in a static. You are
>> >> invoking
>> >> > > the shutdown logic from the shutdown of the LoggerContext which is
>> >> not a
>> >> > > singleton. Log4j supports multiple LoggerContexts in an
>> application.
>> >> For
>> >> > > example, if you are old school and running multiple web
>> applications
>> >> in
>> >> > > Tomcat and have Log4j on Tomcat’s class path then you will have
>> >> multiple
>> >> > > LoggerContexts with a single StatusLogger. So if one web app gets
>> >> > > redeployed then its LoggerContext will be shutdown and a new one
>> >> created
>> >> > > all while another app is continuing to run.
>> >> > >
>> >> > > If you’ll notice the StatusConfiguration class in log4j-core tries
>> to
>> >> > > accommodate for this during startup, but it doesn’t do anything at
>> >> > > shutdown. StatusLogger currently isn’t smart enough to handle one
>> app
>> >> > > writing to one destination and a different on writing to a
>> different
>> >> one.
>> >> > > Since StatusLogger is a singleton it can’t really know which app a
>> >> status
>> >> > > log event is for.
>> >> > >
>> >> > > There are a couple of ways I can think of to handle this but none
>> of
>> >> them
>> >> > > is perfect.
>> >> > > Modify StatusConfiguration to keep track of what each
>> >> StatusConfiguration
>> >> > > set up and reset to whatever the prior StatusConfiguration had. The
>> >> problem
>> >> > > with this is that applications might shutdown in a different order
>> >> than
>> >> > > they were started, so figuring out what the prior configuration was
>> >> could
>> >> > > be difficult.
>> >> > > Add the call to prepareToStop() as a new Callback to Log4j’s
>> shutdown
>> >> > > registry. However, this callback would need to run last. The
>> shutdown
>> >> > > registry currently doesn’t support a way to specify the order of
>> >> callbacks.
>> >> > > Support for that would need to be added for this to work.
>> >> > >
>> >> > > Ralph
>> >> > >
>> >> > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <ti...@gmail.com>
>> wrote:
>> >> > > >
>> >> > > > Ralph,
>> >> > > >
>> >> > > > I implemented what you suggested. Feel free to suggest
>> improvements.
>> >> > > > https://github.com/apache/logging-log4j2/pull/469
>> >> > > >
>> >> > > > Tim
>> >> > > >
>> >> > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers <
>> >> ralph.goers@dslextreme.com>
>> >> > > > wrote:
>> >> > > >
>> >> > > >> I would suggest that if it is writing to something other than
>> >> System.out
>> >> > > >> that it be redirected back there and then the OutputStream be
>> >> closed.
>> >> > > >> However, I’ve not looked at the code recently so I am not sure
>> >> what it
>> >> > > >> takes to do that.
>> >> > > >>
>> >> > > >> Ralph
>> >> > > >>
>> >> > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <ti...@gmail.com>
>> >> wrote:
>> >> > > >>>
>> >> > > >>> Thank you, Volkan.
>> >> > > >>>
>> >> > > >>> I'm not quite ready to submit a PR. I was hoping some of you
>> with
>> >> more
>> >> > > >>> knowledge of log4j-core would weigh in on what we should do
>> about
>> >> > > >> shutting
>> >> > > >>> down the StatusLogger.
>> >> > > >>>
>> >> > > >>> My thought is we choose one of two options:
>> >> > > >>>
>> >> > > >>> Option A:
>> >> > > >>> 1) check if any StatusLogger is writing to standard out or
>> >> standard
>> >> > > >> error.
>> >> > > >>> If not, add one.
>> >> > > >>> 2) stop any loggers that don't write to standard out or
>> standard
>> >> error.
>> >> > > >>>
>> >> > > >>> Option B:
>> >> > > >>> 1) stop any loggers that don't write to standard out or
>> standard
>> >> error.
>> >> > > >>>
>> >> > > >>> Option A could cause the log messages to be split across two
>> >> > > >> destinations,
>> >> > > >>> but they all get sent somewhere. Option B could lose shutdown
>> >> messages
>> >> > > >> when
>> >> > > >>> writing to a file, but by that point it may not matter.
>> >> > > >>>
>> >> > > >>> If any of you have a better idea, I'm happy to implement it. If
>> >> nobody
>> >> > > >>> weighs in on the best option, I'll probably submit Option A as
>> a
>> >> pull
>> >> > > >>> request on Friday or Saturday.
>> >> > > >>>
>> >> > > >>> Tim
>> >> > > >>>
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> > >
>> >> > >
>> >>
>> >
>>
>
Re: What is going on with Master?
Posted by Sixx XT <si...@gmail.com>.
Do I need to disable drive
On Mon, Apr 19, 2021, 4:41 PM Tim Perry <ti...@gmail.com> wrote:
> After further thought, I am threading the context name into the location
> where the StatusConfiguration creates the StatusConsoleListener and
> registering the context name there.
>
> In addition, if the new logger would write to a destination other than
> standard out or standard error then I do not reconfigure the existing
> logger in StatusConfiguration.configureExistingStatusConsoleListener(),
> instead I have the
>
> I am now correctly closing the status logger when the context is stopped.
>
> I'll push the changes to github after I do a full build
>
> On Mon, Apr 19, 2021 at 12:17 PM Tim Perry <ti...@gmail.com> wrote:
>
> > I rewrote this to shut down listeners based on the contextName. In
> > testing, I discovered that the StatusConsoleListener is created in
> > StatusConfiguration, but neither StatusConfiguration nor
> > StatusConsoleListener receive events to indicate when they should stop.
> >
> > It appears that only one StatusConsoleListener object is ever created and
> > it is never shut down. Looking at the api XmlConfiguration, it calls
> > StatusConfiguration.initilize() which then either changes the log level
> to
> > match the config being parsed or creates a new StatusLogger directed to
> the
> > file indicated in the XML configuration. Unless I'm reading the code
> wrong,
> > this means that the status logger output location depends on if a
> previous
> > app was loaded. If so, then that location will continue to receive
> > StatusLogger messages but at the log level of the new application's
> config.
> > Am I reading this correctly? If I am, is this the intended behaviour?
> >
> >
> >
> > On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <bo...@gmail.com> wrote:
> >
> >> The StatusLogger has various listeners attached. I think adding and
> >> removing listeners on startup and shutdown of a LoggerContext might be
> >> a potential way to do this?
> >>
> >> On Wed, 24 Feb 2021 at 01:07, Tim Perry <ti...@gmail.com> wrote:
> >> >
> >> > Ralph,
> >> >
> >> > Thanks for the review. Yep, that *is* a problem...I knew it was a
> >> singleton
> >> > but didn't think through the use case you describe. This is ironic
> >> since a
> >> > few months ago I recommended that one of my clients bundle log4j in
> each
> >> > war rather than on Tomcat's classpath so there would be less chance of
> >> > instances walking on each other. Sigh.
> >> >
> >> >
> >> > What is the correct behaviour if:
> >> >
> >> > - log4j is on Tomcat's classpath
> >> > - App A has status_A.log
> >> > - App B has status_B.log
> >> >
> >> > Now assume both apps are started. At this point I assume we should be
> >> > writing to both status_A.log and status_B.log. Now we stop App B. I
> >> assume
> >> > we should stop writing to status_B.log but not status_A.log. Further,
> I
> >> > assume that if both apps are unloaded from Tomcat, but Tomcat is left
> >> > running, then the status logger should send its messages to standard
> >> out.
> >> > If my assumptions are correct, then maybe we need to keep track of
> what
> >> > file, if any, each web app requested messages to be written to. On top
> >> of
> >> > that, I think we need a Callback in Log4j's shutdown registry and we
> >> need
> >> > to run it last.
> >> >
> >> >
> >> > In some ways this seems like an XY problem. Is the correct question
> how
> >> do
> >> > we reconfigure the logging when a web app shuts down? Or should it be:
> >> > should the StatusLogger be shared across multiple LoggerContexts?
> >> >
> >> >
> >> > This will be more interesting than I first realized!
> >> >
> >> > Tim
> >> >
> >> >
> >> > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <
> >> ralph.goers@dslextreme.com>
> >> > wrote:
> >> >
> >> > > Yeah, I started a review but then I thought it probably would be
> >> better to
> >> > > respond here.
> >> > >
> >> > > You are on the right track but there is a problem. StatusLogger is a
> >> > > singleton - there is one instance anchored in a static. You are
> >> invoking
> >> > > the shutdown logic from the shutdown of the LoggerContext which is
> >> not a
> >> > > singleton. Log4j supports multiple LoggerContexts in an application.
> >> For
> >> > > example, if you are old school and running multiple web applications
> >> in
> >> > > Tomcat and have Log4j on Tomcat’s class path then you will have
> >> multiple
> >> > > LoggerContexts with a single StatusLogger. So if one web app gets
> >> > > redeployed then its LoggerContext will be shutdown and a new one
> >> created
> >> > > all while another app is continuing to run.
> >> > >
> >> > > If you’ll notice the StatusConfiguration class in log4j-core tries
> to
> >> > > accommodate for this during startup, but it doesn’t do anything at
> >> > > shutdown. StatusLogger currently isn’t smart enough to handle one
> app
> >> > > writing to one destination and a different on writing to a different
> >> one.
> >> > > Since StatusLogger is a singleton it can’t really know which app a
> >> status
> >> > > log event is for.
> >> > >
> >> > > There are a couple of ways I can think of to handle this but none of
> >> them
> >> > > is perfect.
> >> > > Modify StatusConfiguration to keep track of what each
> >> StatusConfiguration
> >> > > set up and reset to whatever the prior StatusConfiguration had. The
> >> problem
> >> > > with this is that applications might shutdown in a different order
> >> than
> >> > > they were started, so figuring out what the prior configuration was
> >> could
> >> > > be difficult.
> >> > > Add the call to prepareToStop() as a new Callback to Log4j’s
> shutdown
> >> > > registry. However, this callback would need to run last. The
> shutdown
> >> > > registry currently doesn’t support a way to specify the order of
> >> callbacks.
> >> > > Support for that would need to be added for this to work.
> >> > >
> >> > > Ralph
> >> > >
> >> > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <ti...@gmail.com>
> wrote:
> >> > > >
> >> > > > Ralph,
> >> > > >
> >> > > > I implemented what you suggested. Feel free to suggest
> improvements.
> >> > > > https://github.com/apache/logging-log4j2/pull/469
> >> > > >
> >> > > > Tim
> >> > > >
> >> > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers <
> >> ralph.goers@dslextreme.com>
> >> > > > wrote:
> >> > > >
> >> > > >> I would suggest that if it is writing to something other than
> >> System.out
> >> > > >> that it be redirected back there and then the OutputStream be
> >> closed.
> >> > > >> However, I’ve not looked at the code recently so I am not sure
> >> what it
> >> > > >> takes to do that.
> >> > > >>
> >> > > >> Ralph
> >> > > >>
> >> > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <ti...@gmail.com>
> >> wrote:
> >> > > >>>
> >> > > >>> Thank you, Volkan.
> >> > > >>>
> >> > > >>> I'm not quite ready to submit a PR. I was hoping some of you
> with
> >> more
> >> > > >>> knowledge of log4j-core would weigh in on what we should do
> about
> >> > > >> shutting
> >> > > >>> down the StatusLogger.
> >> > > >>>
> >> > > >>> My thought is we choose one of two options:
> >> > > >>>
> >> > > >>> Option A:
> >> > > >>> 1) check if any StatusLogger is writing to standard out or
> >> standard
> >> > > >> error.
> >> > > >>> If not, add one.
> >> > > >>> 2) stop any loggers that don't write to standard out or standard
> >> error.
> >> > > >>>
> >> > > >>> Option B:
> >> > > >>> 1) stop any loggers that don't write to standard out or standard
> >> error.
> >> > > >>>
> >> > > >>> Option A could cause the log messages to be split across two
> >> > > >> destinations,
> >> > > >>> but they all get sent somewhere. Option B could lose shutdown
> >> messages
> >> > > >> when
> >> > > >>> writing to a file, but by that point it may not matter.
> >> > > >>>
> >> > > >>> If any of you have a better idea, I'm happy to implement it. If
> >> nobody
> >> > > >>> weighs in on the best option, I'll probably submit Option A as a
> >> pull
> >> > > >>> request on Friday or Saturday.
> >> > > >>>
> >> > > >>> Tim
> >> > > >>>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > >
> >> > >
> >>
> >
>
Re: What is going on with Master?
Posted by Tim Perry <ti...@gmail.com>.
After further thought, I am threading the context name into the location
where the StatusConfiguration creates the StatusConsoleListener and
registering the context name there.
In addition, if the new logger would write to a destination other than
standard out or standard error then I do not reconfigure the existing
logger in StatusConfiguration.configureExistingStatusConsoleListener(),
instead I have the
I am now correctly closing the status logger when the context is stopped.
I'll push the changes to github after I do a full build
On Mon, Apr 19, 2021 at 12:17 PM Tim Perry <ti...@gmail.com> wrote:
> I rewrote this to shut down listeners based on the contextName. In
> testing, I discovered that the StatusConsoleListener is created in
> StatusConfiguration, but neither StatusConfiguration nor
> StatusConsoleListener receive events to indicate when they should stop.
>
> It appears that only one StatusConsoleListener object is ever created and
> it is never shut down. Looking at the api XmlConfiguration, it calls
> StatusConfiguration.initilize() which then either changes the log level to
> match the config being parsed or creates a new StatusLogger directed to the
> file indicated in the XML configuration. Unless I'm reading the code wrong,
> this means that the status logger output location depends on if a previous
> app was loaded. If so, then that location will continue to receive
> StatusLogger messages but at the log level of the new application's config.
> Am I reading this correctly? If I am, is this the intended behaviour?
>
>
>
> On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <bo...@gmail.com> wrote:
>
>> The StatusLogger has various listeners attached. I think adding and
>> removing listeners on startup and shutdown of a LoggerContext might be
>> a potential way to do this?
>>
>> On Wed, 24 Feb 2021 at 01:07, Tim Perry <ti...@gmail.com> wrote:
>> >
>> > Ralph,
>> >
>> > Thanks for the review. Yep, that *is* a problem...I knew it was a
>> singleton
>> > but didn't think through the use case you describe. This is ironic
>> since a
>> > few months ago I recommended that one of my clients bundle log4j in each
>> > war rather than on Tomcat's classpath so there would be less chance of
>> > instances walking on each other. Sigh.
>> >
>> >
>> > What is the correct behaviour if:
>> >
>> > - log4j is on Tomcat's classpath
>> > - App A has status_A.log
>> > - App B has status_B.log
>> >
>> > Now assume both apps are started. At this point I assume we should be
>> > writing to both status_A.log and status_B.log. Now we stop App B. I
>> assume
>> > we should stop writing to status_B.log but not status_A.log. Further, I
>> > assume that if both apps are unloaded from Tomcat, but Tomcat is left
>> > running, then the status logger should send its messages to standard
>> out.
>> > If my assumptions are correct, then maybe we need to keep track of what
>> > file, if any, each web app requested messages to be written to. On top
>> of
>> > that, I think we need a Callback in Log4j's shutdown registry and we
>> need
>> > to run it last.
>> >
>> >
>> > In some ways this seems like an XY problem. Is the correct question how
>> do
>> > we reconfigure the logging when a web app shuts down? Or should it be:
>> > should the StatusLogger be shared across multiple LoggerContexts?
>> >
>> >
>> > This will be more interesting than I first realized!
>> >
>> > Tim
>> >
>> >
>> > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <
>> ralph.goers@dslextreme.com>
>> > wrote:
>> >
>> > > Yeah, I started a review but then I thought it probably would be
>> better to
>> > > respond here.
>> > >
>> > > You are on the right track but there is a problem. StatusLogger is a
>> > > singleton - there is one instance anchored in a static. You are
>> invoking
>> > > the shutdown logic from the shutdown of the LoggerContext which is
>> not a
>> > > singleton. Log4j supports multiple LoggerContexts in an application.
>> For
>> > > example, if you are old school and running multiple web applications
>> in
>> > > Tomcat and have Log4j on Tomcat’s class path then you will have
>> multiple
>> > > LoggerContexts with a single StatusLogger. So if one web app gets
>> > > redeployed then its LoggerContext will be shutdown and a new one
>> created
>> > > all while another app is continuing to run.
>> > >
>> > > If you’ll notice the StatusConfiguration class in log4j-core tries to
>> > > accommodate for this during startup, but it doesn’t do anything at
>> > > shutdown. StatusLogger currently isn’t smart enough to handle one app
>> > > writing to one destination and a different on writing to a different
>> one.
>> > > Since StatusLogger is a singleton it can’t really know which app a
>> status
>> > > log event is for.
>> > >
>> > > There are a couple of ways I can think of to handle this but none of
>> them
>> > > is perfect.
>> > > Modify StatusConfiguration to keep track of what each
>> StatusConfiguration
>> > > set up and reset to whatever the prior StatusConfiguration had. The
>> problem
>> > > with this is that applications might shutdown in a different order
>> than
>> > > they were started, so figuring out what the prior configuration was
>> could
>> > > be difficult.
>> > > Add the call to prepareToStop() as a new Callback to Log4j’s shutdown
>> > > registry. However, this callback would need to run last. The shutdown
>> > > registry currently doesn’t support a way to specify the order of
>> callbacks.
>> > > Support for that would need to be added for this to work.
>> > >
>> > > Ralph
>> > >
>> > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <ti...@gmail.com> wrote:
>> > > >
>> > > > Ralph,
>> > > >
>> > > > I implemented what you suggested. Feel free to suggest improvements.
>> > > > https://github.com/apache/logging-log4j2/pull/469
>> > > >
>> > > > Tim
>> > > >
>> > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers <
>> ralph.goers@dslextreme.com>
>> > > > wrote:
>> > > >
>> > > >> I would suggest that if it is writing to something other than
>> System.out
>> > > >> that it be redirected back there and then the OutputStream be
>> closed.
>> > > >> However, I’ve not looked at the code recently so I am not sure
>> what it
>> > > >> takes to do that.
>> > > >>
>> > > >> Ralph
>> > > >>
>> > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <ti...@gmail.com>
>> wrote:
>> > > >>>
>> > > >>> Thank you, Volkan.
>> > > >>>
>> > > >>> I'm not quite ready to submit a PR. I was hoping some of you with
>> more
>> > > >>> knowledge of log4j-core would weigh in on what we should do about
>> > > >> shutting
>> > > >>> down the StatusLogger.
>> > > >>>
>> > > >>> My thought is we choose one of two options:
>> > > >>>
>> > > >>> Option A:
>> > > >>> 1) check if any StatusLogger is writing to standard out or
>> standard
>> > > >> error.
>> > > >>> If not, add one.
>> > > >>> 2) stop any loggers that don't write to standard out or standard
>> error.
>> > > >>>
>> > > >>> Option B:
>> > > >>> 1) stop any loggers that don't write to standard out or standard
>> error.
>> > > >>>
>> > > >>> Option A could cause the log messages to be split across two
>> > > >> destinations,
>> > > >>> but they all get sent somewhere. Option B could lose shutdown
>> messages
>> > > >> when
>> > > >>> writing to a file, but by that point it may not matter.
>> > > >>>
>> > > >>> If any of you have a better idea, I'm happy to implement it. If
>> nobody
>> > > >>> weighs in on the best option, I'll probably submit Option A as a
>> pull
>> > > >>> request on Friday or Saturday.
>> > > >>>
>> > > >>> Tim
>> > > >>>
>> > > >>
>> > > >>
>> > > >>
>> > >
>> > >
>>
>
Re: What is going on with Master?
Posted by Sixx XT <si...@gmail.com>.
Tha rsa-sha256 could be i wrote the event off fake web page should I delete
my events
On Mon, Apr 19, 2021, 3:17 PM Tim Perry <ti...@gmail.com> wrote:
> I rewrote this to shut down listeners based on the contextName. In testing,
> I discovered that the StatusConsoleListener is created in
> StatusConfiguration, but neither StatusConfiguration nor
> StatusConsoleListener receive events to indicate when they should stop.
>
> It appears that only one StatusConsoleListener object is ever created and
> it is never shut down. Looking at the api XmlConfiguration, it calls
> StatusConfiguration.initilize() which then either changes the log level to
> match the config being parsed or creates a new StatusLogger directed to the
> file indicated in the XML configuration. Unless I'm reading the code wrong,
> this means that the status logger output location depends on if a previous
> app was loaded. If so, then that location will continue to receive
> StatusLogger messages but at the log level of the new application's config.
> Am I reading this correctly? If I am, is this the intended behaviour?
>
>
>
> On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <bo...@gmail.com> wrote:
>
> > The StatusLogger has various listeners attached. I think adding and
> > removing listeners on startup and shutdown of a LoggerContext might be
> > a potential way to do this?
> >
> > On Wed, 24 Feb 2021 at 01:07, Tim Perry <ti...@gmail.com> wrote:
> > >
> > > Ralph,
> > >
> > > Thanks for the review. Yep, that *is* a problem...I knew it was a
> > singleton
> > > but didn't think through the use case you describe. This is ironic
> since
> > a
> > > few months ago I recommended that one of my clients bundle log4j in
> each
> > > war rather than on Tomcat's classpath so there would be less chance of
> > > instances walking on each other. Sigh.
> > >
> > >
> > > What is the correct behaviour if:
> > >
> > > - log4j is on Tomcat's classpath
> > > - App A has status_A.log
> > > - App B has status_B.log
> > >
> > > Now assume both apps are started. At this point I assume we should be
> > > writing to both status_A.log and status_B.log. Now we stop App B. I
> > assume
> > > we should stop writing to status_B.log but not status_A.log. Further, I
> > > assume that if both apps are unloaded from Tomcat, but Tomcat is left
> > > running, then the status logger should send its messages to standard
> out.
> > > If my assumptions are correct, then maybe we need to keep track of what
> > > file, if any, each web app requested messages to be written to. On top
> of
> > > that, I think we need a Callback in Log4j's shutdown registry and we
> need
> > > to run it last.
> > >
> > >
> > > In some ways this seems like an XY problem. Is the correct question how
> > do
> > > we reconfigure the logging when a web app shuts down? Or should it be:
> > > should the StatusLogger be shared across multiple LoggerContexts?
> > >
> > >
> > > This will be more interesting than I first realized!
> > >
> > > Tim
> > >
> > >
> > > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <
> ralph.goers@dslextreme.com
> > >
> > > wrote:
> > >
> > > > Yeah, I started a review but then I thought it probably would be
> > better to
> > > > respond here.
> > > >
> > > > You are on the right track but there is a problem. StatusLogger is a
> > > > singleton - there is one instance anchored in a static. You are
> > invoking
> > > > the shutdown logic from the shutdown of the LoggerContext which is
> not
> > a
> > > > singleton. Log4j supports multiple LoggerContexts in an application.
> > For
> > > > example, if you are old school and running multiple web applications
> in
> > > > Tomcat and have Log4j on Tomcat’s class path then you will have
> > multiple
> > > > LoggerContexts with a single StatusLogger. So if one web app gets
> > > > redeployed then its LoggerContext will be shutdown and a new one
> > created
> > > > all while another app is continuing to run.
> > > >
> > > > If you’ll notice the StatusConfiguration class in log4j-core tries to
> > > > accommodate for this during startup, but it doesn’t do anything at
> > > > shutdown. StatusLogger currently isn’t smart enough to handle one app
> > > > writing to one destination and a different on writing to a different
> > one.
> > > > Since StatusLogger is a singleton it can’t really know which app a
> > status
> > > > log event is for.
> > > >
> > > > There are a couple of ways I can think of to handle this but none of
> > them
> > > > is perfect.
> > > > Modify StatusConfiguration to keep track of what each
> > StatusConfiguration
> > > > set up and reset to whatever the prior StatusConfiguration had. The
> > problem
> > > > with this is that applications might shutdown in a different order
> than
> > > > they were started, so figuring out what the prior configuration was
> > could
> > > > be difficult.
> > > > Add the call to prepareToStop() as a new Callback to Log4j’s shutdown
> > > > registry. However, this callback would need to run last. The shutdown
> > > > registry currently doesn’t support a way to specify the order of
> > callbacks.
> > > > Support for that would need to be added for this to work.
> > > >
> > > > Ralph
> > > >
> > > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <ti...@gmail.com>
> wrote:
> > > > >
> > > > > Ralph,
> > > > >
> > > > > I implemented what you suggested. Feel free to suggest
> improvements.
> > > > > https://github.com/apache/logging-log4j2/pull/469
> > > > >
> > > > > Tim
> > > > >
> > > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers <
> > ralph.goers@dslextreme.com>
> > > > > wrote:
> > > > >
> > > > >> I would suggest that if it is writing to something other than
> > System.out
> > > > >> that it be redirected back there and then the OutputStream be
> > closed.
> > > > >> However, I’ve not looked at the code recently so I am not sure
> what
> > it
> > > > >> takes to do that.
> > > > >>
> > > > >> Ralph
> > > > >>
> > > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <ti...@gmail.com>
> wrote:
> > > > >>>
> > > > >>> Thank you, Volkan.
> > > > >>>
> > > > >>> I'm not quite ready to submit a PR. I was hoping some of you with
> > more
> > > > >>> knowledge of log4j-core would weigh in on what we should do about
> > > > >> shutting
> > > > >>> down the StatusLogger.
> > > > >>>
> > > > >>> My thought is we choose one of two options:
> > > > >>>
> > > > >>> Option A:
> > > > >>> 1) check if any StatusLogger is writing to standard out or
> standard
> > > > >> error.
> > > > >>> If not, add one.
> > > > >>> 2) stop any loggers that don't write to standard out or standard
> > error.
> > > > >>>
> > > > >>> Option B:
> > > > >>> 1) stop any loggers that don't write to standard out or standard
> > error.
> > > > >>>
> > > > >>> Option A could cause the log messages to be split across two
> > > > >> destinations,
> > > > >>> but they all get sent somewhere. Option B could lose shutdown
> > messages
> > > > >> when
> > > > >>> writing to a file, but by that point it may not matter.
> > > > >>>
> > > > >>> If any of you have a better idea, I'm happy to implement it. If
> > nobody
> > > > >>> weighs in on the best option, I'll probably submit Option A as a
> > pull
> > > > >>> request on Friday or Saturday.
> > > > >>>
> > > > >>> Tim
> > > > >>>
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> >
>