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 <sixx5...@gmail.com> wrote: > Look out for dup() files > > On Mon, Apr 19, 2021, 4:52 PM Sixx XT <sixx5...@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 <sixx5...@gmail.com> wrote: >> >>> Do I need to disable drive >>> >>> On Mon, Apr 19, 2021, 4:41 PM Tim Perry <tim.v...@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 <tim.v...@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 <boa...@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 <tim.v...@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.go...@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.v...@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.go...@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.v...@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 >>>> >> > > >>> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >>>> >> > > >>>> >> >>>> > >>>> >>>
