[jira] [Commented] (LOG4J2-1051) NoClassDefFoundError when starting app on Google App Engine

[Frank Conover (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508836#comment-15508836
 ] 

Frank Conover commented on LOG4J2-1051:
---

Same error. Same line number.
BTW This is a java desktop application. Just noticed the ticket was for an
app.
https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-api/2.6.3-SNAPSHOT/
Correct?

On Wed, Sep 21, 2016 at 1:09 AM, Gary Gregory (JIRA) 



> NoClassDefFoundError when starting app on Google App Engine
> ---
>
> Key: LOG4J2-1051
> URL: https://issues.apache.org/jira/browse/LOG4J2-1051
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
> Environment: master branch, JDK7, Google App Engine, Apache Struts 2.5
>Reporter: Lukasz Lenart
>Assignee: Remko Popma
> Fix For: 2.4, 2.7
>
>
> I have an app that uses
> - log4j-api
> - log4j-core
> - log4j-web
> and after deploying it to GAE I see such exception in the logs
> {noformat}
> 2015-06-10 23:01:05.768
> Uncaught exception from servlet
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.logging.log4j.core.util.Loader
>   at 
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:114)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:105)
>   at 
> org.apache.logging.log4j.core.config.NullConfiguration.(NullConfiguration.java:30)
>   at 
> org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:62)
>   at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:145)
>   at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:70)
>   at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:57)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:142)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:42)
>   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:175)
>   at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:426)
>   at 
> org.apache.struts2.tiles.StrutsTilesListener.(StrutsTilesListener.java:50)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>   at java.lang.Class.newInstance(Class.java:375)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:650)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:631)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:368)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:289)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:180)
>   at 
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1247)
>   at 
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
>   at 
> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
>   at 
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>   at 
> com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler(AppVersionHandlerMap.java:199)
>   at 
> com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler(AppVersionHandlerMap.java:174)
>   at 
> com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:134)
>   at 
> com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:527)
>   at 
> com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:437)
>   at 
> com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:444)
>   at 
> com.google.tracing.CurrentContext.runInContext(CurrentContext.java:230)
>   at 
> com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:308)
>   at 
> com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:300)
>   at 
> 

[jira] [Commented] (LOG4J2-1051) NoClassDefFoundError when starting app on Google App Engine

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508775#comment-15508775
 ] 

Gary Gregory commented on LOG4J2-1051:
--

Please try the 2.6.3-SNAPSHOT files from our SNAPSHOT repository: 
https://repository.apache.org/content/repositories/snapshots/

I just uploaded a fresh build.

What happens with those?

Gary


> NoClassDefFoundError when starting app on Google App Engine
> ---
>
> Key: LOG4J2-1051
> URL: https://issues.apache.org/jira/browse/LOG4J2-1051
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
> Environment: master branch, JDK7, Google App Engine, Apache Struts 2.5
>Reporter: Lukasz Lenart
>Assignee: Remko Popma
> Fix For: 2.4, 2.7
>
>
> I have an app that uses
> - log4j-api
> - log4j-core
> - log4j-web
> and after deploying it to GAE I see such exception in the logs
> {noformat}
> 2015-06-10 23:01:05.768
> Uncaught exception from servlet
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.logging.log4j.core.util.Loader
>   at 
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:114)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:105)
>   at 
> org.apache.logging.log4j.core.config.NullConfiguration.(NullConfiguration.java:30)
>   at 
> org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:62)
>   at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:145)
>   at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:70)
>   at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:57)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:142)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:42)
>   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:175)
>   at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:426)
>   at 
> org.apache.struts2.tiles.StrutsTilesListener.(StrutsTilesListener.java:50)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>   at java.lang.Class.newInstance(Class.java:375)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:650)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:631)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:368)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:289)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:180)
>   at 
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1247)
>   at 
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
>   at 
> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
>   at 
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>   at 
> com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler(AppVersionHandlerMap.java:199)
>   at 
> com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler(AppVersionHandlerMap.java:174)
>   at 
> com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:134)
>   at 
> com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:527)
>   at 
> com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:437)
>   at 
> com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:444)
>   at 
> com.google.tracing.CurrentContext.runInContext(CurrentContext.java:230)
>   at 
> com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:308)
>   at 
> com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:300)
>   at 
> com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:441)
>   at 
> 

[jira] [Commented] (LOG4J2-1051) NoClassDefFoundError when starting app on Google App Engine

[Frank Conover (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508725#comment-15508725
 ] 

Frank Conover commented on LOG4J2-1051:
---

I see the following with 2.6.2 and the latest api snapshots; only when I use a 
SecurityManager.

2016-09-21 00:26:33,100 main ERROR Unable to create Lookup for jvmrunargs 
java.lang.IllegalArgumentException: java.lang.NoClassDefFoundError: Could not 
initialize class 
org.apache.logging.log4j.core.lookup.JmxRuntimeInputArgumentsLookup
at 
org.apache.logging.log4j.core.util.ReflectionUtil.instantiate(ReflectionUtil.java:192)
at 
org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:66)
at 
org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:467)
at 
org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:219)
at 
org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:231)
at 
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:496)
at 
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:566)
at 
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:582)
at 
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:217)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:242)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:618)
at 
org.apache.logging.log4j.LogManager.getRootLogger(LogManager.java:652)
...
Caused by: java.lang.NoClassDefFoundError: Could not initialize class 
org.apache.logging.log4j.core.lookup.JmxRuntimeInputArgumentsLookup
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at 
org.apache.logging.log4j.core.util.ReflectionUtil.instantiate(ReflectionUtil.java:188)
... 17 more


