Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

Also, is AutoCloseableLock generic? What kind of lock is it? a ReentrantLock, a ReentrantReadWriteLock, a StampedLock (which doesn’t seem to implement Lock at all), a ReentrantReadWriteLock.ReadLock or a ReentrantReadWriteLock.WriteLock? Ralph > On Jul 21, 2016, at 5:22 PM, Gary Gregory

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

To be autocloseable this would need to be try (final Autoacloseable a = lock.open()) { // ... } I find that strange. I find “autoLock()” strange as well. Are we locking a car? Ralph > On Jul 21, 2016, at 5:14 PM, Matt Sicker wrote: > > And to distinguish it, why not

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

The problem is, lock’s don’t “close” so they shouldn’t be Autoacloseable at all. Ralph > On Jul 21, 2016, at 5:12 PM, Matt Sicker wrote: > > AutoCloseable versus AutoCloseableLock. > > On 21 July 2016 at 18:19, Gary Gregory

[jira] [Commented] (LOG4J2-435) Feature request: auto-delete older log files

[ https://issues.apache.org/jira/browse/LOG4J2-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15388743#comment-15388743 ] Remko Popma commented on LOG4J2-435: Have you seen the example here?

Jenkins build is still unstable: Log4j 2.x #2100

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

Interesting idea! I updated the AutoCloseableLock with this change. AutoCloseableLock now implements Lock. Gary On Thu, Jul 21, 2016 at 5:14 PM, Matt Sicker wrote: > And to distinguish it, why not just give it a signature like: > > AutoCloseable autoLock(); > > try (final

Unused methods in Unbox.*State.isBoxedPrimitive(StringBuilder)

The methods Unused methods in Unbox.*State.isBoxedPrimitive(StringBuilder) are not used. Is it OK to remove them? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

And to distinguish it, why not just give it a signature like: AutoCloseable autoLock(); try (final AutoCloseable a = lock.autoLock()) { // ... } This way you can inherit from Lock as well. On 21 July 2016 at 19:12, Matt Sicker wrote: > AutoCloseable versus

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

AutoCloseable versus AutoCloseableLock. On 21 July 2016 at 18:19, Gary Gregory wrote: > On Thu, Jul 21, 2016 at 4:12 PM, Matt Sicker wrote: > >> Well in that case, I guess it doesn't introduce garbage. I'm back to >> supporting this, then. >> >> Can't

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

I can see your POV. It's just so "tempting" to use such a convenience! Gary On Thu, Jul 21, 2016 at 4:48 PM, Ralph Goers wrote: > You are correct, it isn’t creating extra garbage. However, I still object > because close() is in no way equivalent to unlock(). > >

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

You are correct, it isn’t creating extra garbage. However, I still object because close() is in no way equivalent to unlock(). Ralph > On Jul 21, 2016, at 4:10 PM, Gary Gregory wrote: > > Hi All, > > What extra garbage? (Putting aside if this a "good" idea or not.) A

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

On Thu, Jul 21, 2016 at 4:12 PM, Matt Sicker wrote: > Well in that case, I guess it doesn't introduce garbage. I'm back to > supporting this, then. > > Can't you just do: > > try (final AutoCloseable a = configLock.lock()) { > // ... > } > That's just the example I gave! Am

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

Well in that case, I guess it doesn't introduce garbage. I'm back to supporting this, then. Can't you just do: try (final AutoCloseable a = configLock.lock()) { // ... } On 21 July 2016 at 18:10, Gary Gregory wrote: > Hi All, > > What extra garbage? (Putting aside if

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

Hi All, What extra garbage? (Putting aside if this a "good" idea or not.) A local variable here does not create an extra object to be GC'd. For example, in LoggerContext, we have: private final Lock configLock = new ReentrantLock(); ... @Override public void stop() {

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

Yeah, adding garbage does seem like a bad idea in this case. On 21 July 2016 at 16:30, Ralph Goers wrote: > The more I think about this the more I dislike it. This requires that a > temporary variable be created for no other reason than to satisfy the > compiler. It

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

Why is it that I recall just reading about why the JDK implementors decided that implementing an autocloseable lock was a bad idea? How is this really any different than doing synchronized(LOCK) { return MAP.containsKey(name); } so long as everything else is doing it similarly? From

Re: Lock pattern

What is a mismatch? Things that are all AutoCloseable all used to have an instance of the object created and then make sure it was closed during a finally call. Locks generally don’t work that way. They are typically created when they object they reside in is created and are destroyed when

Re: Lock pattern

On Fri, Jun 24, 2016 at 11:44 AM, Paul Benedict wrote: > That may be the one! Thanks for searching for it. I can't believe it's > from three years ago! :-) Anyway, it goes on for some time and provides > good arguments to consider from both sides. > The whole thing is a

Re: [1/4] logging-log4j2 git commit: Add AutoCloseableLock.

Hi Matt, AutoCloseableLock cannot implement Lock because lock() is void and I count on AutoCloseableLock#lock() returning "this" for the pattern: try (final AutoCloseableLock l = LOCK.lock()) { return MAP.containsKey(name); } I could rename lock() to doLock() and a

[jira] [Comment Edited] (LOG4J2-435) Feature request: auto-delete older log files

[ https://issues.apache.org/jira/browse/LOG4J2-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15388411#comment-15388411 ] Karthik Janarthanan edited comment on LOG4J2-435 at 7/21/16 9:08 PM: -

[jira] [Comment Edited] (LOG4J2-435) Feature request: auto-delete older log files

[ https://issues.apache.org/jira/browse/LOG4J2-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15388411#comment-15388411 ] Karthik Janarthanan edited comment on LOG4J2-435 at 7/21/16 9:06 PM: -

[jira] [Commented] (LOG4J2-435) Feature request: auto-delete older log files

[ https://issues.apache.org/jira/browse/LOG4J2-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15388411#comment-15388411 ] Karthik Janarthanan commented on LOG4J2-435: I'm using properties file to configure log4j2.

Re: Serializable Logger

It's Serializable because there was a feature request for it. The jira ticket is internal (reported by Gary), but I recall either another bug or a mailing list post where the justification was so that serializable classes can still use a Logger instance field (not everyone uses a static field for

[jira] [Commented] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15388027#comment-15388027 ] Remko Popma commented on LOG4J2-1430: - John, Anthony, please take a look at the Log4j 2 [performance

Re: Serializable Logger

I asked myself the same question and I guess the answer is that Logger is included in lots of classes, many of which are Serializable. It would be easier for us to make AbstractLogger Serializable then for all the users to mark it as transient and have to manually instantiate the Logger during

Re: Serializable Logger

So then why is AbstractLogger, and our implementation in log4j-core, Serializable? On Thu, Jul 21, 2016 at 6:18 PM, Gary Gregory wrote: > I do not think there is a way to know what folks are doing out there... > > Gary > > On Thu, Jul 21, 2016 at 9:13 AM, Mikael Ståldal

Re: Serializable Logger

I do not think there is a way to know what folks are doing out there... Gary On Thu, Jul 21, 2016 at 9:13 AM, Mikael Ståldal wrote: > Are there any providers not using AbstractLogger? > > On Thu, Jul 21, 2016 at 6:09 PM, Gary Gregory > wrote:

Re: Serializable Logger

Are there any providers not using AbstractLogger? On Thu, Jul 21, 2016 at 6:09 PM, Gary Gregory wrote: > Probably to leave the decision on whether to support serialization to each > provider. > > Gary > > On Jul 21, 2016 3:14 AM, "Mikael Ståldal"

Re: Serializable Logger

Probably to leave the decision on whether to support serialization to each provider. Gary On Jul 21, 2016 3:14 AM, "Mikael Ståldal" wrote: > AbstractLogger is Serializable, but the Logger interface is not. Why is it > so? > > -- > [image: MagineTV] > > *Mikael

[jira] [Commented] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387914#comment-15387914 ] John Cairns commented on LOG4J2-1430: - Yes, SpinPolicy.WAITING is the correct choice for Conversant

[jira] [Commented] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387906#comment-15387906 ] Matt Sicker commented on LOG4J2-1430: - Could you compare these with the LMAX implementation as well?

Re: Release plan

Generally, the release number and release date dictate themselves. Since we use semantic versioning we only increase the second number when a non-insignificant feature is added (I didn’t use significant on purpose as some features aren’t really significant but they aren’t insignificant

[jira] [Commented] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387874#comment-15387874 ] John Cairns commented on LOG4J2-1430: - Anthony, I'm afraid these benchmarks are perfectly relevant.

[jira] [Comment Edited] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387588#comment-15387588 ] Anthony Maire edited comment on LOG4J2-1430 at 7/21/16 3:02 PM: Hello

[jira] [Commented] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387844#comment-15387844 ] Remko Popma commented on LOG4J2-1430: - It would be good if we can end up with a recommendation to

Re: Release plan

I'd say we're done with 2.6. I'm finishing up the async appender updates (still working on documentation updates, but the code is pretty stable at this point). On 21 July 2016 at 06:45, Mikael Ståldal wrote: > Are we now done with 2.6.x, and heading towards 2.7 in a

[jira] [Commented] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387588#comment-15387588 ] Anthony Maire commented on LOG4J2-1430: --- Hello John Thank you for all these benchmark, but I'm

Release plan

Are we now done with 2.6.x, and heading towards 2.7 in a few months? -- [image: MagineTV] *Mikael Ståldal* Senior software developer *Magine TV* mikael.stal...@magine.com Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com Privileged and/or Confidential Information may be

Serializable Logger

AbstractLogger is Serializable, but the Logger interface is not. Why is it so? -- [image: MagineTV] *Mikael Ståldal* Senior software developer *Magine TV* mikael.stal...@magine.com Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com Privileged and/or Confidential Information may

Re: Log4J 1.x and JDK 9

I agree with Remko (and others) that we should not spend any more work on Log4j 1.x. Instead focus on make Log4j 2.x work properly on Java 9 and help with migrations from 1 -> 2. On Mon, Jul 18, 2016 at 3:09 PM, Remko Popma wrote: > Breaking news: > Spring boot 1.4

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

Jenkins build is unstable: Log4j 2.x #2099

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org