[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[JJoe2]

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25
  
You’re right.




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

Re: [GitHub] log4net issue #25: API to flush appenders that buffer logging data

[Dominik Psenner]

Said this, one may use his favorite line endings locally. When applying a
patch with different line endings, the applier of tge patch will either
reject the patch or fix line endings on thy fly.

Sorry for the various mails on the same thread. Sending from mobiles is not
really comfortable.

On 16 Oct 2016 5:13 p.m., "Dominik Psenner"  wrote:

> I suggest to agree on one line ending and use that throughout the
> repository.
>
> Until today the only rule that exists is that each file must use exactly
> one type of line endings. Mixed line endings are forbidden by svn
> properties.
>
> On 16 Oct 2016 4:21 p.m., "JJoe2"  wrote:
>
>> Github user JJoe2 commented on the issue:
>>
>> https://github.com/apache/log4net/pull/25
>>
>> The .gitattributes file you committed doesn’t specify line endings
>> for most file types including .cs and .csproj (the most commonly modified
>> ones).
>>
>> However I don’t feel competent to say whether it’s really a good
>> idea.   Having read the section on “Refreshing the repository after
>> changing line endings”, it seems that a number of arcane git incantations
>> may be required to get everything working again after doing so.   Which
>> might cause problems for people who have forked but are struggling with git.
>>
>>
>>
>> ---
>> 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.
>> ---
>>
>

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/log4net/pull/25
  
`text` means "use native line-ends when checking out, translate to LF when 
sending" which is waht we want IMHO.


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

Re: [GitHub] log4net issue #25: API to flush appenders that buffer logging data

[Dominik Psenner]

I suggest to agree on one line ending and use that throughout the
repository.

Until today the only rule that exists is that each file must use exactly
one type of line endings. Mixed line endings are forbidden by svn
properties.

On 16 Oct 2016 4:21 p.m., "JJoe2"  wrote:

> Github user JJoe2 commented on the issue:
>
> https://github.com/apache/log4net/pull/25
>
> The .gitattributes file you committed doesn’t specify line endings for
> most file types including .cs and .csproj (the most commonly modified ones).
>
> However I don’t feel competent to say whether it’s really a good
> idea.   Having read the section on “Refreshing the repository after
> changing line endings”, it seems that a number of arcane git incantations
> may be required to get everything working again after doing so.   Which
> might cause problems for people who have forked but are struggling with git.
>
>
>
> ---
> 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.
> ---
>

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[JJoe2]

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25
  
The .gitattributes file you committed doesn’t specify line endings for 
most file types including .cs and .csproj (the most commonly modified ones).

However I don’t feel competent to say whether it’s really a good idea.  
 Having read the section on “Refreshing the repository after changing line 
endings”, it seems that a number of arcane git incantations may be required 
to get everything working again after doing so.   Which might cause problems 
for people who have forked but are struggling with git.



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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/log4net/pull/25
  
not sure `.gitattributes` will really help, I've copied and commited the 
one I use for XMLUnit.NET.


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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[JJoe2]

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25
  
Thank you for your patience : I’ve learnt a lot about git this weekend 
which will stand me in good stead for the future (still hate it though).

I subscribed to the dev list this morning, and will try to get involved, 
albeit on a small scale once my subscription is confirmed.

Regarding line endings, I suspect that having a .gitattributes file in the 
repository would help: 
https://help.github.com/articles/dealing-with-line-endings/

Did I just volunteer for that job?



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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/log4net/pull/25
  
Many thanks. Even if it may not have looked like it I really appreciate 
what you have done and am sorry about it having been so difficult. The biggest 
problem likely is that this PR has been sitting there way too long without 
anybody providing feedback. You've opened this almost six months ago and that's 
not how it should be. 

https://blogs.apache.org/logging/entry/apache_log4net_needs_help is there 
for a reason.


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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[JJoe2]

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25
  
Replaced by #37 


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

Re: [GitHub] log4net issue #25: API to flush appenders that buffer logging data

[Dominik Psenner]

What do you think of adding a timezone field such that people can calculate
the utc timestamp if they care? Nothing breaks while all usecases are taken
care of.

On 15 Oct 2016 7:23 p.m., "Dominik Psenner"  wrote:

I highly recommend to stay compatible and add a utc timestampas a new field
and deprecate the old field for at least one release cyle.

On 15 Oct 2016 7:20 p.m., "JJoe2"  wrote:

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25

Thanks.

I agree that I should have done a better job of keeping these changes
separate but when I did the initial work I was very much a git novice.
I’ll bite the bullet and separate these changes into two branches with
a rebase on the latest trunk.

I take your point about the binary serialization format.  For now I’ll
roll back the change in the serialization / deserialization methods.  Users
of RemotingAppender will therefore still be subject to ambiguous timestamps
but it’s no longer a breaking change.

We could also consider implementing serialization as follows (perhaps
enabled by a configuration setting if preserving backwards compatibility is
important):


info.AddValue("TimeStamp", m_data.TimeStampUtc);
  // Serialize
m_data.TimeStampUtc = info.GetDateTime("TimeStamp").ToUniversalTime();
  // Deserialize

Given that DateTime.ToUniversalTime() is a noop if the Kind property is
already set to Utc, this would give the correct result if both sides have
the new version, and the following result (ignoring .NET 1.x which didn’t
have a Kind property) for mixed versions:


1.   Old client and new server

Old client serializes as local time; New server converts this to UTC
based on the server’s timezone.  Result unchanged as long as client and
server timezones are the same.


2.   New client and old server



New client serializes as UTC.  Old server will have a UTC time in the
TimeStamp, and will probably interpret it as local time.




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

Re: [GitHub] log4net issue #25: API to flush appenders that buffer logging data

[Dominik Psenner]

I highly recommend to stay compatible and add a utc timestampas a new field
and deprecate the old field for at least one release cyle.

On 15 Oct 2016 7:20 p.m., "JJoe2"  wrote:

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25

Thanks.

I agree that I should have done a better job of keeping these changes
separate but when I did the initial work I was very much a git novice.
I’ll bite the bullet and separate these changes into two branches with
a rebase on the latest trunk.

I take your point about the binary serialization format.  For now I’ll
roll back the change in the serialization / deserialization methods.  Users
of RemotingAppender will therefore still be subject to ambiguous timestamps
but it’s no longer a breaking change.

We could also consider implementing serialization as follows (perhaps
enabled by a configuration setting if preserving backwards compatibility is
important):


info.AddValue("TimeStamp", m_data.TimeStampUtc);
  // Serialize
m_data.TimeStampUtc = info.GetDateTime("TimeStamp").ToUniversalTime();
  // Deserialize

Given that DateTime.ToUniversalTime() is a noop if the Kind property is
already set to Utc, this would give the correct result if both sides have
the new version, and the following result (ignoring .NET 1.x which didn’t
have a Kind property) for mixed versions:


1.   Old client and new server

Old client serializes as local time; New server converts this to UTC
based on the server’s timezone.  Result unchanged as long as client and
server timezones are the same.


2.   New client and old server



New client serializes as UTC.  Old server will have a UTC time in the
TimeStamp, and will probably interpret it as local time.




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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[JJoe2]

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25
  
Thanks.

I agree that I should have done a better job of keeping these changes 
separate but when I did the initial work I was very much a git novice.
I’ll bite the bullet and separate these changes into two branches with a 
rebase on the latest trunk.

I take your point about the binary serialization format.  For now I’ll 
roll back the change in the serialization / deserialization methods.  Users of 
RemotingAppender will therefore still be subject to ambiguous timestamps but 
it’s no longer a breaking change.

We could also consider implementing serialization as follows (perhaps 
enabled by a configuration setting if preserving backwards compatibility is 
important):


info.AddValue("TimeStamp", m_data.TimeStampUtc);  
// Serialize
m_data.TimeStampUtc = info.GetDateTime("TimeStamp").ToUniversalTime();
// Deserialize

Given that DateTime.ToUniversalTime() is a noop if the Kind property is 
already set to Utc, this would give the correct result if both sides have the 
new version, and the following result (ignoring .NET 1.x which didn’t have a 
Kind property) for mixed versions:


1.   Old client and new server

Old client serializes as local time; New server converts this to UTC based 
on the server’s timezone.  Result unchanged as long as client and server 
timezones are the same.


2.   New client and old server



New client serializes as UTC.  Old server will have a UTC time in the 
TimeStamp, and will probably interpret it as local time.




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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/log4net/pull/25
  
@JJoe2 I'm sorry, but now the patch contains all the changes we've made 
since you started your branch. It would be good if you could rebase your branch.

Many thanks for the `w=1` trick, I wasn't aware of it. I do care about 
line-feeds but I care about identifying what has changed more :-) - in svn the 
linefeeds are correct, BTW.