> NoClassDefFoundError when starting app on Google App Engine
> ---
>
> Key: LOG4J2-1051
> URL: https://issues.apache.org/jira/browse/LOG4J2-1051
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
> Environment: master branch, JDK7, Google App Engine, Apache Struts 2.5
>Reporter: Lukasz Lenart
>Assignee: Remko Popma
> Fix For: 2.4, 2.7
>
>
> I have an app that uses
> - log4j-api
> - log4j-core
> - log4j-web
> and after deploying it to GAE I see such exception in the logs
> {noformat}
> 2015-06-10 23:01:05.768
> Uncaught exception from servlet
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.logging.log4j.core.util.Loader
>   at 
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:114)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:105)
>   at 
> org.apache.logging.log4j.core.config.NullConfiguration.(NullConfiguration.java:30)
>   at 
> org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:62)
>   at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:145)
>   at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:70)
>   at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:57)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:142)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:42)
>   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:175)
>   at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:426)
>   at 
> org.apache.struts2.tiles.StrutsTilesListener.(StrutsTilesListener.java:50)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>   at 

Re: Bit twiddling in org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

[Greg Thomas]

As was Objects.hashcode(...). 

Sorry for the noise, as you were ...

Greg
-- 
Sent from my iPhone

> On 21 Sep 2016, at 03:17, Remko Popma  wrote:
> 
> Sorry I was thinking of Long.hashCode(long), but I see now that this was 
> introduced in java 1.8...
> 
> Sent from my iPhone
> 
>> On 2016/09/21, at 10:09, Gary Gregory  wrote:
>> 
>> Where do you see such a method?
>> 
>> Gary
>> 
>>> On Tue, Sep 20, 2016 at 4:43 PM, Remko Popma  wrote:
>>> Objects.hashCode(long) does exactly the same, but is certainly easier to 
>>> read. Go for it!
>>> 
>>> Sent from my iPhone
>>> 
 On 2016/09/21, at 5:06, Greg Thomas  wrote:
 
 Could you use simply
 
 return Objects.hashcode(...)
 
 To avoid the maths In the first place ??
 -- 
 Sent from my iPhone
 
> On 20 Sep 2016, at 19:53, Gary Gregory  wrote:
> 
> I see a Findbugs error in:
> 
> org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()
> 
> for:
> 
> result = 31 * result + (threadPriority ^ (threadPriority >>> 32));
> 
> "The code performs shift of a 32 bit int by a constant amount outside the 
> range -31..31. The effect of this is to use the lower 5 bits of the 
> integer value to decide how much to shift by (e.g., shifting by 40 bits 
> is the same as shifting by 8 bits, and shifting by 32 bits is the same as 
> shifting by zero bits). This probably isn't what was expected, and it is 
> at least confusing."
> 
> Thoughts?
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>> 
>> 
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory

Re: Bit twiddling in org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

[Remko Popma]

Sorry I was thinking of Long.hashCode(long), but I see now that this was 
introduced in java 1.8...

Sent from my iPhone

> On 2016/09/21, at 10:09, Gary Gregory  wrote:
> 
> Where do you see such a method?
> 
> Gary
> 
>> On Tue, Sep 20, 2016 at 4:43 PM, Remko Popma  wrote:
>> Objects.hashCode(long) does exactly the same, but is certainly easier to 
>> read. Go for it!
>> 
>> Sent from my iPhone
>> 
>>> On 2016/09/21, at 5:06, Greg Thomas  wrote:
>>> 
>>> Could you use simply
>>> 
>>> return Objects.hashcode(...)
>>> 
>>> To avoid the maths In the first place ??
>>> -- 
>>> Sent from my iPhone
>>> 
 On 20 Sep 2016, at 19:53, Gary Gregory  wrote:
 
 I see a Findbugs error in:
 
 org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()
 
 for:
 
 result = 31 * result + (threadPriority ^ (threadPriority >>> 32));
 
 "The code performs shift of a 32 bit int by a constant amount outside the 
 range -31..31. The effect of this is to use the lower 5 bits of the 
 integer value to decide how much to shift by (e.g., shifting by 40 bits is 
 the same as shifting by 8 bits, and shifting by 32 bits is the same as 
 shifting by zero bits). This probably isn't what was expected, and it is 
 at least confusing."
 
 Thoughts?
 
 Gary
 
 -- 
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
 Java Persistence with Hibernate, Second Edition
 JUnit in Action, Second Edition
 Spring Batch in Action
 Blog: http://garygregory.wordpress.com 
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

Jenkins build is back to stable : Log4j 2.x #2340

[Apache Jenkins Server]

See 


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

[jira] [Commented] (LOG4J2-1010) Injectable context properties

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508383#comment-15508383
 ] 

Remko Popma commented on LOG4J2-1010:
-

