Re: Java9

[Mikael Ståldal]

IntelliJ IDEA is "smart" enough to automatically pick up the 
src/main/java9 folder.



On 2017-05-21 22:26, Ralph Goers wrote:

Since src/main/java9 isn’t normally considered a source directory you should be 
able to work with Java 7 as well. It will just ignore the Java 9 files.

Ralph


On May 21, 2017, at 5:50 AM, Gary Gregory  wrote:

I set the JRE for that project to Java 9. I do not think you can set the
JRE per source folder, only per project.

Gary

On May 21, 2017 1:29 AM, "Ralph Goers"  wrote:

I’ve modified the build to put the Java 9 classes of the API into a
separate source directory. Can you see if that helps things in Eclipse?

Ralph

[jira] [Commented] (LOG4J2-1917) Log4j api should use Java's ServiceLoader to locate implememtations

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-1917:
-

Commit 92e4b875463e8dc9e4683687d3572969f39b1593 in logging-log4j2's branch 
refs/heads/LOG4J2-1442 from [~ralph_go...@dslextreme.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=92e4b87 ]

LOG4J2-1917 - Use ServiceLoader to locate implementations.


> Log4j api should use Java's ServiceLoader to locate implememtations
> ---
>
> Key: LOG4J2-1917
> URL: https://issues.apache.org/jira/browse/LOG4J2-1917
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.8.2
>Reporter: Ralph Goers
> Fix For: 2.9
>
>
> Java 9 module support requires that an API locate its implementation using 
> java.util.ServiceLoader. Although we do not plan on implementing module 
> support at this time this change is easy to implement and can be done in a 
> backward compatible manner.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [1/2] logging-log4net git commit: This migrates the visual studio solution to Visual Studio 14

[Stefan Bodewig]

As long as we keep NAnt as the build tool of truth the solution files
are "only" a convenience feature for people using VS (likely everybody
except myself :-).

Actually this is not completely true as we use "dotnet build" as well,
so it's not only NAnt.

I'd be fine with a single sln and laze votes, yes.

Stefan

On 2017-05-21, Dominik Psenner wrote:

> I hoped to hear that. keeping 4 sln in sync is a major effort with no
> profit. Do we want lazy votes when an upgrade to a new vs version is
> immanent?

> On 21 May 2017 6:02 a.m., "Stefan Bodewig"  wrote:

>> On 2017-05-19,  wrote:

>>> This migrates the visual studio solution to Visual Studio 14

>>> --
>>>  src/log4net.vs2012.csproj | 4 ++--
>>>  src/log4net.vs2012.sln| 3 +++
>>>  2 files changed, 5 insertions(+), 2 deletions(-)
>>> --

>> Given the file name and the other solution files I would have expected
>> to add a new solution and project file rather than modify the 2012 one
>> to mean 2014 now :-)

>> I wouldn't object against removing the old solutions completely and just
>> keep one version (without any year in its name).

>> Stefan

Re: [LOG4NET] gitflow

[Stefan Bodewig]

On 2017-05-21, Dominik Psenner wrote:

> To me the gitflow concept boils down to a way of tydying up the
> historical mess that piles up over the years. The branch
> feature/RollingFileAppender-NG dates actually back to 2012. I'd be
> happy already if we had a naming convention for the different branch
> types. From the branch name alone it is at the moment totally unclear
> what i.e. the log4net-1.3 branch is actually about. It is written down
> only somewhere in the mailing list archives that we have abandoned it.

I see. I'll rename it (to fix the short-term problem).

> What do you think about a simple prefix scheme for named branches like
> abandoned/x, feature/y, pullrequest/z,..? These are the three kinds of
> branches I see at the moment.

Works for me.

Stefan

[jira] [Commented] (LOG4J2-1917) Log4j api should use Java's ServiceLoader to locate implememtations

[JIRA]

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

Mikael Ståldal commented on LOG4J2-1917:


Should the version in Log4jProvider be 2.6.0?

> Log4j api should use Java's ServiceLoader to locate implememtations
> ---
>
> Key: LOG4J2-1917
> URL: https://issues.apache.org/jira/browse/LOG4J2-1917
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.8.2
>Reporter: Ralph Goers
> Fix For: 2.9
>
>
> Java 9 module support requires that an API locate its implementation using 
> java.util.ServiceLoader. Although we do not plan on implementing module 
> support at this time this change is easy to implement and can be done in a 
> backward compatible manner.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LOG4J2-1917) Log4j api should use Java's ServiceLoader to locate implememtations

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-1917:
-

Yes, that was the last version where a change was made to the API that affected 
an implementation.

> Log4j api should use Java's ServiceLoader to locate implememtations
> ---
>
> Key: LOG4J2-1917
> URL: https://issues.apache.org/jira/browse/LOG4J2-1917
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.8.2
>Reporter: Ralph Goers
> Fix For: 2.9
>
>
> Java 9 module support requires that an API locate its implementation using 
> java.util.ServiceLoader. Although we do not plan on implementing module 
> support at this time this change is easy to implement and can be done in a 
> backward compatible manner.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Antwort: [Newsletter] Re: [LOG4NET] gitflow

[Jonas . Baehr]

Hi

Gary Gregory  wrote on 19.05.2017 23:01:10:
> Howdy,
> 
> Thank you for the link.
> 
> This is fine until you want to manage more than once major version in 
one
> repo, right?
> 
> Over at HttpComponents, we have decided for now to keep to one repo, as
> opposed to one repo per major version.
> 
> So ATM for example in HttpComponents' HttpCore we have a 4.4.x and 
master
> branch that are BOTH going to be used for releases.
> 
> How do you deal with that in Gitflow?

As I understood gitflow, release branches are "short-living" branches, 
only
used for preparation of a particular release. Once the release is shipped
the branch is removed.
If you need to support several versions of your software in the field 
(e.g.
keep shipping feature updates for 2.x and 1.x; aside from hot fixes),
"support-brachnes" is what you're looking for. They behave like "the" 
develop
branch, but for supporting older version.
The GitVersion Manual has some nice example images for this:
http://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/#support-branches

Regards,
Jonas

> 
> Gary
> 
> On Fri, May 19, 2017 at 1:10 PM, Dominik Psenner  
wrote:
> 
> > Hi,
> >
> > would we like to use gitflow for our named branches? [1]
> >
> > [1] https://datasift.github.io/gitflow/IntroducingGitFlow.html
> >
> > Cheers
> > --
> > Dominik Psenner
> >
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
>  
ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8
> >
> 
>  t=garygregory-20&l=am2&o=1&a=1617290459>
> JUnit in Action, Second Edition
>  
ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%
> 22>
> 
>  t=garygregory-20&l=am2&o=1&a=1935182021>
> Spring Batch in Action
>  ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%
> 7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%
> 22%3ESpring+Batch+in+Action>
>  t=garygregory-20&l=am2&o=1&a=1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

[jira] [Commented] (LOG4NET-565) Dependency Injection support appender and logger types

[Hitesh Chauhan (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019609#comment-16019609
 ] 

Hitesh Chauhan commented on LOG4NET-565:


I disabled my VS settings. This time you can see the changes without any extra 
whitespaces.

https://github.com/TechMinder/logging-log4net/commit/9d2f5f2e11456f1173d24ad04811a8ffc7d7c5ec



> Dependency Injection support appender and logger types
> --
>
> Key: LOG4NET-565
> URL: https://issues.apache.org/jira/browse/LOG4NET-565
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders, Core
>Reporter: Hitesh Chauhan
>  Labels: Enhancement
>
> I have seen demand for dependency injection support in log4net. I have added 
> that behavior to my local repository. And I would like to push that to 
> log4net library.
> e.g. appender configuration
>  name="ServiceAppender" 
> type="LoggingServiceAppender"   
> serviceLocatorType="Log4NetServiceLocator">



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[Log4j] Scala release

[Mikael Ståldal]

How is it going with release of log4j-scala?

Re: [Log4j] Scala release

[Matt Sicker]

I haven't had any time lately to make rc2. Based on the last vote, I'm
wondering if we'll get a third vote since nobody but us two are even using
Scala. ;)