I'd really prefer to keep the Flush and UTC changes separate. That one 
changes binary serialization of `LoggingEvent`s which means people can't use 
different versions of log4net and the remoting sink, for example. Something 
we'd need to document and warn against, if we deem it acceptable.

Actually I would have preferred a separate PR for 57299a4 as well as it is 
a different JIRA issue. I've applied that separately now (and also locked 
`m_ht` in `Clear`) so it should disappear if you rebase your branch.


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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[JJoe2]

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25
  
From your remarks I gather you aren’t too concerned about line ending 
inconsistencies.

And since I did a bit of research today, and discovered that it’s 
possible to ignore whitespace / line endings when reviewing differences on 
github by appending ?w=1 to the url, it doesn’t seem so important to me.

I've now merged with the latest trunk, rolled back the change to 
ILoggerRepository, and also added a timeout to the flush method, so that it 
better handles asynchronous appenders such as RemoteAppender.

It still includes #24 though: is it important to separate these pull 
requests?



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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/log4net/pull/25
  
To be honest I have no idea how svn line ends transfer to the git mirror. 
In svn line ends are CRLF on Windows and LF on Unix. What git makes from this 
depends on your `autocrlf` config and probably on your git client as well (I 
recall cygwin's git insisting on LF).

It's probably best to not touch line ends at all. If that's not possible 
then the best approach may be to create separate commits so that we can at 
least identify the relevant changes.


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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[JJoe2]

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25
  
Some recent commits have changed line endings from LF to CRLF: some of the 
ones that affect me are listed below.  Would it be possible for you to fix 
these line endings in the trunk?  This will make it easier for me to redo my 
work and eliminate merge conflicts.

Appender/DebugAppender.cs
core/LoggingEvent.cs
Util/LogManager.cs
Util/LogLog.cs
Util/SystemInfo.cs



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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[JJoe2]

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25
  
I’ve just fetched the latest trunk into my fork.
As far as I see there are still some line-end inconsistencies in the git 
repository.
For example core/LoggingEvent.cs has CRLF endings while other files such as 
core/LogImpl.cs have LF endings.
My understanding is that LF is preferred, so I have configured my git with 
autocrlf to true.

To handle the inconsistencies I can envisage the following approaches


1.   Push everything with LF and leave you to deal with inconsistencies 
such as LoggingEvent.cs

2.   Whenever I see a file with CRLF, push a commit that fixes this by 
changing to LF, then a second commit with my changes.

Do you have a preference, or a better suggestion?



From: Stefan Bodewig [mailto:notificati...@github.com]
Sent: 13 October 2016 07:58
To: apache/log4net
Cc: JJoe2; Author
Subject: Re: [apache/log4net] API to flush appenders that buffer logging 
data (#25)


I've ensured all line-ends are consistent and set to native in svn trunk - 
git is not our primary repository, 
https://svn.apache.org/repos/asf/logging/log4net/trunk/ is. If you've got 
access to svn maybe it is a better idea to develop your patch against it and 
attach it to JIRA. Using the traditional way :-)

I'd really prefer we don't add any new methods to existing interfaces as 
this may break custom implementations. That's why I didn't want Flush in 
ILoggerRepository. We can't know who has implemented the interface in library 
or application code. LoggerManager could check whether ILoggerRepository 
implemented IFlushable and simply don't do anything in its Flush implementation 
if it didn't.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on 
GitHub, or 
mute the 
thread.



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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/log4net/pull/25
  
Thank you


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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[JJoe2]

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25
  
I don’t have access to svn, so I’ll start by tidying up my fork in 
github this weekend.

I understand your point that adding methods to a public interface is a 
breaking change.  Though it’s also true that it’s unlikely that third 
parties are developing custom implementations of that particular interface.

I agree it’s better to check for IFlushable and will modify accordingly.

From: Stefan Bodewig [mailto:notificati...@github.com]
Sent: 13 October 2016 07:58
To: apache/log4net
Cc: JJoe2; Author
Subject: Re: [apache/log4net] API to flush appenders that buffer logging 
data (#25)


I've ensured all line-ends are consistent and set to native in svn trunk - 
git is not our primary repository, 
https://svn.apache.org/repos/asf/logging/log4net/trunk/ is. If you've got 
access to svn maybe it is a better idea to develop your patch against it and 
attach it to JIRA. Using the traditional way :-)

I'd really prefer we don't add any new methods to existing interfaces as 
this may break custom implementations. That's why I didn't want Flush in 
ILoggerRepository. We can't know who has implemented the interface in library 
or application code. LoggerManager could check whether ILoggerRepository 
implemented IFlushable and simply don't do anything in its Flush implementation 
if it didn't.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on 
GitHub, or 
mute the 
thread.



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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/log4net/pull/25
  
I've ensured all line-ends are consistent and set to native in svn trunk - 
git is not our primary repository, 
https://svn.apache.org/repos/asf/logging/log4net/trunk/ is. If you've got 
access to svn maybe it is a better idea to develop your patch against it and 
attach it to JIRA. Using the traditional way :-)