I was unable to work on this yesterday but I will try to address this tonight.

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> is not so useful since JVM threads might not be coupled to the logical flow 
> of the application.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: logging-log4j2 git commit: Add equals() and hashCode() since Log4jLogEvent's equals() and hashCode() depends on them, all implementors should implement these methods.

[Gary Gregory]

It has to be in the contract (the interface) because it signals the intent
and expectation formally. That, and it let's the compiler's lint pass
(depending on the compiler), tooling, and FindBugs provide better feedback.

Gary

On Tue, Sep 20, 2016 at 5:03 PM, Remko Popma  wrote:

> It may be more effective to add a "note to implementors" to that effect in
> the javadoc.
> Programmers are more likely to follow your advice if they know the reason
> behind it.
>
> Sent from my iPhone
>
> > On 2016/09/21, at 8:29, ggreg...@apache.org wrote:
> >
> > Repository: logging-log4j2
> > Updated Branches:
> >  refs/heads/master 08a529fbb -> 436416b99
> >
> >
> > Add equals() and hashCode() since Log4jLogEvent's equals() and
> > hashCode() depends on them, all implementors should implement these
> > methods.
> >
> > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> commit/436416b9
> > Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
> 436416b9
> > Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
> 436416b9
> >
> > Branch: refs/heads/master
> > Commit: 436416b990fe7f405cc4b57aa5ea2dae1ea04518
> > Parents: 08a529f
> > Author: Gary Gregory 
> > Authored: Tue Sep 20 16:29:18 2016 -0700
> > Committer: Gary Gregory 
> > Committed: Tue Sep 20 16:29:18 2016 -0700
> >
> > --
> > .../logging/log4j/spi/MutableContextData.java | 18
> ++
> > 1 file changed, 18 insertions(+)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> 436416b9/log4j-api/src/main/java/org/apache/logging/log4j/
> spi/MutableContextData.java
> > --
> > diff --git 
> > a/log4j-api/src/main/java/org/apache/logging/log4j/spi/MutableContextData.java
> b/log4j-api/src/main/java/org/apache/logging/log4j/spi/
> MutableContextData.java
> > index 96251ef..346ea35 100644
> > --- a/log4j-api/src/main/java/org/apache/logging/log4j/spi/
> MutableContextData.java
> > +++ b/log4j-api/src/main/java/org/apache/logging/log4j/spi/
> MutableContextData.java
> > @@ -80,4 +80,22 @@ public interface MutableContextData extends
> ContextData {
> >  * @return  {@code true} if this object has been {@linkplain
> #freeze() frozen}, {@code false} otherwise
> >  */
> > boolean isFrozen();
> > +
> > +/**
> > + * Returns a hash code value for the object.
> > + * @return a hash code value for this object.
> > + */
> > +@Override
> > +int hashCode();
> > +
> > +/**
> > + * Indicates whether some other object is "equal to" this one.
> > + *
> > + * @param obj
> > + *the reference object with which to compare.
> > + * @return {@code true} if this object is the same as the obj
> argument; {@code false} otherwise.
> > + * @see #hashCode()
> > + */
> > +@Override
> > +boolean equals(final Object obj);
> > }
> > \ No newline at end of file
> >
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Bit twiddling in org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

[Gary Gregory]

Where do you see such a method?

Gary

On Tue, Sep 20, 2016 at 4:43 PM, Remko Popma  wrote:

> Objects.hashCode(long) does exactly the same, but is certainly easier to
> read. Go for it!
>
> Sent from my iPhone
>
> On 2016/09/21, at 5:06, Greg Thomas  wrote:
>
> Could you use simply
>
> return Objects.hashcode(...)
>
> To avoid the maths In the first place ??
> --
> Sent from my iPhone
>
> On 20 Sep 2016, at 19:53, Gary Gregory  wrote:
>
> I see a Findbugs error in:
>
> org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()
>
> for:
>
> result = 31 * result + (threadPriority ^ (threadPriority >>> 32));
>
> "The code performs shift of a 32 bit int by a constant amount outside the
> range -31..31. The effect of this is to use the lower 5 bits of the integer
> value to decide how much to shift by (e.g., shifting by 40 bits is the same
> as shifting by 8 bits, and shifting by 32 bits is the same as shifting by
> zero bits). This probably isn't what was expected, and it is at least
> confusing."
>
> Thoughts?
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[jira] [Closed] (LOG4J2-1599) Prevent potential NPE in org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder, char[], int, Object[], int, int[])

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-1599.

Resolution: Fixed

> Prevent potential NPE in 
> org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder,
>  char[], int, Object[], int, int[])
> -
>
> Key: LOG4J2-1599
> URL: https://issues.apache.org/jira/browse/LOG4J2-1599
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder,
>  char[], int, Object[], int, int[]) if messagePattern is null.
> As reported by FindBugs when calling {{buffer.append(messagePattern);}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: NPE's reported by FindBugs

[Gary Gregory]

Done.

Gary

On Tue, Sep 20, 2016 at 6:04 PM, Gary Gregory 
wrote:

> Sure, will do.
>
> Gary
>
> On Tue, Sep 20, 2016 at 4:40 PM, Remko Popma 
> wrote:
>
>> It's good to prevent potential NPEs of course, but in the release notes
>> (changes.xml) can we change the explanation to _prevented potential_ NPEs?
>>
>> As it stands the release notes make it look like we're having massive
>> issues with NullPointerExceptions...
>>
>> Sent from my iPhone
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[jira] [Updated] (LOG4J2-1599) Prevent potential NPE in org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder, char[], int, Object[], int, int[])

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1599:
-
Summary: Prevent potential NPE in 
org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder,
 char[], int, Object[], int, int[])  (was: NPE in 
org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder,
 char[], int, Object[], int, int[]))