On 22 May 2017 at 09:30, Mikael Ståldal  wrote:

> How is it going with release of log4j-scala?
>
>
>


-- 
Matt Sicker 

Re: [Log4j] Scala release

[Mikael Ståldal]

If I remembered correctly, Gary was willing to test it and vote if there 
were building instructions. And now there are.



On 2017-05-22 17:01, Matt Sicker wrote:

I haven't had any time lately to make rc2. Based on the last vote, I'm
wondering if we'll get a third vote since nobody but us two are even using
Scala. ;)

On 22 May 2017 at 09:30, Mikael Ståldal  wrote:


How is it going with release of log4j-scala?

Re: [1/2] logging-log4net git commit: This migrates the visual studio solution to Visual Studio 14

[Dominik Psenner]

On 2017-05-22 13:59, Stefan Bodewig wrote:

As long as we keep NAnt as the build tool of truth the solution files
are "only" a convenience feature for people using VS (likely everybody
except myself :-).


How do you develop log4net if not with visual studio?

Plugin builder setters

[Mikael Ståldal]

What is the preferred naming convention for plugin builder setter 
methods? It is setXXX or withXXX? I see both being used in the code base.


I wonder which to use for the upcoming HttpAppender (LOG4J2-1442).

Re: Java9

[Matt Sicker]

I still want to see a better Maven plugin for handling Java 9 multi-release
jars and things like that. The whole Java 9 build is still rather hacky. If
the entire project was buildable in Java 9 and could still target 7, 8, and
9, then that would be a simpler solution IMO.

On 22 May 2017 at 06:16, Mikael Ståldal  wrote:

> IntelliJ IDEA is "smart" enough to automatically pick up the
> src/main/java9 folder.
>
>
>
> On 2017-05-21 22:26, Ralph Goers wrote:
>
>> Since src/main/java9 isn’t normally considered a source directory you
>> should be able to work with Java 7 as well. It will just ignore the Java 9
>> files.
>>
>> Ralph
>>
>> On May 21, 2017, at 5:50 AM, Gary Gregory  wrote:
>>>
>>> I set the JRE for that project to Java 9. I do not think you can set the
>>> JRE per source folder, only per project.
>>>
>>> Gary
>>>
>>> On May 21, 2017 1:29 AM, "Ralph Goers" 
>>> wrote:
>>>
>>> I’ve modified the build to put the Java 9 classes of the API into a
>>> separate source directory. Can you see if that helps things in Eclipse?
>>>
>>> Ralph
>>>
>>
>>
>


-- 
Matt Sicker 

Re: Plugin builder setters

[Gary Gregory]

I like "with" for methods that return a new instance and "set" for those
that do not.

Since most if not all of our builders don't create new instances on setter
calls I would go with "set".

2c,
Gary

Gary

On May 22, 2017 8:36 AM, "Mikael Ståldal"  wrote:

> What is the preferred naming convention for plugin builder setter methods?
> It is setXXX or withXXX? I see both being used in the code base.
>
> I wonder which to use for the upcoming HttpAppender (LOG4J2-1442).
>
>
>

Re: Plugin builder setters

[Mikael Ståldal]

SocketAppender uses "with" like this:

public B withSslConfiguration(final SslConfiguration sslConfiguration) {
this.sslConfiguration = sslConfiguration;
return asBuilder();
}

is that wrong?

On 2017-05-22 17:50, Gary Gregory wrote:

I like "with" for methods that return a new instance and "set" for those
that do not.

Since most if not all of our builders don't create new instances on setter
calls I would go with "set".

2c,
Gary

Gary

On May 22, 2017 8:36 AM, "Mikael Ståldal"  wrote:


What is the preferred naming convention for plugin builder setter methods?
It is setXXX or withXXX? I see both being used in the code base.

I wonder which to use for the upcoming HttpAppender (LOG4J2-1442).

Re: [Log4j] Scala release

[Ralph Goers]

I’ll look at it as well provided I have the time.

Ralph

> On May 22, 2017, at 8:12 AM, Mikael Ståldal  wrote:
> 
> If I remembered correctly, Gary was willing to test it and vote if there were 
> building instructions. And now there are.
> 
> 
> On 2017-05-22 17:01, Matt Sicker wrote:
>> I haven't had any time lately to make rc2. Based on the last vote, I'm
>> wondering if we'll get a third vote since nobody but us two are even using
>> Scala. ;)
>> 
>> On 22 May 2017 at 09:30, Mikael Ståldal  wrote:
>> 
>>> How is it going with release of log4j-scala?
>>> 
>>> 
>>> 
>> 
> 
> 

Re: Java9

[Ralph Goers]

Java 9 now has a —release option which should help. However, if we set it to 
Java 7 I suspect the build will fail on the Java 9 stuff even though we are 
using the Java 9 compiler. I really don’t see a way to do this except by 
calling the compiler multiple times.

Ralph

> On May 22, 2017, at 8:49 AM, Matt Sicker  wrote:
> 
> I still want to see a better Maven plugin for handling Java 9 multi-release
> jars and things like that. The whole Java 9 build is still rather hacky. If
> the entire project was buildable in Java 9 and could still target 7, 8, and
> 9, then that would be a simpler solution IMO.
> 
> On 22 May 2017 at 06:16, Mikael Ståldal  wrote:
> 
>> IntelliJ IDEA is "smart" enough to automatically pick up the
>> src/main/java9 folder.
>> 
>> 
>> 
>> On 2017-05-21 22:26, Ralph Goers wrote:
>> 
>>> Since src/main/java9 isn’t normally considered a source directory you
>>> should be able to work with Java 7 as well. It will just ignore the Java 9
>>> files.
>>> 
>>> Ralph
>>> 
>>> On May 21, 2017, at 5:50 AM, Gary Gregory  wrote:
 
 I set the JRE for that project to Java 9. I do not think you can set the
 JRE per source folder, only per project.
 
 Gary
 
 On May 21, 2017 1:29 AM, "Ralph Goers" 
 wrote:
 
 I’ve modified the build to put the Java 9 classes of the API into a
 separate source directory. Can you see if that helps things in Eclipse?
 
 Ralph
 
>>> 
>>> 
>> 
> 
> 
> -- 
> Matt Sicker 

Re: [Newsletter] Re: [LOG4NET] gitflow

[Matt Sicker]

The master branch holding only production tags is useful for making a
production hotfix release. For example, this would be useful in making
security patches. As for holding release branches, in my use of git-flow,
I've always deleted them after merging back to develop&master, but in
theory, it could be used for cherry-picking bug fixes and such to make
multiple releases. Whether we'd want to support multiple version branches
somewhat relies on how easy of a process that is for release managers to
follow. We only use a single release train in Log4j, but that's partially
due to the complexity in making a release.

On 22 May 2017 at 08:01,  wrote:

> Hi
>
> Gary Gregory  wrote on 19.05.2017 23:01:10:
> > Howdy,
> >
> > Thank you for the link.
> >
> > This is fine until you want to manage more than once major version in
> one
> > repo, right?
> >
> > Over at HttpComponents, we have decided for now to keep to one repo, as
> > opposed to one repo per major version.
> >
> > So ATM for example in HttpComponents' HttpCore we have a 4.4.x and
> master
> > branch that are BOTH going to be used for releases.
> >
> > How do you deal with that in Gitflow?
>
> As I understood gitflow, release branches are "short-living" branches,
> only
> used for preparation of a particular release. Once the release is shipped
> the branch is removed.
> If you need to support several versions of your software in the field
> (e.g.
> keep shipping feature updates for 2.x and 1.x; aside from hot fixes),
> "support-brachnes" is what you're looking for. They behave like "the"
> develop
> branch, but for supporting older version.
> The GitVersion Manual has some nice example images for this:
> http://gitversion.readthedocs.io/en/latest/git-branching-
> strategies/gitflow-examples/#support-branches
>
> Regards,
> Jonas
>
> >
> > Gary
> >
> > On Fri, May 19, 2017 at 1:10 PM, Dominik Psenner 
> wrote:
> >
> > > Hi,
> > >
> > > would we like to use gitflow for our named branches? [1]
> > >
> > > [1] https://datasift.github.io/gitflow/IntroducingGitFlow.html
> > >
> > > Cheers
> > > --
> > > Dominik Psenner
> > >
> >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> >  >
> ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8
> > >
> >
> >  > t=garygregory-20&l=am2&o=1&a=1617290459>
> > JUnit in Action, Second Edition
> >  >
> ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%
> > 22>
> >
> >  > t=garygregory-20&l=am2&o=1&a=1935182021>
> > Spring Batch in Action
> >  > ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%
> > 7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%
> > 22%3ESpring+Batch+in+Action>
> >  > t=garygregory-20&l=am2&o=1&a=1935182951>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>



