You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by JJoe2 <gi...@git.apache.org> on 2016/04/23 23:57:53 UTC
[GitHub] log4net pull request: API to flush appenders that buffer logging d...
GitHub user JJoe2 opened a pull request:
https://github.com/apache/log4net/pull/25
API to flush appenders that buffer logging data
Implementation of https://issues.apache.org/jira/browse/LOG4NET-511
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/JJoe2/log4net wip/Flush
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/log4net/pull/25.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #25
----
commit a66d2fc61c4a1cfd8317aee41385ef6c43373ffc
Author: JoeJoe <jo...@hotmail.com>
Date: 2016-04-22T19:21:07Z
Use UTC internally to avoid ambiguous times
commit 9e9f1759d6a80594cd2d12bd54a9e3af9e7cfaa0
Author: JoeJoe <jo...@hotmail.com>
Date: 2016-04-23T19:58:36Z
Implement flushing of appenders that buffer data
----
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net pull request: API to flush appenders that buffer logging d...
Posted by JJoe2 <gi...@git.apache.org>.
Github user JJoe2 commented on the pull request:
https://github.com/apache/log4net/pull/25#issuecomment-214260923
Added two commits including a fix for https://issues.apache.org/jira/browse/LOG4NET-512
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by JJoe2 <gi...@git.apache.org>.
Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/25
I\u2019ve 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:notifications@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.
\u2014
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<https://github.com/apache/log4net/pull/25#issuecomment-253421362>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFY0u5EBnT3LnqX0W-949j7U-fd4djBEks5qzchugaJpZM4IOSN6>.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by JJoe2 <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
Re: [GitHub] log4net issue #25: API to flush appenders that buffer
logging data
Posted by Dominik Psenner <dp...@gmail.com>.
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" <dp...@gmail.com> 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" <gi...@git.apache.org> 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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
Re: [GitHub] log4net issue #25: API to flush appenders that buffer
logging data
Posted by Dominik Psenner <dp...@gmail.com>.
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" <gi...@git.apache.org> 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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by JJoe2 <gi...@git.apache.org>.
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\u2019ll 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\u2019ll roll back the change in the serialization / deserialization methods. Users of RemotingAppender will therefore still be subject to ambiguous timestamps but it\u2019s 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\u2019t 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\u2019s 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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by bodewig <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by JJoe2 <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by bodewig <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by JJoe2 <gi...@git.apache.org>.
Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/25
Thank you for your patience : I\u2019ve 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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by bodewig <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net pull request #25: API to flush appenders that buffer logging data
Posted by JJoe2 <gi...@git.apache.org>.
Github user JJoe2 closed the pull request at:
https://github.com/apache/log4net/pull/25
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by JJoe2 <gi...@git.apache.org>.
Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/25
From your remarks I gather you aren\u2019t too concerned about line ending inconsistencies.
And since I did a bit of research today, and discovered that it\u2019s possible to ignore whitespace / line endings when reviewing differences on github by appending ?w=1 to the url, it doesn\u2019t 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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by bodewig <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by JJoe2 <gi...@git.apache.org>.
Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/25
Hi Stefan,
Thanks for the feedback.
As you\u2019ll have gathered I\u2019m a novice as far as Git and Github are concerned, though slightly less so than I was when I created this patch.
I\u2019ll 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; \u2026).
I suspect the whitespace issues may be caused by different CRLF standards, though I\u2019m surprised the diff utility doesn\u2019t 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\u2019m all ears, otherwise I\u2019m sure I\u2019ll 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:notifications@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<https://github.com/apache/log4net/pull/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.
\u2014
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<https://github.com/apache/log4net/pull/25#issuecomment-253330546>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFY0u7no2CA1aE7ZfZEWE9hxc_YACHeHks5qzUPcgaJpZM4IOSN6>.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by bodewig <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
Re: [GitHub] log4net issue #25: API to flush appenders that buffer
logging data
Posted by Dominik Psenner <dp...@gmail.com>.
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" <dp...@gmail.com> 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" <gi...@git.apache.org> 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 infrastructure@apache.org or file a JIRA ticket
>> with INFRA.
>> ---
>>
>
Re: [GitHub] log4net issue #25: API to flush appenders that buffer
logging data
Posted by Dominik Psenner <dp...@gmail.com>.
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" <gi...@git.apache.org> 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 infrastructure@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by JJoe2 <gi...@git.apache.org>.
Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/25
The .gitattributes file you committed doesn\u2019t specify line endings for most file types including .cs and .csproj (the most commonly modified ones).
However I don\u2019t feel competent to say whether it\u2019s really a good idea. Having read the section on \u201cRefreshing the repository after changing line endings\u201d, 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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by JJoe2 <gi...@git.apache.org>.
Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/25
You\u2019re 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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by bodewig <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
Re: [GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by Stefan Bodewig <bo...@apache.org>.
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
Posted by Dominik Psenner <dp...@gmail.com>.
The patch looks sensible. Whats your opinion stefan?
On 12 Oct 2016 7:42 p.m., "Salgat" <gi...@git.apache.org> 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 infrastructure@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by Salgat <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by bodewig <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by JJoe2 <gi...@git.apache.org>.
Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/25
I don\u2019t have access to svn, so I\u2019ll 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\u2019s also true that it\u2019s unlikely that third parties are developing custom implementations of that particular interface.
I agree it\u2019s better to check for IFlushable and will modify accordingly.
From: Stefan Bodewig [mailto:notifications@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.
\u2014
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<https://github.com/apache/log4net/pull/25#issuecomment-253421362>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFY0u5EBnT3LnqX0W-949j7U-fd4djBEks5qzchugaJpZM4IOSN6>.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] log4net issue #25: API to flush appenders that buffer logging data
Posted by bodewig <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---