> Prevent potential NPE in 
> org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder,
>  char[], int, Object[], int, int[])
> -
>
> Key: LOG4J2-1599
> URL: https://issues.apache.org/jira/browse/LOG4J2-1599
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder,
>  char[], int, Object[], int, int[]) if messagePattern is null.
> As reported by FindBugs when calling {{buffer.append(messagePattern);}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Reopened] (LOG4J2-1600) NPE due to org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[], String, boolean, boolean, Configuration)

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory reopened LOG4J2-1600:
--

> NPE due to 
> org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)
> -
>
> Key: LOG4J2-1600
> URL: https://issues.apache.org/jira/browse/LOG4J2-1600
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> {{org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)}}
> If PatternMatch[] is null, you'll get an NPE in 
> {{org.apache.logging.log4j.core.layout.MarkerPatternSelector.MarkerPatternSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)}}.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-1601) Prevent potential NPE due to org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript, PatternMatch[], String, boolean, boolean, Configur

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1601:
-
Summary: Prevent potential NPE due to 
org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
 PatternMatch[], String, boolean, boolean, Configuration)  (was: NPE due to 
org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
 PatternMatch[], String, boolean, boolean, Configuration))

> Prevent potential NPE due to 
> org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)
> ---
>
> Key: LOG4J2-1601
> URL: https://issues.apache.org/jira/browse/LOG4J2-1601
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE due to 
> {{org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)}} if 
> {{PatternMatch[]}} is null in 
> {{org.apache.logging.log4j.core.layout.ScriptPatternSelector.ScriptPatternSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)}}.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (LOG4J2-1601) Prevent potential NPE due to org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript, PatternMatch[], String, boolean, boolean, Configura

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-1601.

Resolution: Fixed

> Prevent potential NPE due to 
> org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)
> ---
>
> Key: LOG4J2-1601
> URL: https://issues.apache.org/jira/browse/LOG4J2-1601
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE due to 
> {{org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)}} if 
> {{PatternMatch[]}} is null in 
> {{org.apache.logging.log4j.core.layout.ScriptPatternSelector.ScriptPatternSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)}}.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (LOG4J2-1600) Prevent potential NPE due to org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[], String, boolean, boolean, Configuration)

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-1600.

Resolution: Fixed

> Prevent potential NPE due to 
> org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)
> ---
>
> Key: LOG4J2-1600
> URL: https://issues.apache.org/jira/browse/LOG4J2-1600
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> {{org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)}}
> If PatternMatch[] is null, you'll get an NPE in 
> {{org.apache.logging.log4j.core.layout.MarkerPatternSelector.MarkerPatternSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)}}.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Reopened] (LOG4J2-1599) NPE in org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder, char[], int, Object[], int, int[])

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory reopened LOG4J2-1599:
--

> NPE in 
> org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder,
>  char[], int, Object[], int, int[])
> ---
>
> Key: LOG4J2-1599
> URL: https://issues.apache.org/jira/browse/LOG4J2-1599
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder,
>  char[], int, Object[], int, int[]) if messagePattern is null.
> As reported by FindBugs when calling {{buffer.append(messagePattern);}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-1600) Prevent potential NPE due to org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[], String, boolean, boolean, Configuration)

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1600:
-
Summary: Prevent potential NPE due to 
org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
 String, boolean, boolean, Configuration)  (was: NPE due to 
org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
 String, boolean, boolean, Configuration))

> Prevent potential NPE due to 
> org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)
> ---
>
> Key: LOG4J2-1600
> URL: https://issues.apache.org/jira/browse/LOG4J2-1600
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> {{org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)}}
> If PatternMatch[] is null, you'll get an NPE in 
> {{org.apache.logging.log4j.core.layout.MarkerPatternSelector.MarkerPatternSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)}}.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Reopened] (LOG4J2-1601) NPE due to org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript, PatternMatch[], String, boolean, boolean, Configuration)

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory reopened LOG4J2-1601:
--

> NPE due to 
> org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)
> -
>
> Key: LOG4J2-1601
> URL: https://issues.apache.org/jira/browse/LOG4J2-1601
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE due to 
> {{org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)}} if 
> {{PatternMatch[]}} is null in 
> {{org.apache.logging.log4j.core.layout.ScriptPatternSelector.ScriptPatternSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)}}.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-1602) Prevent potential NPE in org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object) when object is null

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1602:
-
Summary: Prevent potential NPE in 
org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
 when object is null  (was: Prevented potential NPE in 
org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
 when object is null)

> Prevent potential NPE in 
> org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
>  when object is null
> 
>
> Key: LOG4J2-1602
> URL: https://issues.apache.org/jira/browse/LOG4J2-1602
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
>  when object is null.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (LOG4J2-1602) Prevent potential NPE in org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object) when object is null

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-1602.