-- 
Matt Sicker 

Re: [1/2] logging-log4net git commit: This migrates the visual studio solution to Visual Studio 14

[Matt Sicker]

Is Monodevelop still a thing? I used to use that back in college in my C#
class.

On 22 May 2017 at 10:21, Dominik Psenner  wrote:

>
> On 2017-05-22 13:59, Stefan Bodewig wrote:
>
>> As long as we keep NAnt as the build tool of truth the solution files
>> are "only" a convenience feature for people using VS (likely everybody
>> except myself :-).
>>
>
> How do you develop log4net if not with visual studio?
>



-- 
Matt Sicker 

Re: Plugin builder setters

[Matt Sicker]

I like that distinction, Gary. For example, the withers in Lombok are used
for creating copies with the named property updated. A builder pattern
using the same builder instance would then make sense to use setter names
instead of wither names.

On 22 May 2017 at 10:54, Mikael Ståldal  wrote:

> SocketAppender uses "with" like this:
>
> public B withSslConfiguration(final SslConfiguration sslConfiguration) {
> this.sslConfiguration = sslConfiguration;
> return asBuilder();
> }
>
> is that wrong?
>
>
> On 2017-05-22 17:50, Gary Gregory wrote:
>
>> I like "with" for methods that return a new instance and "set" for those
>> that do not.
>>
>> Since most if not all of our builders don't create new instances on setter
>> calls I would go with "set".
>>
>> 2c,
>> Gary
>>
>> Gary
>>
>> On May 22, 2017 8:36 AM, "Mikael Ståldal"  wrote:
>>
>> What is the preferred naming convention for plugin builder setter methods?
>>> It is setXXX or withXXX? I see both being used in the code base.
>>>
>>> I wonder which to use for the upcoming HttpAppender (LOG4J2-1442).
>>>
>>>
>>>
>>>
>


-- 
Matt Sicker 

Re: Java9

[Remko Popma]

One idea: we could move (actually copy) the StackLocator interface to the
Java 9 module.
This allows us to build the Java 9 module first. Then, when building the
log4j-api module, the Java 9 classes can be shaded into the log4j-api jar
(excluding StackLocator since we want to compile that interface with Java
7).

That way all modules depend on Java 7 except the log4j-api-java9 module
which depends on Java 9. This is clean, works well in IDEs and does not
require the toolchain workaround. The whole project could probably be
compiled with just JDK 9 this way.

Started to play with this but could not finish today. Need to continue
tomorrow.


On Tue, May 23, 2017 at 12:59 AM, Ralph Goers 
wrote:

> Java 9 now has a —release option which should help. However, if we set it
> to Java 7 I suspect the build will fail on the Java 9 stuff even though we
> are using the Java 9 compiler. I really don’t see a way to do this except
> by calling the compiler multiple times.
>
> Ralph
>
> > On May 22, 2017, at 8:49 AM, Matt Sicker  wrote:
> >
> > I still want to see a better Maven plugin for handling Java 9
> multi-release
> > jars and things like that. The whole Java 9 build is still rather hacky.
> If
> > the entire project was buildable in Java 9 and could still target 7, 8,
> and
> > 9, then that would be a simpler solution IMO.
> >
> > On 22 May 2017 at 06:16, Mikael Ståldal  wrote:
> >
> >> IntelliJ IDEA is "smart" enough to automatically pick up the
> >> src/main/java9 folder.
> >>
> >>
> >>
> >> On 2017-05-21 22:26, Ralph Goers wrote:
> >>
> >>> Since src/main/java9 isn’t normally considered a source directory you
> >>> should be able to work with Java 7 as well. It will just ignore the
> Java 9
> >>> files.
> >>>
> >>> Ralph
> >>>
> >>> On May 21, 2017, at 5:50 AM, Gary Gregory 
> wrote:
> 
>  I set the JRE for that project to Java 9. I do not think you can set
> the
>  JRE per source folder, only per project.
> 
>  Gary
> 
>  On May 21, 2017 1:29 AM, "Ralph Goers" 
>  wrote:
> 
>  I’ve modified the build to put the Java 9 classes of the API into a
>  separate source directory. Can you see if that helps things in
> Eclipse?
> 
>  Ralph
> 
> >>>
> >>>
> >>
> >
> >
> > --
> > Matt Sicker 
>
>
>

Re: [1/2] logging-log4net git commit: This migrates the visual studio solution to Visual Studio 14

[Stefan Bodewig]

On 2017-05-22, Dominik Psenner wrote:

> On 2017-05-22 13:59, Stefan Bodewig wrote:

>> As long as we keep NAnt as the build tool of truth the solution files
>> are "only" a convenience feature for people using VS (likely everybody
>> except myself :-).

> How do you develop log4net if not with visual studio?

Emacs. The same way I do pretty much everything else as well :-)

Stefan

Re: Java9

[Matt Sicker]

Splitting the Java 9 code into its own module and shading that back in to
log4j-api seems like it could work for now. I'd imagine that as Java 9 gets
released or sometime soon hopefully, the IDEs will start adding support for
multi-version modules/projects.

On 22 May 2017 at 11:16, Remko Popma  wrote:

> One idea: we could move (actually copy) the StackLocator interface to the
> Java 9 module.
> This allows us to build the Java 9 module first. Then, when building the
> log4j-api module, the Java 9 classes can be shaded into the log4j-api jar
> (excluding StackLocator since we want to compile that interface with Java
> 7).
>
> That way all modules depend on Java 7 except the log4j-api-java9 module
> which depends on Java 9. This is clean, works well in IDEs and does not
> require the toolchain workaround. The whole project could probably be
> compiled with just JDK 9 this way.
>
> Started to play with this but could not finish today. Need to continue
> tomorrow.
>
>
> On Tue, May 23, 2017 at 12:59 AM, Ralph Goers 
> wrote:
>
> > Java 9 now has a —release option which should help. However, if we set it
> > to Java 7 I suspect the build will fail on the Java 9 stuff even though
> we
> > are using the Java 9 compiler. I really don’t see a way to do this except
> > by calling the compiler multiple times.
> >
> > Ralph
> >
> > > On May 22, 2017, at 8:49 AM, Matt Sicker  wrote:
> > >
> > > I still want to see a better Maven plugin for handling Java 9
> > multi-release
> > > jars and things like that. The whole Java 9 build is still rather
> hacky.
> > If
> > > the entire project was buildable in Java 9 and could still target 7, 8,
> > and
> > > 9, then that would be a simpler solution IMO.
> > >
> > > On 22 May 2017 at 06:16, Mikael Ståldal  wrote:
> > >
> > >> IntelliJ IDEA is "smart" enough to automatically pick up the
> > >> src/main/java9 folder.
> > >>
> > >>
> > >>
> > >> On 2017-05-21 22:26, Ralph Goers wrote:
> > >>
> > >>> Since src/main/java9 isn’t normally considered a source directory you
> > >>> should be able to work with Java 7 as well. It will just ignore the
> > Java 9
> > >>> files.
> > >>>
> > >>> Ralph
> > >>>
> > >>> On May 21, 2017, at 5:50 AM, Gary Gregory 
> > wrote:
> > 
> >  I set the JRE for that project to Java 9. I do not think you can set
> > the
> >  JRE per source folder, only per project.
> > 
> >  Gary
> > 
> >  On May 21, 2017 1:29 AM, "Ralph Goers" 
> >  wrote:
> > 
> >  I’ve modified the build to put the Java 9 classes of the API into a
> >  separate source directory. Can you see if that helps things in
> > Eclipse?
> > 
> >  Ralph
> > 
> > >>>
> > >>>
> > >>
> > >
> > >
> > > --
> > > Matt Sicker 
> >
> >
> >
>