I'd really prefer we don't add any new methods to existing interfaces as 
this may break custom implementations. That's why I didn't want `Flush` in 
`ILoggerRepository`. We can't know who has implemented the interface in library 
or application code. `LoggerManager` could check whether `ILoggerRepository` 
implemented `IFlushable` and simply don't do anything in its `Flush` 
implementation if it didn't.


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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[JJoe2]

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25
  
Hi Stefan,

Thanks for the feedback.

As you’ll have gathered I’m a novice as far as Git and Github are 
concerned, though slightly less so than I was when I created this patch.

I’ll take a look this weekend and try to produce something better that 
can be merged directly, and separate the patches for the different pull 
requests (UTC; Flush; …).

I suspect the whitespace issues may be caused by different CRLF standards, 
though I’m surprised the diff utility doesn’t ignore such differences.  
IIRC Visual Studio popped up a dialog about inconsistent line endings and 
offered to fix it.   If you have any tips on how to handle this I’m all ears, 
otherwise I’m sure I’ll work it out for myself.

The LogManager.Flush() method is implemented as:


LoggerManager.GetRepository(Assembly.GetCallingAssembly()).Flush();

How would you propose to implement this if the Flush method was moved out 
of ILoggerRepository?

From: Stefan Bodewig [mailto:notificati...@github.com]
Sent: 12 October 2016 22:32
To: apache/log4net
Cc: JJoe2; Author
Subject: Re: [apache/log4net] API to flush appenders that buffer logging 
data (#25)


This PR seems to include #24 as 
well, could you provide a patch without it?

Also, I'm not sure why Flush has been added to ILoggerRepository directly. 
It would be better if LoggerRepositorySkeleton implemented IFlushable IMHO.

The whitespace changes are distracting, it is difficult to see the 
differences in lots of classes.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on 
GitHub, or 
mute the 
thread.



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

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/log4net/pull/25
  
This PR seems to include #24 as well, could you provide a patch without it?

Also, I'm not sure why `Flush` has been added to `ILoggerRepository` 
directly. It would be better if `LoggerRepositorySkeleton` implemented 
`IFlushable` IMHO.

The whitespace changes are distracting, it is  difficult to see the 
differences in lots of classes.


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

Re: [GitHub] log4net issue #25: API to flush appenders that buffer logging data

[Stefan Bodewig]

On 2016-10-12, Dominik Psenner wrote:

> The patch looks sensible. Whats your opinion stefan?

all the whitespace changes are distracting. And the patch contains
changes that are completely unrelated - it seems to contain pull request
#24 as well.

I'll comment on the PR.

Stefan

Re: [GitHub] log4net issue #25: API to flush appenders that buffer logging data

[Dominik Psenner]

The patch looks sensible. Whats your opinion stefan?

On 12 Oct 2016 7:42 p.m., "Salgat"  wrote:

> Github user Salgat commented on the issue:
>
> https://github.com/apache/log4net/pull/25
>
> Any news if this will ever get pulled?
>
>
> ---
> 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.
> ---
>

[GitHub] log4net issue #25: API to flush appenders that buffer logging data

[Salgat]

Github user Salgat commented on the issue:

https://github.com/apache/log4net/pull/25
  
Any news if this will ever get pulled?


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