Resolution: Fixed

> Prevent potential NPE in 
> org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
>  when object is null
> 
>
> Key: LOG4J2-1602
> URL: https://issues.apache.org/jira/browse/LOG4J2-1602
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
>  when object is null.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-1602) Prevented potential NPE in org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object) when object is null

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1602:
-
Summary: Prevented potential NPE in 
org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
 when object is null  (was: NPE in 
org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
 when object is null)

> Prevented potential NPE in 
> org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
>  when object is null
> --
>
> Key: LOG4J2-1602
> URL: https://issues.apache.org/jira/browse/LOG4J2-1602
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
>  when object is null.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Reopened] (LOG4J2-1602) NPE in org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object) when object is null

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory reopened LOG4J2-1602:
--

> NPE in 
> org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
>  when object is null
> --
>
> Key: LOG4J2-1602
> URL: https://issues.apache.org/jira/browse/LOG4J2-1602
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
>  when object is null.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: NPE's reported by FindBugs

[Gary Gregory]

Sure, will do.

Gary

On Tue, Sep 20, 2016 at 4:40 PM, Remko Popma  wrote:

> It's good to prevent potential NPEs of course, but in the release notes
> (changes.xml) can we change the explanation to _prevented potential_ NPEs?
>
> As it stands the release notes make it look like we're having massive
> issues with NullPointerExceptions...
>
> Sent from my iPhone
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[jira] [Commented] (LOG4J2-1010) Injectable context properties

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508223#comment-15508223
 ] 

Ralph Goers commented on LOG4J2-1010:
-

If it is immutable then I would think you could just always return the same 
instance.

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> is not so useful since JVM threads might not be coupled to the logical flow 
> of the application.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Jenkins build became unstable: Log4j 2.x #2339

[Apache Jenkins Server]

See 


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

Re: logging-log4j2 git commit: Add equals() and hashCode() since Log4jLogEvent's equals() and hashCode() depends on them, all implementors should implement these methods.

[Remko Popma]

It may be more effective to add a "note to implementors" to that effect in the 
javadoc. 
Programmers are more likely to follow your advice if they know the reason 
behind it.

Sent from my iPhone

> On 2016/09/21, at 8:29, ggreg...@apache.org wrote:
> 
> Repository: logging-log4j2
> Updated Branches:
>  refs/heads/master 08a529fbb -> 436416b99
> 
> 
> Add equals() and hashCode() since Log4jLogEvent's equals() and
> hashCode() depends on them, all implementors should implement these
> methods.
> 
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/436416b9
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/436416b9
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/436416b9
> 
> Branch: refs/heads/master
> Commit: 436416b990fe7f405cc4b57aa5ea2dae1ea04518
> Parents: 08a529f
> Author: Gary Gregory 
> Authored: Tue Sep 20 16:29:18 2016 -0700
> Committer: Gary Gregory 
> Committed: Tue Sep 20 16:29:18 2016 -0700
> 
> --
> .../logging/log4j/spi/MutableContextData.java | 18 ++
> 1 file changed, 18 insertions(+)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/436416b9/log4j-api/src/main/java/org/apache/logging/log4j/spi/MutableContextData.java
> --
> diff --git 
> a/log4j-api/src/main/java/org/apache/logging/log4j/spi/MutableContextData.java
>  
> b/log4j-api/src/main/java/org/apache/logging/log4j/spi/MutableContextData.java
> index 96251ef..346ea35 100644
> --- 
> a/log4j-api/src/main/java/org/apache/logging/log4j/spi/MutableContextData.java
> +++ 
> b/log4j-api/src/main/java/org/apache/logging/log4j/spi/MutableContextData.java
> @@ -80,4 +80,22 @@ public interface MutableContextData extends ContextData {
>  * @return  {@code true} if this object has been {@linkplain #freeze() 
> frozen}, {@code false} otherwise
>  */
> boolean isFrozen();
> +
> +/**
> + * Returns a hash code value for the object.
> + * @return a hash code value for this object.
> + */
> +@Override
> +int hashCode();
> +
> +/**
> + * Indicates whether some other object is "equal to" this one.
> + * 
> + * @param obj
> + *the reference object with which to compare.
> + * @return {@code true} if this object is the same as the obj argument; 
> {@code false} otherwise.
> + * @see #hashCode()
> + */
> +@Override
> +boolean equals(final Object obj);
> }
> \ No newline at end of file
> 

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

Re: Bit twiddling in org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

[Remko Popma]

Objects.hashCode(long) does exactly the same, but is certainly easier to read. 
Go for it!

Sent from my iPhone

> On 2016/09/21, at 5:06, Greg Thomas  wrote:
> 
> Could you use simply
> 
> return Objects.hashcode(...)
> 
> To avoid the maths In the first place ??
> -- 
> Sent from my iPhone
> 
>> On 20 Sep 2016, at 19:53, Gary Gregory  wrote:
>> 
>> I see a Findbugs error in:
>> 
>> org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()
>> 
>> for:
>> 
>> result = 31 * result + (threadPriority ^ (threadPriority >>> 32));
>> 
>> "The code performs shift of a 32 bit int by a constant amount outside the 
>> range -31..31. The effect of this is to use the lower 5 bits of the integer 
>> value to decide how much to shift by (e.g., shifting by 40 bits is the same 
>> as shifting by 8 bits, and shifting by 32 bits is the same as shifting by 
>> zero bits). This probably isn't what was expected, and it is at least 
>> confusing."
>> 
>> Thoughts?
>> 
>> Gary
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory

NPE's reported by FindBugs

[Remko Popma]

It's good to prevent potential NPEs of course, but in the release notes 
(changes.xml) can we change the explanation to _prevented potential_ NPEs?

As it stands the release notes make it look like we're having massive issues 
with NullPointerExceptions...

Sent from my iPhone
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Bug in pattern or usage

[Gary Gregory]

We have code like this in a couple of places:

final String search = String.format(StatusLoggerAdminMBean.PATTERN,
escape(contextName), "*");


Where:

String PATTERN = Server.DOMAIN + ":type=%s,component=StatusLogger";

And:

public static final String DOMAIN = "org.apache.logging.log4j2";

So of course the "*" is not used.

Is the bug that we have a missing parameter marker in the pattern or that
we should not pass the extra argument?

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Jenkins build is back to stable : Log4j 2.x #2338

[Apache Jenkins Server]

See 


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

[jira] [Created] (LOG4J2-1603) Redo hashCode() and equals() methods in org.apache.logging.log4j.core.net.ssl classes.

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-1603:


 Summary: Redo hashCode() and equals() methods in 
org.apache.logging.log4j.core.net.ssl classes.
 Key: LOG4J2-1603
 URL: https://issues.apache.org/jira/browse/LOG4J2-1603
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.6.2
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 2.7


We have a few FindBugs warnings about {{hashCode()}} and {{equals(Object)}} 
methods in the package {{org.apache.logging.log4j.core.net.ssl}} classes.

The first problem is that not all classes implement these method where some of 
the code expects it to like an {{equals()}} method calling another {{equals()}} 
method but there is not one and the behavior of {{Object.equals()}} kicks in.

This change make it obvious where there are still issues: the behavior 
described above will only happen when the code path ends up in a JRE class 
which itself depends on {{Object.equals()}}, so you still get a FindBugs 
warning about that but it is no longer a warning about a class in our code. We 
can revisit how to best implement {{equals()}} for those classes later.

It is possible that the warning is a false positive since the JRE could be 
using a subclass of the class FindBugs complains about.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (LOG4J2-1602) NPE in org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object) when object is null

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-1602.

Resolution: Fixed

In Git master.

> NPE in 
> org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
>  when object is null
> --
>
> Key: LOG4J2-1602
> URL: https://issues.apache.org/jira/browse/LOG4J2-1602
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
>  when object is null.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LOG4J2-1602) NPE in org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object) when object is null

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-1602:


 Summary: NPE in 
org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
 when object is null
 Key: LOG4J2-1602
 URL: https://issues.apache.org/jira/browse/LOG4J2-1602
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.6.2
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 2.7


NPE in 
org.apache.logging.log4j.core.util.datetime.FormatCache.MultipartKey.equals(Object)
 when object is null.

Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Jenkins build became unstable: Log4j 2.x #2337

[Apache Jenkins Server]

See 


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

Re: Bit twiddling in org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

[Greg Thomas]

Could you use simply

return Objects.hashcode(...)

To avoid the maths In the first place ??
-- 
Sent from my iPhone

> On 20 Sep 2016, at 19:53, Gary Gregory  wrote:
> 
> I see a Findbugs error in:
> 
> org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()
> 
> for:
> 
> result = 31 * result + (threadPriority ^ (threadPriority >>> 32));
> 
> "The code performs shift of a 32 bit int by a constant amount outside the 
> range -31..31. The effect of this is to use the lower 5 bits of the integer 
> value to decide how much to shift by (e.g., shifting by 40 bits is the same 
> as shifting by 8 bits, and shifting by 32 bits is the same as shifting by 
> zero bits). This probably isn't what was expected, and it is at least 
> confusing."
> 
> Thoughts?
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

[jira] [Closed] (LOG4J2-1601) NPE due to org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript, PatternMatch[], String, boolean, boolean, Configuration)

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-1601.

Resolution: Fixed

In Git master.

> NPE due to 
> org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)
> -
>
> Key: LOG4J2-1601
> URL: https://issues.apache.org/jira/browse/LOG4J2-1601
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE due to 
> {{org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)}} if 
> {{PatternMatch[]}} is null in 
> {{org.apache.logging.log4j.core.layout.ScriptPatternSelector.ScriptPatternSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)}}.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-1601) NPE due to org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript, PatternMatch[], String, boolean, boolean, Configuration)

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1601:
-
Description: 
NPE due to 
{{org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
 PatternMatch[], String, boolean, boolean, Configuration)}} if 
{{PatternMatch[]}} is null in 
{{org.apache.logging.log4j.core.layout.ScriptPatternSelector.ScriptPatternSelector(AbstractScript,
 PatternMatch[], String, boolean, boolean, Configuration)}}.