-- 
Matt Sicker 

[jira] [Commented] (LOG4NET-565) Dependency Injection support appender and logger types

[Dominik Psenner (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019867#comment-16019867
 ] 

Dominik Psenner commented on LOG4NET-565:
-

Is there a reason why you have not put the appender injection in a custom 
appender? A AppenderServiceLocatorAppender would allow more flexibility while 
at the same time reducing complexity in core. For instance, one could reuse 
other appenders like the buffering appender or a filtering appender to create 
sophisticated logevent flows.

> Dependency Injection support appender and logger types
> --
>
> Key: LOG4NET-565
> URL: https://issues.apache.org/jira/browse/LOG4NET-565
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders, Core
>Reporter: Hitesh Chauhan
>  Labels: Enhancement
>
> I have seen demand for dependency injection support in log4net. I have added 
> that behavior to my local repository. And I would like to push that to 
> log4net library.
> e.g. appender configuration
>  name="ServiceAppender" 
> type="LoggingServiceAppender"   
> serviceLocatorType="Log4NetServiceLocator">



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LOG4NET-565) Dependency Injection support appender and logger types

[Dominik Psenner (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019870#comment-16019870
 ] 

Dominik Psenner commented on LOG4NET-565:
-

Further it would reduce the service locator api to something that does not 
contain an appender type. That makes this kind of a hack.

> Dependency Injection support appender and logger types
> --
>
> Key: LOG4NET-565
> URL: https://issues.apache.org/jira/browse/LOG4NET-565
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders, Core
>Reporter: Hitesh Chauhan
>  Labels: Enhancement
>
> I have seen demand for dependency injection support in log4net. I have added 
> that behavior to my local repository. And I would like to push that to 
> log4net library.
> e.g. appender configuration
>  name="ServiceAppender" 
> type="LoggingServiceAppender"   
> serviceLocatorType="Log4NetServiceLocator">



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LOG4NET-565) Dependency Injection support appender and logger types

