Actually, I either wish they wouldn’t or do it in such a way that it doesn’t impact the application’s classpath. Many applications will want to use newer versions that whatever version the container ships with.
Ralph > On Jul 14, 2016, at 4:44 PM, Matt Sicker <boa...@gmail.com> wrote: > > I mean ideally, log4j should be running as a server library. Some of the JEE > servers come with log4j 2 out of the box I think. > > On 14 July 2016 at 16:36, Paul Benedict <pbened...@apache.org > <mailto:pbened...@apache.org>> wrote: > Ralph, I am sure it does require some refactoring. Sounds like a good 3.0 > thing :-) but it would be really awesome if Log4J could advertise itself as > EE compatible with threading. Just my 2 cents. When it comes to the > refactoring, you'll just want to have a good abstraction built so you can > plug in the right implementation at runtime (non-container vs container). > > Cheers, > Paul > > On Thu, Jul 14, 2016 at 4:34 PM, Ralph Goers <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> wrote: > I’m not aware that frameworks like Log4j actually adhere to those guidelines. > It is too difficult to write code that works in both the JEE and non-JEE > environments. > > Ralph > >> On Jul 14, 2016, at 1:07 PM, Paul Benedict <pbened...@apache.org >> <mailto:pbened...@apache.org>> wrote: >> >> In an EE environment, don't create your own threads. If you do create your >> own threads, the EE server has no way to shut them down when an application >> gets undeployed. You'd want to have the EE server manage the thread >> creations. >> >> Cheers, >> Paul >> >> On Thu, Jul 14, 2016 at 2:41 PM, Gary Gregory <garydgreg...@gmail.com >> <mailto:garydgreg...@gmail.com>> wrote: >> I'll get around to it ;-) >> >> Gary >> >> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <boa...@gmail.com >> <mailto:boa...@gmail.com>> wrote: >> Anyone wanna make a jira ticket for this? I'm not sure on how best to >> describe this. >> >> On 5 July 2016 at 09:00, Matt Sicker <boa...@gmail.com >> <mailto:boa...@gmail.com>> wrote: >> I'm not sure how many threads we spawn are actually reusable, but gathering >> them into a single pool would definitely help figure out which ones can be >> used. >> >> Also, would this be vaguely related to the custom Log4j ThreadLocal object >> we were thinking about a little while ago? >> >> On 5 July 2016 at 04:52, Mikael Ståldal <mikael.stal...@magine.com >> <mailto:mikael.stal...@magine.com>> wrote: >> Sounds like a good idea. I think it's also good to reuse threads for >> performance. >> >> On Mon, Jul 4, 2016 at 10:00 PM, Matt Sicker <boa...@gmail.com >> <mailto:boa...@gmail.com>> wrote: >> This sounds like an interesting idea worth pursuing. >> >> On 4 July 2016 at 14:56, Gary Gregory <garydgreg...@gmail.com >> <mailto:garydgreg...@gmail.com>> wrote: >> When I see code like: >> >> LOGGER.debug("RollingFileManager executing async {}", >> descriptor.getAsynchronous()); >> thread = new Log4jThread(new >> AsyncAction(descriptor.getAsynchronous(), this)); >> thread.start(); >> >> and: >> >> final Thread thread = new Log4jThread(new >> ReconfigurationWorker(listener, reconfigurable)); >> thread.setDaemon(true); >> thread.start(); >> >> and other places, I think: "and poof, I've lost track of that thread". >> >> What if we used a thread pool (ExecutorService) to track all of our threads? >> This would allow for at least trying for an orderly shutdown. This would >> avoid problems like one part of an app thinking that rollovers should be >> done when they are not because a log4j context has been stopped (like in our >> test probably) but the rollover thread is still going about doing its work. >> >> This would be for 2.7 I think. >> >> We could then have a different context stop API, maybe with a timeout or >> not, something like ExecutorService's shutdown() vs. shutdownNow(). >> >> Thoughts? >> >> Happy 4th! >> >> Gary >> >> -- >> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | >> ggreg...@apache.org <mailto:ggreg...@apache.org> >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> >> Home: http://garygregory.com/ <http://garygregory.com/> >> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >> >> >> -- >> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> >> >> >> >> -- >> >> >> Mikael Ståldal >> Senior software developer >> >> Magine TV >> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com> >> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >> <http://www.magine.com/> >> >> Privileged and/or Confidential Information may be contained in this message. >> If you are not the addressee indicated in this message >> (or responsible for delivery of the message to such a person), you may not >> copy or deliver this message to anyone. In such case, >> you should destroy this message and kindly notify the sender by reply email. >> >> >> >> >> -- >> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> >> >> >> >> -- >> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> >> >> >> >> -- >> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | >> ggreg...@apache.org <mailto:ggreg...@apache.org> >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> >> Home: http://garygregory.com/ <http://garygregory.com/> >> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> > > > > > > -- > Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>