Reported by FindBugs.

  was:NPE due to 
{{org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
 PatternMatch[], String, boolean, boolean, Configuration)}} if 
{{PatternMatch[]}} is null in 
{{org.apache.logging.log4j.core.layout.ScriptPatternSelector.ScriptPatternSelector(AbstractScript,
 PatternMatch[], String, boolean, boolean, Configuration)}}.


> NPE due to 
> org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)
> -
>
> Key: LOG4J2-1601
> URL: https://issues.apache.org/jira/browse/LOG4J2-1601
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE due to 
> {{org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)}} if 
> {{PatternMatch[]}} is null in 
> {{org.apache.logging.log4j.core.layout.ScriptPatternSelector.ScriptPatternSelector(AbstractScript,
>  PatternMatch[], String, boolean, boolean, Configuration)}}.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LOG4J2-1601) NPE due to org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript, PatternMatch[], String, boolean, boolean, Configuration)

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-1601:


 Summary: NPE due to 
org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
 PatternMatch[], String, boolean, boolean, Configuration)
 Key: LOG4J2-1601
 URL: https://issues.apache.org/jira/browse/LOG4J2-1601
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.6.2
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 2.7


NPE due to 
{{org.apache.logging.log4j.core.layout.ScriptPatternSelector.createSelector(AbstractScript,
 PatternMatch[], String, boolean, boolean, Configuration)}} if 
{{PatternMatch[]}} is null in 
{{org.apache.logging.log4j.core.layout.ScriptPatternSelector.ScriptPatternSelector(AbstractScript,
 PatternMatch[], String, boolean, boolean, Configuration)}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (LOG4J2-1600) NPE due to org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[], String, boolean, boolean, Configuration)

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-1600.

   Resolution: Fixed
Fix Version/s: 2.7

In Git master.

> NPE due to 
> org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)
> -
>
> Key: LOG4J2-1600
> URL: https://issues.apache.org/jira/browse/LOG4J2-1600
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> {{org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)}}
> If PatternMatch[] is null, you'll get an NPE in 
> {{org.apache.logging.log4j.core.layout.MarkerPatternSelector.MarkerPatternSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Reopened] (LOG4J2-1600) NPE due to org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[], String, boolean, boolean, Configuration)

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory reopened LOG4J2-1600:
--

> NPE due to 
> org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)
> -
>
> Key: LOG4J2-1600
> URL: https://issues.apache.org/jira/browse/LOG4J2-1600
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> {{org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)}}
> If PatternMatch[] is null, you'll get an NPE in 
> {{org.apache.logging.log4j.core.layout.MarkerPatternSelector.MarkerPatternSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (LOG4J2-1600) NPE due to org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[], String, boolean, boolean, Configuration)

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-1600.

Resolution: Fixed

> NPE due to 
> org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)
> -
>
> Key: LOG4J2-1600
> URL: https://issues.apache.org/jira/browse/LOG4J2-1600
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> {{org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)}}
> If PatternMatch[] is null, you'll get an NPE in 
> {{org.apache.logging.log4j.core.layout.MarkerPatternSelector.MarkerPatternSelector(PatternMatch[],
>  String, boolean, boolean, Configuration)}}.
> Reported by FindBugs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LOG4J2-1600) NPE due to org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[], String, boolean, boolean, Configuration)

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-1600:


 Summary: NPE due to 
org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
 String, boolean, boolean, Configuration)
 Key: LOG4J2-1600
 URL: https://issues.apache.org/jira/browse/LOG4J2-1600
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.6.2
Reporter: Gary Gregory
Assignee: Gary Gregory


NPE in 
{{org.apache.logging.log4j.core.layout.MarkerPatternSelector.createSelector(PatternMatch[],
 String, boolean, boolean, Configuration)}}

If PatternMatch[] is null, you'll get an NPE in 
{{org.apache.logging.log4j.core.layout.MarkerPatternSelector.MarkerPatternSelector(PatternMatch[],
 String, boolean, boolean, Configuration)}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

org.apache.logging.log4j.core.script.ScriptManager.addScript(AbstractScript)

[Gary Gregory]

We have no removeScript API here, which I would use for scripts that are
run only once per configuration.

Thoughts?

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Bit twiddling in org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

[Gary Gregory]

I see a Findbugs error in:

org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

for:

result = 31 * result + (threadPriority ^ (threadPriority >>> 32));

"The code performs shift of a 32 bit int by a constant amount outside the
range -31..31. The effect of this is to use the lower 5 bits of the integer
value to decide how much to shift by (e.g., shifting by 40 bits is the same
as shifting by 8 bits, and shifting by 32 bits is the same as shifting by
zero bits). This probably isn't what was expected, and it is at least
confusing."

Thoughts?

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[jira] [Closed] (LOG4J2-1599) NPE in org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder, char[], int, Object[], int, int[])

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-1599.

   Resolution: Fixed
 Assignee: Gary Gregory
Fix Version/s: 2.7

In Git master.

> NPE in 
> org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder,
>  char[], int, Object[], int, int[])
> ---
>
> Key: LOG4J2-1599
> URL: https://issues.apache.org/jira/browse/LOG4J2-1599
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> NPE in 
> org.apache.logging.log4j.message.ParameterFormatter.formatMessage3(StringBuilder,
>  char[], int, Object[], int, int[]) if messagePattern is null.
> As reported by FindBugs when calling {{buffer.append(messagePattern);}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507277#comment-15507277
 ] 