[Hitesh Chauhan (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019915#comment-16019915
 ] 

Hitesh Chauhan commented on LOG4NET-565:


To me, this is similar to what core does for IAppender using reflection. The 
only thing it's doing is pushing IAppender instantiation one level down. Which 
opens up the more flexibilities for resolving any Appender types using IoC. 
Since all appenders implement IAppender so this code should cause any issues or 
coupling between types. At least, I don't see that based on my understanding of 
log4net code - I am not an expert as I didn't write feature or fix any issues 
before.

If I understood correctly you are saying create a new custom appender 
"AppenderServiceLocatorAppender". I cannot image how it would solve the 
problem. The actual instance creating happens inside XmlHierarchyConfigurator 
class. so even if I create a new appender I would land into the same situation 
where I started.

"Further it would reduce the service locator api to something that does not 
contain an appender type. That makes this kind of a hack."
Apologies, I cannot visualize that. Are you saying no service locator api or 
use service locator but outside of the core? can you please help me to 
understand with the pseudo code?



> Dependency Injection support appender and logger types
> --
>
> Key: LOG4NET-565
> URL: https://issues.apache.org/jira/browse/LOG4NET-565
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders, Core
>Reporter: Hitesh Chauhan
>  Labels: Enhancement
>
> I have seen demand for dependency injection support in log4net. I have added 
> that behavior to my local repository. And I would like to push that to 
> log4net library.
> e.g. appender configuration
>  name="ServiceAppender" 
> type="LoggingServiceAppender"   
> serviceLocatorType="Log4NetServiceLocator">



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: logging-log4j2 git commit: Https support (W.I.P.)

[Gary Gregory]

On Mon, May 22, 2017 at 9:02 AM,  wrote:

> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/LOG4J2-1442 42dcb4588 -> 93ac8ab82
>
>
> Https support (W.I.P.)
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> commit/93ac8ab8
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/93ac8ab8
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/93ac8ab8
>
> Branch: refs/heads/LOG4J2-1442
> Commit: 93ac8ab82037ea77eee5e99cd3e6b26b0ea1ad95
> Parents: 42dcb45
> Author: Mikael Ståldal 
> Authored: Mon May 22 18:02:13 2017 +0200
> Committer: Mikael Ståldal 
> Committed: Mon May 22 18:02:13 2017 +0200
>
> --
>  .../log4j/core/appender/HttpAppender.java   | 15 +-
>  .../core/appender/HttpURLConnectionManager.java | 17 +--
>  .../log4j/core/appender/HttpAppenderTest.java   | 31 ++--
>  3 files changed, 58 insertions(+), 5 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> 93ac8ab8/log4j-core/src/main/java/org/apache/logging/log4j/
> core/appender/HttpAppender.java
> --
> diff --git 
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/HttpAppender.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> appender/HttpAppender.java
> index c43c63d..efc9942 100644
> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/
> appender/HttpAppender.java
> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> appender/HttpAppender.java
> @@ -32,6 +32,7 @@ import org.apache.logging.log4j.core.config.plugins.
> PluginBuilderAttribute;
>  import org.apache.logging.log4j.core.config.plugins.PluginBuilderFactory;
>  import org.apache.logging.log4j.core.config.plugins.PluginElement;
>  import org.apache.logging.log4j.core.config.plugins.validation.
> constraints.Required;
> +import org.apache.logging.log4j.core.net.ssl.SslConfiguration;
>
>  /**
>   * Sends log events over HTTP.
> @@ -62,10 +63,13 @@ public final class HttpAppender extends
> AbstractAppender {
>  @PluginElement("Headers")
>  private Property[] headers;
>
> +@PluginElement("SslConfiguration")
> +private SslConfiguration sslConfiguration;
> +
>  @Override
>  public HttpAppender build() {
>  final HttpManager httpManager = new 
> HttpURLConnectionManager(getConfiguration(),
> getConfiguration().getLoggerContext(),
> -getName(), url, method, connectTimeoutMillis,
> readTimeoutMillis, headers);
> +getName(), url, method, connectTimeoutMillis,
> readTimeoutMillis, headers, sslConfiguration);
>  return new HttpAppender(getName(), getLayout(), getFilter(),
> isIgnoreExceptions(), httpManager);
>  }
>
> @@ -89,6 +93,10 @@ public final class HttpAppender extends
> AbstractAppender {
>  return headers;
>  }
>
> +public SslConfiguration getSslConfiguration() {
> +return sslConfiguration;
> +}
> +
>  public B setUrl(final String url) {
>  this.url = url;
>  return asBuilder();
> @@ -113,6 +121,11 @@ public final class HttpAppender extends
> AbstractAppender {
>  this.headers = headers;
>  return asBuilder();
>  }
> +
> +public B setSslConfiguration(final SslConfiguration
> sslConfiguration) {
> +this.sslConfiguration = sslConfiguration;
> +return asBuilder();
> +}
>  }
>
>  /**
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> 93ac8ab8/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/
> HttpURLConnectionManager.java
> --
> diff --git a/log4j-core/src/main/java/org/apache/logging/log4j/core/
> appender/HttpURLConnectionManager.java b/log4j-core/src/main/java/
> org/apache/logging/log4j/core/appender/HttpURLConnectionManager.java
> index d656c90..de9225c 100644
> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/
> HttpURLConnectionManager.java
> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/
> HttpURLConnectionManager.java
> @@ -26,12 +26,15 @@ import java.net.URL;
>  import java.nio.charset.Charset;
>  import java.util.Objects;
>
> +import javax.net.ssl.HttpsURLConnection;
> +
>  import org.apache.logging.log4j.core.Layout;
>  import org.apache.logging.log4j.core.LogEvent;
>  import org.apache.logging.log4j.core.LoggerContext;
>  import org.apache.logging.log4j.core.config.Configuration;
>  import org.apache.logging.log4j.core.config.ConfigurationException;
>  import org.apache.logging.log4j.core.config.Property;
> +import org.apache.lo

[jira] [Comment Edited] (LOG4NET-565) Dependency Injection support appender and logger types

[Hitesh Chauhan (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019915#comment-16019915
 ] 

Hitesh Chauhan edited comment on LOG4NET-565 at 5/22/17 6:20 PM:
-

To me, this is similar to what core does for IAppender using reflection. The 
only thing it's doing is pushing IAppender instantiation one level down. Which 
opens up the more flexibilities for resolving any Appender types using IoC. 
Since all appenders implement IAppender so this code should not cause any 
issues or coupling between types. At least, I don't see that based on my 
understanding of log4net code - I am not an expert as I didn't write feature or 
fix any issues before.

If I understood correctly you are saying create a new custom appender 
"AppenderServiceLocatorAppender". I cannot image how it would solve the 
problem. The actual instance creating happens inside XmlHierarchyConfigurator 
class. so even if I create a new appender I would land into the same situation 
where I started.

"Further it would reduce the service locator api to something that does not 
contain an appender type. That makes this kind of a hack."
Apologies, I cannot visualize that. Are you saying no service locator api or 
use service locator but outside of the core? can you please help me to 
understand with the pseudo code?




was (Author: techminder):
To me, this is similar to what core does for IAppender using reflection. The 
only thing it's doing is pushing IAppender instantiation one level down. Which 
opens up the more flexibilities for resolving any Appender types using IoC. 
Since all appenders implement IAppender so this code should cause any issues or 
coupling between types. At least, I don't see that based on my understanding of 
log4net code - I am not an expert as I didn't write feature or fix any issues 
before.

If I understood correctly you are saying create a new custom appender 
"AppenderServiceLocatorAppender". I cannot image how it would solve the 
problem. The actual instance creating happens inside XmlHierarchyConfigurator 
class. so even if I create a new appender I would land into the same situation 
where I started.

"Further it would reduce the service locator api to something that does not 
contain an appender type. That makes this kind of a hack."
Apologies, I cannot visualize that. Are you saying no service locator api or 
use service locator but outside of the core? can you please help me to 
understand with the pseudo code?



> Dependency Injection support appender and logger types
> --
>
> Key: LOG4NET-565
> URL: https://issues.apache.org/jira/browse/LOG4NET-565
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders, Core
>Reporter: Hitesh Chauhan
>  Labels: Enhancement
>
> I have seen demand for dependency injection support in log4net. I have added 
> that behavior to my local repository. And I would like to push that to 
> log4net library.
> e.g. appender configuration
>  name="ServiceAppender" 
> type="LoggingServiceAppender"   
> serviceLocatorType="Log4NetServiceLocator">



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Plugin builder setters

[Gary Gregory]

On Mon, May 22, 2017 at 8:54 AM, Mikael Ståldal  wrote:

> SocketAppender uses "with" like this:
>
> public B withSslConfiguration(final SslConfiguration sslConfiguration) {
> this.sslConfiguration = sslConfiguration;
> return asBuilder();
> }
>
> is that wrong?
>

In my mind, yes, but it is more confusing than "wrong".

Gary

>
> On 2017-05-22 17:50, Gary Gregory wrote:
>
>> I like "with" for methods that return a new instance and "set" for those
>> that do not.
>>
>> Since most if not all of our builders don't create new instances on setter
>> calls I would go with "set".
>>
>> 2c,
>> Gary
>>
>> Gary
>>
>> On May 22, 2017 8:36 AM, "Mikael Ståldal"  wrote:
>>
>> What is the preferred naming convention for plugin builder setter methods?
>>> It is setXXX or withXXX? I see both being used in the code base.
>>>
>>> I wonder which to use for the upcoming HttpAppender (LOG4J2-1442).
>>>
>>>
>>>
>>>
>


-- 
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-1914) AsyncLogger and message formatting (ConcurrentModificationException)

[Leon Finker (JIRA)]

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

Leon Finker commented on LOG4J2-1914:
-

Hi Gary,

Tried with 2.8.2 and same exception. It's hard to find the actual place though 
that's causing it on the caller's thread.

> AsyncLogger and message formatting (ConcurrentModificationException)
> 
>
> Key: LOG4J2-1914
> URL: https://issues.apache.org/jira/browse/LOG4J2-1914
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Leon Finker
>
> Hi,
> The docs specify that the default for log4j.format.msg.async is false. But we 
> still got the following log4j2 AsyncLogger processing exception. Does it mean 
> that message formatting is async or maybe async up to 2.7 only? Or is this 
> something else?  Thank you
> 2017-05-18 08:02:44,570 Log4j2-TF-3-AsyncLoggerConfig-2 ERROR An exception 
> occurred processing Appender AppLogFile 
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(Unknown Source)
> at java.util.HashMap$EntryIterator.next(Unknown Source)
> at java.util.HashMap$EntryIterator.next(Unknown Source)
> at 
> org.apache.logging.log4j.message.ParameterFormatter.appendMap(ParameterFormatter.java:569)
> at 
> org.apache.logging.log4j.message.ParameterFormatter.appendPotentiallyRecursiveValue(ParameterFormatter.java:505)
> at 
> org.apache.logging.log4j.message.ParameterFormatter.recursiveDeepToString(ParameterFormatter.java:432)
> at 
> org.apache.logging.log4j.message.ParameterFormatter.formatMessage2(ParameterFormatter.java:189)
> at 
> org.apache.logging.log4j.message.ParameterizedMessage.formatTo(ParameterizedMessage.java:225)
> at 
> org.apache.logging.log4j.core.pattern.MessagePatternConverter.format(MessagePatternConverter.java:117)
> at 
> org.apache.logging.log4j.core.pattern.PatternFormatter.format(PatternFormatter.java:38)
> at 
> org.apache.logging.log4j.core.layout.PatternLayout$PatternSerializer.toSerializable(PatternLayout.java:294)
> at 
> org.apache.logging.log4j.core.layout.PatternLayout.toText(PatternLayout.java:195)
> at 
> org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:180)
> at 
> org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:57)
> at 
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:176)
> at 
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:169)
> at 
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:160)
> at 
> org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender.append(RollingRandomAccessFileAppender.java:104)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:447)
> at 
> org.apache.logging.log4j.core.async.AsyncLoggerConfig.asyncCallAppenders(AsyncLoggerConfig.java:114)
> at 
> org.apache.logging.log4j.core.async.AsyncLoggerConfigDisruptor$Log4jEventWrapperHandler.onEvent(AsyncLoggerConfigDisruptor.java:112)
> at 
> org.apache.logging.log4j.core.async.AsyncLoggerConfigDisruptor$Log4jEventWrapperHandler.onEvent(AsyncLoggerConfigDisruptor.java:98)
> at 
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:129)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown 
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
> Source)
> at java.lang.Thread.run(Unknown Source)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LOG4J2-1914) AsyncLogger and message formatting (ConcurrentModificationException)

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1914:
--

Would you mind posting the 2.8.2 stack trace? 

Thank you.

> AsyncLogger and message formatting (ConcurrentModificationException)
> 
>
> Key: LOG4J2-1914
> URL: https://issues.apache.org/jira/browse/LOG4J2-1914
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Leon Finker
>
> Hi,
> The docs specify that the default for log4j.format.msg.async is false. But we 
> still got the following log4j2 AsyncLogger processing exception. Does it mean 
> that message formatting is async or maybe async up to 2.7 only? Or is this 
> something else?  Thank you
> 2017-05-18 08:02:44,570 Log4j2-TF-3-AsyncLoggerConfig-2 ERROR An exception 
> occurred processing Appender AppLogFile 
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(Unknown Source)
> at java.util.HashMap$EntryIterator.next(Unknown Source)
> at java.util.HashMap$EntryIterator.next(Unknown Source)
> at 
> org.apache.logging.log4j.message.ParameterFormatter.appendMap(ParameterFormatter.java:569)
> at 
> org.apache.logging.log4j.message.ParameterFormatter.appendPotentiallyRecursiveValue(ParameterFormatter.java:505)
> at 
> org.apache.logging.log4j.message.ParameterFormatter.recursiveDeepToString(ParameterFormatter.java:432)
> at 
> org.apache.logging.log4j.message.ParameterFormatter.formatMessage2(ParameterFormatter.java:189)
> at 
> org.apache.logging.log4j.message.ParameterizedMessage.formatTo(ParameterizedMessage.java:225)
> at 
> org.apache.logging.log4j.core.pattern.MessagePatternConverter.format(MessagePatternConverter.java:117)
> at 
> org.apache.logging.log4j.core.pattern.PatternFormatter.format(PatternFormatter.java:38)
> at 
> org.apache.logging.log4j.core.layout.PatternLayout$PatternSerializer.toSerializable(PatternLayout.java:294)
> at 
> org.apache.logging.log4j.core.layout.PatternLayout.toText(PatternLayout.java:195)
> at 
> org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:180)
> at 
> org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:57)
> at 
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:176)
> at 
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:169)
> at 
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:160)
> at 
> org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender.append(RollingRandomAccessFileAppender.java:104)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:447)
> at 
> org.apache.logging.log4j.core.async.AsyncLoggerConfig.asyncCallAppenders(AsyncLoggerConfig.java:114)
> at 
> org.apache.logging.log4j.core.async.AsyncLoggerConfigDisruptor$Log4jEventWrapperHandler.onEvent(AsyncLoggerConfigDisruptor.java:112)
> at 
> org.apache.logging.log4j.core.async.AsyncLoggerConfigDisruptor$Log4jEventWrapperHandler.onEvent(AsyncLoggerConfigDisruptor.java:98)
> at 
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:129)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown 
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
> Source)
> at java.lang.Thread.run(Unknown Source)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Plugin builder setters

[Mikael Ståldal]

Then I keep it as "set" in HttpAppender.

On 2017-05-22 20:26, Gary Gregory wrote:

On Mon, May 22, 2017 at 8:54 AM, Mikael Ståldal  wrote:


SocketAppender uses "with" like this:

public B withSslConfiguration(final SslConfiguration sslConfiguration) {
 this.sslConfiguration = sslConfiguration;
 return asBuilder();
}

is that wrong?



In my mind, yes, but it is more confusing than "wrong".

Gary



On 2017-05-22 17:50, Gary Gregory wrote:


I like "with" for methods that return a new instance and "set" for those
that do not.

Since most if not all of our builders don't create new instances on setter
calls I would go with "set".

2c,
Gary

Gary

On May 22, 2017 8:36 AM, "Mikael Ståldal"  wrote:

What is the preferred naming convention for plugin builder setter methods?

It is setXXX or withXXX? I see both being used in the code base.

I wonder which to use for the upcoming HttpAppender (LOG4J2-1442).

[jira] [Commented] (LOG4J2-1874) Add ByteBufferDestionation.write(ByteBuffer) and write(byte[], int, int) methods and call them from TextEncoderHelper whenever possible

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-1874:


Github user leventov commented on the issue:

https://github.com/apache/logging-log4j2/pull/71
  
@remkop any extra comments on this?


> Add ByteBufferDestionation.write(ByteBuffer) and write(byte[], int, int) 
> methods and call them from TextEncoderHelper whenever possible
> ---
>
> Key: LOG4J2-1874
> URL: https://issues.apache.org/jira/browse/LOG4J2-1874
> Project: Log4j 2
>  Issue Type: Improvement
>Reporter: Roman Leventov
>Assignee: Remko Popma
>
> Existing ByteBufferDestination API: getByteBuffer() and drain() is designed 
> so that synchronization couldn't be avoided. This doesn't allow to implement 
> LOG4J2-928.
> Github PR: https://github.com/apache/logging-log4j2/pull/71
> Added methods: write(ByteBuffer data) and write(byte[] data, int offset, int 
> length) are designed so that they should care about synchronization 
> themselves, internally, if needed. They should also synchronize with possible 
> concurrent users of the synchronized getByteBuffer() + drain() API. 
> Nevertheless, it allows for ByteBufferDestination implementations to 
> implement write() methods without lock-free.
> TextEncoderHelper (hence StringBuilderEncoder, which delegates it's logic to 
> TextEncoderHelper) is changed so that it calls ByteBufferDestination.write() 
> whenever possible.  There is an expectation that most of encoded events fit 
> the thread-local buffers, and write() could be called instead of writing to 
> destination.getByteBuffer() with synchronization.
> The PR also includes a sanity improvement: uses ByteBuffer.arrayOffset() at 
> some places.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] logging-log4j2 issue #71: [LOG4J2-1874] Add ByteBufferDestionation.writeByte...

[leventov]

Github user leventov commented on the issue:

https://github.com/apache/logging-log4j2/pull/71
  
@remkop any extra comments on this?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LOG4NET-565) Dependency Injection support appender and logger types

[Dominik Psenner (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020094#comment-16020094
 ] 

Dominik Psenner commented on LOG4NET-565:
-

I imagined an Appender that works almost like the ForwardingAppender does 
today. It differs in that it allows injection of a service locator interface 
implementation, much like the one you have provided. During ActivateOptions() 
it would then call the service locator and obtain an instance of the requested 
appender. Alternatively it could ask the service locator for an appender when 
it processes a log event. Something like:

{code}
class AppenderLocatorForwardingAppender : AppenderSkeleton {
public IAppenderLocator AppenderLocator { get; set; }
public string[] AppenderLocatorArguments { get; set; }
protected IAppender AppenderImpl { get; private set; }
public override ActivateOptions() {
// TODO sanity checks etc
AppenderImpl = AppenderLocator.GetInstance(AppenderLocatorArguments);
}
public override void Append(LogEvent logEvent) {
AppenderImpl.DoAppend(logEvent);
}
protected override OnClose() {
// TODO forward Close() to appender locator
}
}
{code}

or:

{code}
class AppenderLocatorForwardingAppender : AppenderSkeleton {
public IAppenderLocator AppenderLocator { get; set; }
public string[] AppenderLocatorArguments { get; set; }
public override void ActivateOptions() {
// TODO sanity checks and forward to AppenderLocator
}
public override void Append(LogEvent logEvent) {
IAppender appenderImpl = 
AppenderLocator.GetInstance(AppenderLocatorArguments);
appenderImpl.DoAppend(logEvent);
}
protected override OnClose() {
// TODO forward to AppenderLocator
}
}
{code}

This way the implementation rather straight forward, reuses existing features 
(like filtering etc) and can be combined with other appenders much like the 
ForwardingAppender does today.

Please note that option two may need an enhanced service locator or a 
IServiceLocatorAppender API to allow for a better resource allocation and 
disposal that after all ends up being the IAppender API and thus option one is 
most probably the better approach.

> Dependency Injection support appender and logger types
> --
>
> Key: LOG4NET-565
> URL: https://issues.apache.org/jira/browse/LOG4NET-565
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders, Core
>Reporter: Hitesh Chauhan
>  Labels: Enhancement
>
> I have seen demand for dependency injection support in log4net. I have added 
> that behavior to my local repository. And I would like to push that to 
> log4net library.
> e.g. appender configuration
>  name="ServiceAppender" 
> type="LoggingServiceAppender"   
> serviceLocatorType="Log4NetServiceLocator">



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [1/2] logging-log4net git commit: This migrates the visual studio solution to Visual Studio 14

[Dominik Psenner]

I'm a vi guy and have no need for a decent window manager. ;-)

Can I proceed with bumping the solution to visual studio 2015 and removing
all solution files on the master branch?

2017-05-22 18:19 GMT+02:00 Stefan Bodewig :

> On 2017-05-22, Dominik Psenner wrote:
>
> > On 2017-05-22 13:59, Stefan Bodewig wrote:
>
> >> As long as we keep NAnt as the build tool of truth the solution files
> >> are "only" a convenience feature for people using VS (likely everybody
> >> except myself :-).
>
> > How do you develop log4net if not with visual studio?
>
> Emacs. The same way I do pretty much everything else as well :-)
>
> Stefan
>



-- 
Dominik Psenner

Re: [Newsletter] Re: [LOG4NET] gitflow

[Dominik Psenner]

Right now I could use the develop branch because I have made the
modifications that remove the old solution files and updates the solution
to visual studio 2015. It makes no sense to make those changes either in
the feature branch, nore the master branch but I would like to push those
changes somewhere such that anyone could merge those changes into master.
I'm starting a lazy vote now.

2017-05-22 17:59 GMT+02:00 Matt Sicker :

> The master branch holding only production tags is useful for making a
> production hotfix release. For example, this would be useful in making
> security patches. As for holding release branches, in my use of git-flow,
> I've always deleted them after merging back to develop&master, but in
> theory, it could be used for cherry-picking bug fixes and such to make
> multiple releases. Whether we'd want to support multiple version branches
> somewhat relies on how easy of a process that is for release managers to
> follow. We only use a single release train in Log4j, but that's partially
> due to the complexity in making a release.
>
> On 22 May 2017 at 08:01,  wrote:
>
> > Hi
> >
> > Gary Gregory  wrote on 19.05.2017 23:01:10:
> > > Howdy,
> > >
> > > Thank you for the link.
> > >
> > > This is fine until you want to manage more than once major version in
> > one
> > > repo, right?
> > >
> > > Over at HttpComponents, we have decided for now to keep to one repo, as
> > > opposed to one repo per major version.
> > >
> > > So ATM for example in HttpComponents' HttpCore we have a 4.4.x and
> > master
> > > branch that are BOTH going to be used for releases.
> > >
> > > How do you deal with that in Gitflow?
> >
> > As I understood gitflow, release branches are "short-living" branches,
> > only
> > used for preparation of a particular release. Once the release is shipped
> > the branch is removed.
> > If you need to support several versions of your software in the field
> > (e.g.
> > keep shipping feature updates for 2.x and 1.x; aside from hot fixes),
> > "support-brachnes" is what you're looking for. They behave like "the"
> > develop
> > branch, but for supporting older version.
> > The GitVersion Manual has some nice example images for this:
> > http://gitversion.readthedocs.io/en/latest/git-branching-
> > strategies/gitflow-examples/#support-branches
> >
> > Regards,
> > Jonas
> >
> > >
> > > Gary
> > >
> > > On Fri, May 19, 2017 at 1:10 PM, Dominik Psenner 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > would we like to use gitflow for our named branches? [1]
> > > >
> > > > [1] https://datasift.github.io/gitflow/IntroducingGitFlow.html
> > > >
> > > > Cheers
> > > > --
> > > > Dominik Psenner
> > > >
> > >
> > >
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition
> > >  > >
> > ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8
> > > >
> > >
> > >  > > t=garygregory-20&l=am2&o=1&a=1617290459>
> > > JUnit in Action, Second Edition
> > >  > >
> > ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%
> > > 22>
> > >
> > >  > > t=garygregory-20&l=am2&o=1&a=1935182021>
> > > Spring Batch in Action
> > >  > > ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%
> > > 7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%
> > > 22%3ESpring+Batch+in+Action>
> > >  > > t=garygregory-20&l=am2&o=1&a=1935182951>
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> >
>
>
>
> --
> Matt Sicker 
>



-- 
Dominik Psenner

[LOG4NET] [VOTE] gitflow

[Dominik Psenner]

This is a vote to introduce gitflow on the log4net subproject. gitflow
would mean that we make use of the following named branches:

* master
Marks stable milestones and is moves on with a release.

* develop
Development of the next milestone should happen here.

* feature/featurename
 These should be named branches used to develop a feature that needs
some crafting and unstable modifications. Only when a feature is complete
and stable, it should be merged back into develop.

* hotfix/hotfixname
Hotfixes branch from master and modifications should happen here. When
the hotfix is complete, a release should be made and this branch should
then be merged into master. Please note that modifications to the site
during a release should also happen here, while this is not an actual
release.

* release/releasename
A release branch used to prepare the codebase for a release.


+1: Yes!
+0: Go ahead, don't care that much.
-0: Don't like it, but not vetoing it.
-1: No, don't do that! I have a better idea!

This vote follows the "lazy consensus" (no -1/vetoes). The vote will be
open for at least 72 hours after that I'm going to push the develop branch.

-- 
Dominik Psenner

[jira] [Commented] (LOG4NET-565) Dependency Injection support appender and logger types

[Hitesh Chauhan (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020275#comment-16020275
 ] 

Hitesh Chauhan commented on LOG4NET-565:


Thanks Dominik for the pseudo code. My question is who is going provide the 
instance for IAppenderLocator property? Will it be coming from 
XmlHierarchyConfigurator  class?




> Dependency Injection support appender and logger types
> --
>
> Key: LOG4NET-565
> URL: https://issues.apache.org/jira/browse/LOG4NET-565
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders, Core
>Reporter: Hitesh Chauhan
>  Labels: Enhancement
>
> I have seen demand for dependency injection support in log4net. I have added 
> that behavior to my local repository. And I would like to push that to 
> log4net library.
> e.g. appender configuration
>  name="ServiceAppender" 
> type="LoggingServiceAppender"   
> serviceLocatorType="Log4NetServiceLocator">



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LOG4NET-565) Dependency Injection support appender and logger types

[Dominik Psenner (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020351#comment-16020351
 ] 

Dominik Psenner commented on LOG4NET-565:
-

That's something that the xml configurator is already able to do already with 
appender and their properties. I assume that the following appender 
configuration would create the service locator:

{code}



{code}

This is yet untested and needs to be confirmed, but I am confident it would 
work as this is used for custom evaluators, layouts, .. Also I am not sure if 
it would be possible to have an array of arguments to pass to the service 
locator impl, but I'm not sure that is even needed. If the appender locator has 
public properties to write to, it can be configured in the same way it is 
injected into the appender.

> Dependency Injection support appender and logger types
> --
>
> Key: LOG4NET-565
> URL: https://issues.apache.org/jira/browse/LOG4NET-565
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders, Core
>Reporter: Hitesh Chauhan
>  Labels: Enhancement
>
> I have seen demand for dependency injection support in log4net. I have added 
> that behavior to my local repository. And I would like to push that to 
> log4net library.
> e.g. appender configuration
>  name="ServiceAppender" 
> type="LoggingServiceAppender"   
> serviceLocatorType="Log4NetServiceLocator">



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] logging-log4j2 issue #71: [LOG4J2-1874] Add ByteBufferDestionation.writeByte...

[remkop]

Github user remkop commented on the issue:

https://github.com/apache/logging-log4j2/pull/71
  
I got distracted by other things but still reviewing. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LOG4J2-1874) Add ByteBufferDestionation.write(ByteBuffer) and write(byte[], int, int) methods and call them from TextEncoderHelper whenever possible

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-1874:


Github user remkop commented on the issue:

https://github.com/apache/logging-log4j2/pull/71
  
I got distracted by other things but still reviewing. 


> Add ByteBufferDestionation.write(ByteBuffer) and write(byte[], int, int) 
> methods and call them from TextEncoderHelper whenever possible
> ---
>
> Key: LOG4J2-1874
> URL: https://issues.apache.org/jira/browse/LOG4J2-1874
> Project: Log4j 2
>  Issue Type: Improvement
>Reporter: Roman Leventov
>Assignee: Remko Popma
>
> Existing ByteBufferDestination API: getByteBuffer() and drain() is designed 
> so that synchronization couldn't be avoided. This doesn't allow to implement 
> LOG4J2-928.
> Github PR: https://github.com/apache/logging-log4j2/pull/71
> Added methods: write(ByteBuffer data) and write(byte[] data, int offset, int 
> length) are designed so that they should care about synchronization 
> themselves, internally, if needed. They should also synchronize with possible 
> concurrent users of the synchronized getByteBuffer() + drain() API. 
> Nevertheless, it allows for ByteBufferDestination implementations to 
> implement write() methods without lock-free.
> TextEncoderHelper (hence StringBuilderEncoder, which delegates it's logic to 
> TextEncoderHelper) is changed so that it calls ByteBufferDestination.write() 
> whenever possible.  There is an expectation that most of encoded events fit 
> the thread-local buffers, and write() could be called instead of writing to 
> destination.getByteBuffer() with synchronization.
> The PR also includes a sanity improvement: uses ByteBuffer.arrayOffset() at 
> some places.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] logging-log4j2 issue #71: [LOG4J2-1874] Add ByteBufferDestionation.writeByte...

[leventov]

Github user leventov commented on the issue:

https://github.com/apache/logging-log4j2/pull/71
  
@remkop thanks for commitment


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LOG4J2-1874) Add ByteBufferDestionation.write(ByteBuffer) and write(byte[], int, int) methods and call them from TextEncoderHelper whenever possible

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-1874:


Github user leventov commented on the issue:

https://github.com/apache/logging-log4j2/pull/71
  
@remkop thanks for commitment


> Add ByteBufferDestionation.write(ByteBuffer) and write(byte[], int, int) 
> methods and call them from TextEncoderHelper whenever possible
> ---
>
> Key: LOG4J2-1874
> URL: https://issues.apache.org/jira/browse/LOG4J2-1874
> Project: Log4j 2
>  Issue Type: Improvement
>Reporter: Roman Leventov
>Assignee: Remko Popma
>
> Existing ByteBufferDestination API: getByteBuffer() and drain() is designed 
> so that synchronization couldn't be avoided. This doesn't allow to implement 
> LOG4J2-928.
> Github PR: https://github.com/apache/logging-log4j2/pull/71
> Added methods: write(ByteBuffer data) and write(byte[] data, int offset, int 
> length) are designed so that they should care about synchronization 
> themselves, internally, if needed. They should also synchronize with possible 
> concurrent users of the synchronized getByteBuffer() + drain() API. 
> Nevertheless, it allows for ByteBufferDestination implementations to 
> implement write() methods without lock-free.
> TextEncoderHelper (hence StringBuilderEncoder, which delegates it's logic to 
> TextEncoderHelper) is changed so that it calls ByteBufferDestination.write() 
> whenever possible.  There is an expectation that most of encoded events fit 
> the thread-local buffers, and write() could be called instead of writing to 
> destination.getByteBuffer() with synchronization.
> The PR also includes a sanity improvement: uses ByteBuffer.arrayOffset() at 
> some places.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LOG4J2-1911) DynamicThresholdFilter defaultThreshold is not used to compare against event's level when there's no matching key found.

[Jerry Chin (JIRA)]

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

Jerry Chin commented on LOG4J2-1911:


[~garydgregory] can you tell where I can supply a patch?

> DynamicThresholdFilter defaultThreshold is not used to compare against 
> event's level when there's no matching key found.
> 
>
> Key: LOG4J2-1911
> URL: https://issues.apache.org/jira/browse/LOG4J2-1911
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.8.2
>Reporter: Jerry Chin
>Priority: Minor
>  Labels: documentation, patch
>
> The {{defaultThreshold}} property is not honored as documented :
> {quote}
> defaultThreshold  Level of messages to be filtered. If there is no 
> matching key in the key/value pairs then this level will be compared against 
> the event's level.
> {quote}
> after carefully examining the source code, I found the following code is 
> called:
> {code:title=DynamicThresholdFilter.java|borderStyle=solid}
>  private Result filter(Level level, ReadOnlyStringMap contextMap) {
> String value = (String)contextMap.getValue(this.key);
> if(value != null) {
> Level ctxLevel = (Level)this.levelMap.get(value);
> if(ctxLevel == null) {
> ctxLevel = this.defaultThreshold;
> }
> return 
> level.isMoreSpecificThan(ctxLevel)?this.onMatch:this.onMismatch;
> } else {
> return Result.NEUTRAL;
> }
> }
> {code}
> where level is the event's level, when there's no matching key found 
> {{contextMap}}, {{Result.NEUTRAL}} is mistakenly returned, instead of against 
> {{this.defaultThreshold}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LOG4J2-1911) DynamicThresholdFilter defaultThreshold is not used to compare against event's level when there's no matching key found.

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1911:
--

You can either attach a diff file to this ticket or create a PR on GitHub.

> DynamicThresholdFilter defaultThreshold is not used to compare against 
> event's level when there's no matching key found.
> 
>
> Key: LOG4J2-1911
> URL: https://issues.apache.org/jira/browse/LOG4J2-1911
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.8.2
>Reporter: Jerry Chin
>Priority: Minor
>  Labels: documentation, patch
>
> The {{defaultThreshold}} property is not honored as documented :
> {quote}
> defaultThreshold  Level of messages to be filtered. If there is no 
> matching key in the key/value pairs then this level will be compared against 
> the event's level.
> {quote}
> after carefully examining the source code, I found the following code is 
> called:
> {code:title=DynamicThresholdFilter.java|borderStyle=solid}
>  private Result filter(Level level, ReadOnlyStringMap contextMap) {
> String value = (String)contextMap.getValue(this.key);
> if(value != null) {
> Level ctxLevel = (Level)this.levelMap.get(value);
> if(ctxLevel == null) {
> ctxLevel = this.defaultThreshold;
> }
> return 
> level.isMoreSpecificThan(ctxLevel)?this.onMatch:this.onMismatch;
> } else {
> return Result.NEUTRAL;
> }
> }
> {code}
> where level is the event's level, when there's no matching key found 
> {{contextMap}}, {{Result.NEUTRAL}} is mistakenly returned, instead of against 
> {{this.defaultThreshold}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [1/2] logging-log4net git commit: This migrates the visual studio solution to Visual Studio 14

[Stefan Bodewig]

I've been through the vi vs emacs debate more than twenty years ago,
both are decent.

Yes, feel free to unify the solution files, just keep in mind we've also
got a .NET Core project file that may need to get adapted (as it
excludes files explicitly, this is less work).

Stefan

On 2017-05-22, Dominik Psenner wrote:

> I'm a vi guy and have no need for a decent window manager. ;-)

> Can I proceed with bumping the solution to visual studio 2015 and removing
> all solution files on the master branch?

> 2017-05-22 18:19 GMT+02:00 Stefan Bodewig :

>> On 2017-05-22, Dominik Psenner wrote:

>>> On 2017-05-22 13:59, Stefan Bodewig wrote:

 As long as we keep NAnt as the build tool of truth the solution files
 are "only" a convenience feature for people using VS (likely everybody
 except myself :-).

>>> How do you develop log4net if not with visual studio?

>> Emacs. The same way I do pretty much everything else as well :-)

>> Stefan

Re: [LOG4NET] [VOTE] gitflow

[Stefan Bodewig]

On 2017-05-22, Dominik Psenner wrote:

> This is a vote to introduce gitflow on the log4net subproject. gitflow
> would mean that we make use of the following named branches:

> * master
> Marks stable milestones and is moves on with a release.

> * develop
> Development of the next milestone should happen here.

> * feature/featurename
>  These should be named branches used to develop a feature that needs
> some crafting and unstable modifications. Only when a feature is complete
> and stable, it should be merged back into develop.

> * hotfix/hotfixname
> Hotfixes branch from master and modifications should happen here. When
> the hotfix is complete, a release should be made and this branch should
> then be merged into master. Please note that modifications to the site
> during a release should also happen here, while this is not an actual
> release.

> * release/releasename
> A release branch used to prepare the codebase for a release.


> +1: Yes!
> +0: Go ahead, don't care that much.
> -0: Don't like it, but not vetoing it.
> -1: No, don't do that! I have a better idea!

> This vote follows the "lazy consensus" (no -1/vetoes). The vote will be
> open for at least 72 hours after that I'm going to push the develop branch.

-0

I personally prefer feature branches and master in the role you assign
to develop, but that's a matter of taste. Please ensure github tracks
develop as the default branch when the vote passes.

Stefan