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

Reply via email to