Re: Log4j should manage it's own threads

The implementation of https://issues.apache.org/jira/browse/LOG4J2-1539 "Add Core API Configurator.shutdown(LoggerContext, long, TimeUnit)" wraps up this thread. Gary On Mon, Jul 4, 2016 at 12:56 PM, Gary Gregory wrote: > When I see code like: > >

Re: Log4j should manage it's own threads

We should not make Log4j dependent on JavaEE. We should make sure it continue to work in other server frameworks (Akka, ReactiveX, Finagle, etc.) as well. On Fri, Jul 15, 2016 at 2:06 AM, Remko Popma wrote: > The purpose of the J2EE thread model is to prevent prevent

Re: Log4j should manage it's own threads

We have some legacy crap using Oracle Commerce at work (as a shitty CMS, not even for eCommerce) that requires JEE, but other than that, yeah, I've been using Spring and Camel mostly which are generally Tomcat or Jetty or even just Netty. On 14 July 2016 at 20:23, Ralph Goers

Re: Log4j should manage it's own threads

I am not even aware that J2EE/JEE dominates. The environments I have always worked in use Spring. Ralph > On Jul 14, 2016, at 5:06 PM, Remko Popma wrote: > > The purpose of the J2EE thread model is to prevent prevent custom threads > from interacting with container

Re: Log4j should manage it's own threads

The purpose of the J2EE thread model is to prevent prevent custom threads from interacting with container threads. I believe that it is the intention to protect against data corruption issues, data visibility issues etc. If it was allowed for custom threads to call servlet or EJB methods

Re: Log4j should manage it's own threads

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 wrote: > > I

Re: Log4j should manage it's own threads

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 wrote: > Ralph, I am sure it does require some refactoring. Sounds like a good 3.0 > thing :-) but it

Re: Log4j should manage it's own threads

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

Re: Log4j should manage it's own threads

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 wrote: > > In an EE environment, don't create your own

Re: Log4j should manage it's own threads

I think sending you to these links will help the most: https://jcp.org/aboutJava/communityprocess/ec-public/materials/2013-01-1516/JSR236-EC-F2F-Jan2013.pdf https://www.javacodegeeks.com/2014/07/java-ee-concurrency-api-tutorial.html Cheers, Paul On Thu, Jul 14, 2016 at 4:10 PM, Gary Gregory

Re: Log4j should manage it's own threads

On Thu, Jul 14, 2016 at 1:07 PM, Paul Benedict 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

Re: Log4j should manage it's own threads

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

Re: Log4j should manage it's own threads

I'll get around to it ;-) Gary On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker 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 wrote: > >> I'm not sure how many threads

Re: Log4j should manage it's own threads

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

Re: Log4j should manage it's own threads

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

Re: Log4j should manage it's own threads

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 wrote: > This sounds like an interesting idea worth pursuing. > > On 4 July 2016 at 14:56, Gary Gregory wrote: > >> When I

Re: Log4j should manage it's own threads

This sounds like an interesting idea worth pursuing. On 4 July 2016 at 14:56, Gary Gregory wrote: > When I see code like: > > LOGGER.debug("RollingFileManager executing async {}", > descriptor.getAsynchronous()); > thread = new

Log4j should manage it's own threads

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