Gary Gregory commented on LOG4J2-1259:
--

Are you able to test our Git master?

> Log4j threads are leaking on Tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown

[Gabriel Stanek (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507208#comment-15507208
 ] 

Gabriel Stanek commented on LOG4J2-1259:


Great, thank you!

> Log4j threads are leaking on Tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown

[Matt Sicker (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506777#comment-15506777
 ] 

Matt Sicker commented on LOG4J2-1259:
-

It'll be in 2.7, and we're getting read to release that within the next week or 
so. We almost began a release yesterday, but we found a regression we're 
investigating first.

> Log4j threads are leaking on Tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown

[Gabriel Stanek (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506734#comment-15506734
 ] 

Gabriel Stanek commented on LOG4J2-1259:


Hello [~garydgregory] - could you confirm which official release this change 
will be a part of, and what date that release is scheduled for?

> Log4j threads are leaking on Tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are available on java.net

[Rory O'Donnell]

Hi Nick,

Early Access b136  for JDK 9 is 
available on java.net, summary of  changes are listed here 
.
Early Access b136  (#5506) for JDK 9 with 
Project Jigsaw is available on java.net, summary of  changes are listed 
here 
.


There have been a number of fixes to bugs reported by Open Source 
projects since the last availability email  :


 * 8165723 - b136 - core-libs JarFile::isMultiRelease() method returns
   false when it should return true
 * 8165116 - b136 - xml redirect function is not allowed even with
   enableExtensionFunctions

NOTE:-  Build 135 included a fix for JDK-8161016 which *has introduced a 
behavioral change to HttpURLConnection, more info:*


The behavior of HttpURLConnection when using a ProxySelector has been 
modified with this JDK release. Currently, HttpURLConnection.connect() 
call would fallback to a DIRECT connection attempt if the configured 
proxy/proxies failed to make a connection. This release introduces a 
change whereby no DIRECT connection will be attempted in such a 
scenario. Instead, the HttpURLConnection.connect() method will fail and 
throw an IOException which occurred from the last proxy tested. This 
behavior now matches with the HTTP connections made by popular web 
browsers. But this change will bring compatibility issues for the 
applications expecting a DIRECT connection when a proxy server is down 
or when wrong proxies are provided.

*

JDK 9 Outreach Survey*

In order to encourage and receive additional feedback from developers 
testing their applications with JDK 9,
the OpenJDK Quality Outreach effort has put together a very brief survey 
about your experiences with JDK 9 so far.


It is available at***https://www.surveymonkey.de/r/JDK9EA*

We would love to hear feedback from you!


Rgds,Rory

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

[jira] [Resolved] (LOG4J2-1436) Log4j2 migration tools

[JIRA]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikael Ståldal resolved LOG4J2-1436.

Resolution: Duplicate

> Log4j2 migration tools
> --
>
> Key: LOG4J2-1436
> URL: https://issues.apache.org/jira/browse/LOG4J2-1436
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Configurators, Documentation, log4j 1.2 emulation
>Reporter: Remko Popma
> Fix For: 2.8
>
>
> TODO verify the status of the below projects and link to them from the site:
> http://log4j-props2xml.appspot.com/ 
> https://github.com/jroyals/log4j-properties-converter/
> https://github.com/mulesoft-labs/log4j2-migrator
> Also, consider adding separate pages for
> * Migrating to Log4j 2 from Logback
> * Migrating to Log4j 2 from JUL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Reopened] (LOG4J2-1010) Injectable context properties

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reopened LOG4J2-1010:
-

Reopening since Ralph found that the FilterPerformanceComparison performance 
test showed a large performance regression.

The cause of the regression is that a new context data instance is created for 
each call to getMutableContextData() if the thread context is empty.

The solution is to return a cached empty instance. Filters don't need a mutable 
instance. 

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> is not so useful since JVM threads might not be coupled to the logical flow 
> of the application.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: ThreadContextMapFilter performance

[Remko Popma]

That's obviously not good. 
Looking at this now. 

Sent from my iPhone

> On 2016/09/20, at 15:33, Ralph Goers  wrote:
> 
> I started the release process tonight but stopped it when I noticed that the 
> FilterPerformanceComparison test is now taking over 200 seconds to complete. 
> Where it used to be faster than Logback it is now from 3 to 60 times slower 
> depending on the number of threads.  I am assuming this is due to the changes 
> to add support for the ThreadContextInjector.  If this cannot be addressed 
> then I am going to have to ask that this feature be removed.
> 
> In the meantime a 2.7 release is on hold.
> 
> Ralph
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 

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

ThreadContextMapFilter performance

[Ralph Goers]

I started the release process tonight but stopped it when I noticed that the 
FilterPerformanceComparison test is now taking over 200 seconds to complete. 
Where it used to be faster than Logback it is now from 3 to 60 times slower 
depending on the number of threads.  I am assuming this is due to the changes 
to add support for the ThreadContextInjector.  If this cannot be addressed then 
I am going to have to ask that this feature be removed.

In the meantime a 2.7 release is on hold.

Ralph

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