Sorry for the JIRA Spam

[Stefan Bodewig]

Hi

there's been a cycle where a mailer daemon responded to a JIRA ticket
because of an "undeliverable" notification and this response caused a
new comment creating a new mail to the same failing address ...

Over the course of the day I've been wading through the comments,
deleting them one by one. I thought JIRA notifications had been going to
a special "issues" list and never thought I'd be spamming more people
than just myself and Dominik. I'll stop deleting the comments
immediately.

Sorry for the noise

  Stefan

Re: Sorry for the JIRA Spam

[Stefan Bodewig]

On 2017-01-18, Dominik Psenner wrote:

> Interesting. I dont mind the spam unless i have to look at all the content
> to filter the spam manually. Can i safely mark everything as read or is
> there anything i have to catch up with?

You can savely remove all comments for LOG4NET-435, there may be
something worth looking at for LOG4NET-539 and LOG4NET-549.

Stefan

[ANN] New Committer Joe

[Stefan Bodewig]

Hi all

on behalf of the log4net committers it's my pleasure to announce that
Joe has been elected as a new log4net committer.

Please join me in welcoming him.

Cheers

Stefan

ParallelAppender (was Re: log4net/pull/40)

[Stefan Bodewig]

Hi Harry,

sorry for the delay and many thanks for hanging around and nudging
us. This is obviously something we need.

Harry has created a pull request that adds a feature of a
ParallelAppender using TPL which, when enabled wraps all configured
appenders and makes their logging asynchrounous.

I've seen big overlap with Joe's work on an AsyncAppender and asked
Harry to head over here for comments. I'm not really sure how the two
approaches relate to each other and whether it would be a good idea to
keep both of them in parallel or to merge them into one.

My initial comment would be that I wouldn't want to enable
parallel/async workflows unconditionally for all appenders but rather
make people use the corresponding decorators explicitly when configuring
their appenders.

Stefan

Re: ParallelAppender (was Re: log4net/pull/40)

[Stefan Bodewig]

On 2017-02-19, Stefan Bodewig wrote:

> I've seen big overlap with Joe's work on an AsyncAppender

which I think is
https://github.com/JJoe2/log4net/commits/wip/AsyncAppender

Stefan

Releasing 2.0.8?

[Stefan Bodewig]

Hi all

apart from the LockRecursionException Joe has fixed, we probably should
also bring back support for LogicalThreadContext for the .NET Standard
build.

I'll try to find time to build the release during the coming days, is
there anything that should be done before starting the release process?

Cheers

Stefan

Re: Releasing 2.0.8?

[Stefan Bodewig]

On 2017-03-06, Dominik Psenner wrote:

> Testing and applying the patch for LOG4NET-553 is on my todo, but
> can't see when I can free the spare time to actually get it done.

I see.

Maybe we really should get back into the habbit of more frequent
releases. :-)  If that's ever been the case, I'm not sure.

Schedule LOG4NET-553 for 2.0.9?

Stefan

Re: Releasing 2.0.8?

[Stefan Bodewig]

On 2017-03-06, Dominik Psenner wrote:

> The codereview of 553 is fine and includes reasonable unittests. The
> regression tests for all supported framework targets is the bottleneck here.

What kind of regression tests do you envision? Is there anything I or a
different member of the community can do to move this forward?

Stefan

Re: Releasing 2.0.8?

[Stefan Bodewig]

On 2017-03-07, Dominik Psenner wrote:

> *hm*

> Rereading the patch its probably safe to just apply the patch [1] and
> check if all the unittests pass.

> [1]
> https://issues.apache.org/jira/secure/attachment/12852105/log4net-DebugAppenderCategory3.patch

That's something I can do, I'll run them on the zoo of platforms I use
to build releases.

Stefan

Re: Releasing 2.0.8?

[Stefan Bodewig]

On 2017-03-07, Stefan Bodewig wrote:

> On 2017-03-07, Dominik Psenner wrote:

>> *hm*

>> Rereading the patch its probably safe to just apply the patch [1] and
>> check if all the unittests pass.

>> [1]
>> https://issues.apache.org/jira/secure/attachment/12852105/log4net-DebugAppenderCategory3.patch

> That's something I can do, I'll run them on the zoo of platforms I use
> to build releases.

Done. All trunk tests pass on .NET 2.0, 3.5 and 4.0 as well as .NET Core
1.0 - all tests that didn't fail before applying the patch also pass on
Mono 2.0, 3.5 and 4.0.

I've committed the patch and closed LOG4NET-553.

Stefan

Re: [VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Stefan Bodewig]

On 2017-03-08, Matt Sicker wrote:

> I may be missing some mailing lists considering I just subscribed to half
> of them less than five minutes ago.

> This is a vote to merge the various Apache Logging Services mailing lists.
> The proposal is to combine them as follows:

> log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ ->
> d...@logging.apache.org

+1

> log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ ->
> u...@logging.apache.org

-1

I don't think the users would benefit from a shared list and would
prefer to keep them separate (this is not a veto, just a vote).

Stefan

[VOTE] Release log4net 2.0.8 Based on RC1

[Stefan Bodewig]

Hi all

log4net 2.0.8 RC1 is available for review here:
  https://dist.apache.org/repos/dist/dev/logging/log4net
  (revision 18620)

Details of changes since 2.0.7 are in the release notes:
  https://stefan.samaflost.de/staging/log4net-2.0.8/release/release-notes.html

I have tested this with Mono and several .NET frameworks using NAnt.

The tag is here:
  https://svn.apache.org/repos/asf/logging/log4net/tags/2.0.8RC1
  (revision 1786048)

Site:
  https://stefan.samaflost.de/staging/log4net-2.0.8/

RAT Report:
  https://stefan.samaflost.de/staging/log4net-2.0.8/rat-report.html

Nuget Package:
  https://www.myget.org/feed/log4net-test/package/nuget/log4net

Votes, please.  This vote will close no sooner than in 72 hours,
1900 GMT 11-Mar 2017

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thanks!

Stefan

Re: [VOTE] Release log4net 2.0.8 Based on RC1

[Stefan Bodewig]

On 2017-03-08, Dominik Psenner wrote:

> I am looking through the release and am going to give a few feedbacks
> during the next hour. The first thing i noticed is this:

> The website page 'features' still mentions that log4net has builds for
> ancient .net framework versions. We should change that.

Sure. But we can do so independent of any release anyway.

Thanks

Stefan

[RESULT] Release log4net 2.0.8 Based on RC1

[Stefan Bodewig]

Hi all

with +1s by Remko Popma, Matt Sicker, Dominik Psenner and my own
implicit one the vote has passed.

I'll continue with the release process and will give the mirrors a bit
of time before I send out the announcement mail.

Thanks

Stefan

[ANN] Apache log4net 2.0.8 Released

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Apache log4net team is pleased to announce the release of Apache
log4net 2.0.8.  The release is available for download at

https://logging.apache.org/log4net/download_log4net.cgi

as well as via nuget

https://www.nuget.org/packages/log4net/

The Apache log4net library is a tool to help the programmer output log
statements to a variety of output targets.  log4net is a port of the
excellent Apache log4j framework to the Microsoft(R) .NET runtime.

Apache log4net 2.0.8 fixes a LockRecursionException that could happen
inside the FileAppender under certain circumstances. It also adds
support for LogicalThreadContext to the .NET Standard build based on
AsyncLocal rather than CallContext.

See the release-notes at

http://logging.apache.org/log4net/release/release-notes.html

for a full list of changes.

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on log4net, including instructions on how to
submit bug reports, patches, or suggestions for improvement, see the
Apache log4net website:

http://logging.apache.org/log4net/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAljE2jkACgkQohFa4V9ri3KGaQCg0UBteNnBmUI0x3O3JL/drZba
dy8An0As0KHbyeyxahHRcA5FaZJau/bl
=b9b6
-END PGP SIGNATURE-

Re: cvs commit: logging-log4net/src/Util PatternString.cs

[Stefan Bodewig]

Nicko,

I've seen that in several commit mails now.  It seems the sources have
been copied from a Windows system to a Unix box and committed from
there.  All files I've seen so far have been checked in with Windows
line-ends inside the file.  Is this intentional?

I think somebody with CVS karma and access to a Unix box should fix
all line-ends (using dos2unix, tr or Ant's  task, for
example) and re-commit the files.

Stefan

Re: cvs commit: logging-log4net/src/Util PatternString.cs

[Stefan Bodewig]

On Wed, 11 May 2005, Nicko Cadell <[EMAIL PROTECTED]> wrote:

> I use cygwin cvs which is configured to work in UNIX mode on my
> WinXP box. This is not really by design, its just the way it is
> right now.

I don't want to make an issue of this, but I'm curious.  Why are you
using the UNIX mode instead of DOS?  Is there some other tool that
works better that way?  Is it just "for historic reasons"?

Stefan

Re: cvs commit: logging-log4net/src/Util PatternString.cs

[Stefan Bodewig]

On Thu, 12 May 2005, Nicko Cadell <[EMAIL PROTECTED]> wrote:

> I haven't played around with subversion too much and I don't know
> how it deals with the LF / CRLF issue, I guess we will find out ;)

Unlike CVS, Subversion treats all files as binary files - and doesn't
do any keyword expansion either - unless you tell it to.  You have to
set properties on the individual files to make it translate line-feeds
or make any other changes.

For people working on Unix it is a bit annoying if you have cariage
returns in the files and as soon as you have a committer working on
Unix you may end up with files that have mixed line-ends since the
code she/he added would have line-feeds only.

Where it becomes a real problem is when you have Unix shell scripts in
the module since the shell will see the cariage return in the she-bang
line and fail with something like "file not found /bin/sh^M" where ^M
is a \r and easy to overlook.

Stefan

Re: Ron Grabowski as a committer for log4net

[Stefan Bodewig]

I've been a lurker on the log4net lists for a while now, so even if my
"vote" isn't binding, I still want to express a strong +1.

Stefan

Re: Ron Grabowski as a committer for log4net

[Stefan Bodewig]

On Fri, 2 Sep 2005, Nicko Cadell <[EMAIL PROTECTED]> wrote:

> The Logging PMC has voted in favour of adding Ron as a committer on
> log4net.

Congrats!

Stefan

Re: svn commit: r331170 - in /logging/log4net: ./ trunk/

[Stefan Bodewig]

On Wed, 9 Nov 2005, Ron Grabowski <[EMAIL PROTECTED]> wrote:

> Is there a switch for svn.exe to make it recursively touch only
> folders?

I don't think so.  But on a Unix box or using Cygwin something like

find . -type d ! -name .svn -print0 \
| xargs -0 -e svn propset PROPNAME PROPVAL

should work (untested).  If your find doesn't support -print0 (i.e. no
GNU find), use print and drop the -0 in xargs - and hope you don't
have spaces in any file names.

Stefan

Re: Escaping the incubator

[Stefan Bodewig]

On Tue, 19 Sep 2006, Ron Grabowski <[EMAIL PROTECTED]> wrote:

> I think most people would agree that log4net has been considered
> quite stable for a number of years.

+1

In addition you've done two releases at Apache and demonstrated you
work as a community already.

Curt and log4net team, if you need any ASF member support (like having
another mentor for the project), let me know.

Stefan

Re: [g...@vmgump]: Project logging-log4net (in module logging-log4net) failed

[Stefan Bodewig]

On Mon, 10 Mar 2008, Gert Driesen <[EMAIL PROTECTED]> wrote:

> Anyone happen to know if an upgrade of Mono or NAnt was done prior
> to this failure?

We should be building against a hand-installed Mono 1.2.4, but I see
there also is a system installed mono 1.2.3 on vmgump.  I don't recall
installing it and it may have been a side-effect of anybody else doing
an apt-get upgrade.

I will remove the system installed one and we'll see whether it fixes
the problem.

Stefan

Re: [g...@vmgump]: Project logging-log4net (in module logging-log4net) failed

[Stefan Bodewig]

On Tue, 11 Mar 2008, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

On Mon, 10 Mar 2008, Gert Driesen <[EMAIL PROTECTED]> wrote:

>> Anyone happen to know if an upgrade of Mono or NAnt was done prior
>> to this failure?
> 
> We should be building against a hand-installed Mono 1.2.4, but I see
> there also is a system installed mono 1.2.3 on vmgump.  I don't
> recall installing it and it may have been a side-effect of anybody
> else doing an apt-get upgrade.

Given how short the list for apt-get upgrade is, this has probably
been done pretty recently.

> I will remove the system installed one and we'll see whether it
> fixes the problem.

Well, I can't do so easily because mono is required by the system
installed nant that is used to build log4net.

I don't recall the details of why we are using a system installed NAnt
instead of the Gump built one, Curt was the one behind it IIRC.

Stefan

[OT] How do you deal with signing the DLLs?

[Stefan Bodewig]

Hi,

I'm turning to you for advice as the .NET open source project who's
community I know best 8-)

Since about a year and a half I've talen over maintaining XMLUnit
which has a Java and a .NET version.  A few weeks ago I released the
.NET version and now a user asked me to release a strongly named
version of it.

Right now I'm the only one working on XMLUnit but I'd hope this will
change in the future, so keeping the key private to myself is not a
real option.  Putting it into subversion doesn't feel right, either.

I see that you do not ship your key file with the distribution and it
seems that the keys file itself is encrypted in svn (at least this is
what I guess log4net.snk.gpg is).  How is this better than simply
sharing the .snk file between developers?  Why have you decided to do
it the way you do?

Thanks

Stefan

Re: abandoned?

[Stefan Bodewig]

Disclaimer: even though I own and use an @apache.org address I'm not a
log4net developer, only a user and interested observer - and a
contributor to a couple of other ASF projects.  I don't speak for
log4net.

On 2010-04-29, Kirill Temnenkov  wrote:

> I think that the project be abandoned. Am I right?

I hope you are not - if you look at the JIRA issues those get addressed,
likewise questions on this and the user list do get answered.
Unfortunately there hasn't been any coding action in four months.

What the problem needs most IMHO is a new release (and I'd be glad to
help out if I can).

> Can I participate in the development as a developer?

Make yourself familiar with .

Anybody can participate by asking or answering questions, finding or
fixing bugs, suggesting or implementing new features.  The preferred
channels are the mailing lists and JIRA.

In Apache projects, if you stick around long enough and provide enough
patches the committers usually get tired of applying your patches and
you become a committer yourself.

Cheers

Stefan

Re: abandoned?

[Stefan Bodewig]

On 2010-05-03, Ron Grabowski  wrote:

> I agree with getting out a small point release before a large refactor.

+1

You may even consider to change the major version with the refactoring,
i.e. release a 1.1 compatible log4net 1.2.x soon and call the .NET 2.0+
version log4net 2.x

Stefan

Re: abandoned?

[Stefan Bodewig]

On 2010-05-03, Dominik Psenner  wrote:

> But as long there are no breaking API changes needed to get log4net running
> with .net4.0 I would not target it as a major release, but more or less a
> 1.4.x.

Ron talked about taking advantage of generics in the API which would be
a breaking change.  Otherwise I agree with you that changing the major
version shouldn't be required.

Stefan

Re: [jira] Created: (LOG4NET-257) Visual Studio 2010 .NET 4.0 Application does not copy log4net lib to bin directory

[Stefan Bodewig]

On 2010-05-03, Ron Grabowski  wrote:

> I just read that nant has a new release candidate out that supports
> .NET 4.0. Someone may want to try running that against the code base
> as that's how the final releases are built.

I ran the beta1 on NAnt 0.90 against log4net's build file in the root
dir of trunk and it worked without any problems.  Anything specific I
should be looking out for?

Stefan

Re: Compiling log4net with strong name and 3rd party dependencies (also is log4net in a cul-du-sac)

[Stefan Bodewig]

On 2011-08-09, Curt Arnold wrote:

> For those who want to drive a release forward, I would suggest:

> Create a bug report for the next release (check if there is already
> one)

JIRA already has 1.2.11 as release version and tons of issues assigned
to it.  20 are still open 34 are already in the resolved state.

Some triage may be in order.  34 fixed issues sounds huge and it may
very well be worth pushing back some issues without patches and release
the rest now rather than waiting for the rest.

I'm not sure we need a separate issue for the release itself when JIRA
provides the roadmap view.

> If there are any debatable issues (like dropping support for earlier
> .NET versions), start a vote on the mailing list. If there are
> interrelated issues, perhaps create a page on the logging wiki and
> have a vote on all the issues in the same time.

> If there are bugs without test cases or patches, create test cases and
> patches.

> If there are bugs with test case and patches that should be committed,
> make a comment on the bug that it appears ready to go.

> Hopefully through this process, we can develop the track record that
> will allow adding some new committers or PMC members.

Sounds like a plan.

Stefan

Re: Compiling log4net with strong name and 3rd party dependencies (also is log4net in a cul-du-sac)

[Stefan Bodewig]

[cross-posted so people don't duplicate effort, rest should only happen
on the dev list]

On 2011-08-09, Stefan Bodewig wrote:

> On 2011-08-09, Curt Arnold wrote:

>> For those who want to drive a release forward, I would suggest:

>> Create a bug report for the next release (check if there is already
>> one)

> I'm not sure we need a separate issue for the release itself when JIRA
> provides the roadmap view.

Created one anyway <https://issues.apache.org/jira/browse/LOG4NET-299>

Stefan

Re: Compiling log4net with strong name and 3rd party dependencies (also is log4net in a cul-du-sac)

[Stefan Bodewig]

Hi Jim,

On 2011-08-10, Jim Scott wrote:

> On 8/8/2011 8:34 PM, Curt Arnold wrote:

>> I'd be happy to perform the release build or reencrypt the strong
>> signing key to another PMC member who wants to help. However, to get
>> to that point, it will take people who are motivated to pitch in and
>> get things ready for release. Further discussion should be on
>> log4net-dev.

> Curt, I am more than interested in helping this project move
> forward.

This sounds great.

> However I am not 100% confident that I would be able to do things
> exactly to the standard expected so would need some guidance in
> providing help if you are interested in having me participate.

Don't worry.

Most people around here won't know me as I'm just a user of log4net
myself and haven't contributed much to it.  In 2000 I became involved
with the Apache Software Foundation as a committer to Apache Ant - some
small build tool nobody knew back then that initially was used to build
Tomcat and was later spun out as a separate project.  Those familiar
with the Java space will know what has grown out of it.  After that I've
helped out here and there and still am a committer and PMC member at Ant
(and a few other places).  But when I started I was sure I could never
meet the standards of the ASF.

One of my first contributions to Ant was some helper code that allowed
me to use the small - by then - unknown testing library from inside my
builds, the  task.  The initial code was quite limited and even a
bit hackish in places, it did what I needed and others expanded upon it.

What I'm trying to say here is that it is better to have some start,
even if not perfect, than nothing at all.  A bad implementation may even
be a good way to get the community involved.  I think Cocoon's founder
Stefano Mazzocci once coined "great ideas and crappy code" as the best
fertilizer for open source communities.

When I wrote the initial version of the code that maps XML elements and
attributes to Java objects in Ant using lots of reflection this was the
first time I used any class from the Java reflection package.  I learned
a lot from it and I learned even more from the improvements others made
to my code.

There is a lot of value in developing in the open.  Each time anybody
provides a patch to code you've written you learn something new and
become a better developer.  And the discussions in most communities are
very very fruitful, there are very few jerks around the ASF.

Again, don't worry, just jump in, the water is fine.

Stefan

Re: Compiling log4net with strong name and 3rd party dependencies (also is log4net in a cul-du-sac)

[Stefan Bodewig]

Hi Roy

On 2011-08-10, Roy Chastain wrote:

> I have volunteered my services before, but unfortunately, I don't know
> how to use ANY of the tools required to interface with Jira and the
> source control.

Interfacing with JIRA really doesn't involve anything but a browser.  I
know there are some integrations into Eclipse, maybe even Visual Studio,
but I've never used anything but Firefox for it myself.

The recent JIRA releases are pretty JavaScript-heavy so I wouldn't
recommend using older IEs.

Subversion is the main tool and likely the biggest hurdle.  I come from
a Unix background myself and am a command line kind of person so I'm not
sure about the options but there are GUI frontends to Subversion as well
(TurtoiseSVN or something like that).

The command line "svn diff" creates exactly the kind of output that
people expect as "patches" attached to JIRA.  I'm sure the GUI frontends
will provide a way to get exactly that as well.

The ideal workflow if you think you've found a bug would then be:

(1) check out source code from svn

(2) write a unit test that verifies the bug

(3) fix the bug

(4) open a JIRA ticket

(5) create a patch by using svn diff

(6) attach the patch to the ticket

(7) revert your changes in your local copy and tackle the next bug

You may need to "svn add" new files before creating the patch.

If you do that often enough, you'll eventually gain write access and can
forget about the patch, at which point the flow continues as

(5) commit your changes

(6) resolve the JIRA issue

and there will be nothing to revert.

Cheers

Stefan

Re: Compiling log4net with strong name and 3rd party dependencies

[Stefan Bodewig]

On 2011-08-08, Johannes Gustafsson wrote:

> There are a few bugfixes in the trunk that I need and since there has been
> no new release for a very long time, I tried to compile it myself. I created
> a key and have successfully compiled it with no problems. However, I have
> quite a few 3rd party dependencies that themselves are dependent on log4net.
> These dependencies can't find load the new assembly that I have created
> because they require that it is signed with a key that I dont have access
> to. So this means that I can't use my own version of log4net without
> recompiling all my dependencies.

> Do you have any suggestions to how I can solve this?

For your current situation I don't have one, sorry.  Helping to get
log4net 1.2.11 released by verifying fixes might be an option ;-)

For future releases I'd suggest to take a different approach - and this
likely is a discussion point for the dev list.  Therefore the
cross-post, please let us keep the discussion there.

I happen to be one of the ASF Incubator mentors for Lucene.NET and the
question of whether they should strong name their assembly at all and if
they should keep the signing key secret came up there for their last
release - well, they didn't really question it, I did.

Several people had good arguments towards strong naming - there are
deployment situations where it is simply necessary to use the GAC, think
BizTalk.  And several people had good arguments to simply give the
signing key away to everyone, this would help you in your case.

This seems to be consensus by now by pretty much all Open Source
projects in the .NET space.  Just hand out your signing key so people
can create their own patch builds - as they can do for any other
platform as well.  There is absolutely zero security attached to that
key if used that way, but that doesn't matter since our releases are
signed using OpenPGP and we provide hashes of everything.

I'd propose to not keep the signing key of future releases secret but
simply keep the full keypair inside the source tree.

Stefan

Re: Compiling log4net with strong name and 3rd party dependencies

[Stefan Bodewig]

On 2011-08-11, Curt Arnold wrote:

> On Aug 10, 2011, at 10:38 AM, Stefan Bodewig wrote:
>> I'd propose to not keep the signing key of future releases secret but
>> simply keep the full keypair inside the source tree.

>> Stefan

> I'm fine with that as long as it is a different key than that which
> signed the earlier releases which had some at least implied promise of
> signing key secrecy that we should not undo.

+1

That's why I proposed it for future releases.

> Likely that would mean that we would need to build assemblies with the
> previous key for those who want a dropin replacement for earlier
> log4net and figure out if we want to distribute compiled assembles
> with the open key or just distribute the source.

Right now I'd lean towards making breaking changes for a 1.3.x line of
releases and using the new key there, I'm not sure whether signing those
with the old key would be useful at all.

As for distributions, I think the community needs to rethink what type
of assemblies should be distributed anyway - I'm not convinced separate
Mono assemblies are needed anymore, for example.  There may be value in
assemblies that are not strong named at all in addition to those signed
with an open key.

Stefan

Build/Release instructions?

[Stefan Bodewig]

Hi,

I've checked out trunk and tried to build it and run tests using NAnt on
both my $work Win7 machine and my private Linux box.  I opened a few
JIRA tickets on the way.

Is there any document that I have missed on what I'm expected to have
installed if I want to do a full build that would be needed for a
release?

Right now the only framework I have installed is 4.0 (alongside VS2010
which I deliberately do not use to build log4net) and so NAnt only
builds the net/2.0 and net/3.5 assemblies.  I may be able to arrange
something for the older frameworks and compact versions at work (can't
promise anything, though) but would need to know what to install.

On the Mono side using Ubuntu and the Mono Project PPA works OK but I
get more than 50 failed unit tests - as opposed to the about ten failed
tests I get on Windows using MS .NET.  What are the expectations for
Mono support?

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-12, Roy Chastain wrote:

> I have finally gotten an environment allows me to get source etc.

Great.

Have you got an environemt where you can build the 1.x and compact
framework assemblies (right now I don't)?  SSCLI?

> My questions are of the following types
> 1) - Do we have a plan?

Not yet.  8-)

Your list matches my ideas pretty well.

> 2) - How do we prevent duplication of effort?

This list, wiki, JIRA.  Right now it doesn't look to me as if we had so
many people that we could lose track.

Short term we'll be slowed down by the fact that there are only very few
people with write access to the source tree, of course.

> 3) - Someone mentioned a poll.  I would be glad to setup a survey on my
> SharePoint site.

Thanks.

> I have seen the discussions on public vs. private signing key.  I second
> the idea of switching to a publicly usable key, but maintain the private
> key for a "release" build so that the 3rd party vendors have something
> to reference.  I am sure that some of them will require strongly names
> assemblies.

You mean you'd still want to use a secret key for "release" in either
case or just as an alternative distribution in addition to one signed
with the new non-secret key?

> I have seen the discussion on our first steps, but I have not observed a
> consensus.  I would lay out the following as our steps.
> 1) - Produce the 1.2.11 build with all currently available fixes.
> Signed with the old key and all the current platforms.

+1

I'd suggest we triage JIRA to see whether there are any open issues that
(1) are bugs and not feature requests, (2) come with tests that fail and
(3) come with a patch that makes the test pass.  If there are any such
issues they could go into 1.2.11 IMHO.  Otherwise 1.2.11 is long overdue
anyway.

> 2) - Move to a 2.0 build tree that drops support for .NET 1.0, 1.1,
> Compact etc.  Produce a release with the same fixes as the 1.2.11 build
> and sign with the old private key.

How would that be different from the first step - except that we'd
distribute fewer assemblies in the binary distribution?  Do you plan to
remove all 1.0/1.1 specific code and the conditional compilations for
NET 2.0 so that this release actually used different source code?

> 3) - Start the 4.0 build tree (match the framework level) which targets
> the 4.0 Framework and is refactored so that it can run with a Client
> only framework when the non-Client support namespaces are not required
> by the application or requested appender.  (2 DLLs).  This gets signed
> with the private key and the new public key (2 distribution packages.)
> This version will support 4.0 and up only.

Totally agreed that this is needed.

I'd poll for 3.5 support as well.

> (MONO if needed??)

Mono is at the 4.0 level in many things and not even at 3.5 in others.
For the things log4net currently uses it should work fine AFAICT.

> 4) - Apply the same refactoring to the 2.0 build tree to allow targeting
> the 3.5 Client install.  (I believe this is a lower priority than the
> 4.0 simply because I do not believe that many people have attempted
> deployment with the 3.5 client set.  (I could easily be wrong.)

Should have read to the end before I started typing ;-)

I'd prioritize your steps 3 and 4 with the help of a poll among users to
see how urgently 3.5 support is needed.  I agree I have seen way more
questions about 4.0 than 3.5, though.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-12, Roy Chastain wrote:

>> Have you got an environment where you can build the 1.x and compact
>> framework assemblies (right now I don't)?

> I could at one point a few years back, but probably not now.

The same is true for my own environment.

> I was referring more to just being able to get the source from the
> tree.  (For me getting anything SubVersion related working is a BIG
> step). :-)

Congrats, then. 8-)

> That was part my question about duplicating effort.  If changes need
> to be made to get an environment that supports building, there is no
> need for multiple people to tackle it at once.

This is true, but at least for the next release we'll need one
accessible for the release manager.

> In the past I converted the zipped source to VS 2010 keeping the 2.0
> framework target and made that work, but I did not work on tests etc.,
> so I don't know how valid my efforts were.

So far I still don't want to use VS at all but stick with the NAnt
build.  I'm not familiar enough with the express editions - does anybody
know whether VS 2010 Express supports setting the compilation target to
2.0?  We can't expect contributors to own one of the non-free editions.

>> just as an alternative distribution in addition to one signed with
>> the new non-secret key?

> Yes, both versions.  I think that is necessary to keep the 3rd party
> people running until they have time to switch to the new non-secret key.

OK, then we agree.

>> Otherwise 1.2.11 is long overdue anyway

> Yes, I agree, that is way I was suggesting doing the "minimum" which is
> basically integrating the currently supplied/tested/gold fixes and
> features (such as the log file renaming feature-fix).  Feature requests
> and fixes that need work go into the 4.0 build tree (and the refactored
> 3.5 build tree which was my step 4).  This approach should allow for an
> "easy" (not hardly) production of the 1.2.11 that would be a drop in for
> anyone on 1.2.10 with the fixes/features that have been tested.

Yes.

> Maybe we have to revisit the bug/feature list and produce 1.2.12 with
> the next round before going on to 2.0 tree with less frameworks.  Once
> we do the 2.0 tree the 1.2.xx tree is frozen and we have less to
> maintain because we do not have to worry about 1.0, 1.1, compact etc.
> To sum up this paragraph, we produce a new stable long life span
> product (1.2.11 or 1.2.12) that people who do not wish to/cannot move
> forward can use for a long time to come.

Sounds good to me.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-12, Tasos Vogiatzoglou wrote:

> I had submitted a patch about building log4net for 2010 (.NET 4 Client
> profile and .NET 4) which also fixes an issue in the UdpAppender.

> https://issues.apache.org/jira/browse/LOG4NET-296

There are a few indentation changes and the rest should be straight
forward to apply.  I may give a NAnt build for client profile a try at
one point.  NAnt doesn't specifically mention it would support the
client profile as target, though.

Is the one line fix in IPAddressConvert all that is needed for
UdpAppender?  If so we could do with conditional compilation here (use
GetHostByName for frameworks prior to 2.0 and GetHostEntry  for
framework 2.0+) and push that into 1.2.11.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-12, Dominik Psenner wrote:

> On 08/12/2011 07:19 PM, Stefan Bodewig wrote:
>> Short term we'll be slowed down by the fact that there are only very few
>> people with write access to the source tree, of course.

> Could the short term development be done in a remote repository,
> likewise hg hosted on bitbucket?

We do have a read-only git version at git://git.apache.org/log4net.git
<http://git.apache.org/log4net.git/> mirrored at github as well
<https://github.com/apache/log4net>

Given that svn is new to some of the people who raised their hand to
help I'm a bit reluctant to add yet another tool new to them to the mix
(and throw in something like git-svn or hg-svn on top of that).  Combine
that with the change in philosophy a distributed VCS brings.

> One would not need to have write access to the original source and can
> still work versioned. If one keeps a strict linear history (no
> merges), one should also be able to push changes back to the svn
> repository.

I agree this would work and would be willing to give it a try with
people who want to work that way.  But this really depends on the people
who will actually do the commit to svn (which I currently can't do
myself either).

Thanks for setting up the hg mirror.

   Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-12, Dominik Psenner wrote:

> The operation could take some time. Once it is done, there should be 553
> changesets. The last would be:

> changeset:   553:7f145743e63e
> tag: tip
> user:rgrabowski@13f79535-47bb-0310-9956-ffa450edef68
> date:Wed Oct 13 03:26:57 2010 +
> summary: Additional fix for LOG4NET-59 to ensure correct call to
> System.IO.File.GetLastWriteTime or GetLastWriteTimeUtc

Yes, this should be the current trunk version.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-13, Dominik Psenner wrote:

> On 08/12/2011 10:46 PM, Dominik Psenner wrote:
>> I actually just cloned the apache svn and am currently pushing the
>> changes to a bitbucket repository here:

>> https://bitbucket.org/NachbarsLumpi/log4net

> FWIW, I managed to apply some of the patches that were submitted into a
> fork of the just created log4net clone:

> https://bitbucket.org/NachbarsLumpi/log4net-patches/changesets

> For now they're just placed on top of the svn revisions that those
> patches apply to.

Great.

> For each of them we have to:

>  * see if the patches are not fixed already
>  * see if they fit into the current latest tip (trunk)
>  * revise if they include sane changes
>  * determine if they should be included in the upcoming release

If you do any of these, could you note it as a comment inside the
corresponding JIRA tickets?  This would reduce the chance of people
duplicating work.

Thanks!

Stefan

Re: Open issues for 1.2.10 release

[Stefan Bodewig]

On 2011-08-13, Dominik Psenner wrote:

> There are 9 open issues targeted for 1.2.10. They should probably be
> rescheduled to be included in 1.2.11?

I'm not even sure whether some of them still are relevant.  They
certainly need to be rescheduled.

My preference would be to have some release like 1.2.MAINTNENANCE that
we'd assign things to that may eventually get fixed in a 1.2.x release
if we agree that these are the versions that actually work for compact
framework and 1.x - and a few others similar unspecific releases.

We then pick the pieces from there as we prepare real releases.

Right now I'm afraid we'll have to visit all open issues and
re-assign/close them.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-13, Dominik Psenner wrote:

> On 08/13/2011 06:34 AM, Stefan Bodewig wrote:
>>> For each of them we have to:
>>>  * see if the patches are not fixed already
>>>  * see if they fit into the current latest tip (trunk)
>>>  * revise if they include sane changes
>>>  * determine if they should be included in the upcoming release

>> If you do any of these, could you note it as a comment inside the
>> corresponding JIRA tickets?  This would reduce the chance of people
>> duplicating work.

> Sure thing. Can we place some other comments somewhere so that others
> can find out that there's a repository they could actually work on?

We could do so, but right now I'd be happy if we could get to work
within the existing processes - patch attached to JIRA, commit to svn -
any time soon.

I'd really hope there will be lots of "others" but so far I'm not
convinced we'll be overwhelmed by new contributors.  I'd love to be
proven wrong.

> I'm afraid I don't have the time to actually hack on log4net.

See ;-)

> But I could help with what I'm good at: lever some of the major data
> migration work to smooth the way for others that need a repository.

Many thanks for that.

Stefan

Re: Discussing the existing patches

[Stefan Bodewig]

On 2011-08-13, Dominik Psenner wrote:

> Can we start a discussion on the existing patches?

Absolutely.  I'm running out of time right now, but will focus on the
three issues you've mentioned soon.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-13, Roy Chastain wrote:

>>> Who are those people? Maybe they should comment on this?

> I am one of those people.  At this point I have minimal (if any)
> understanding of the actual patch insertion process, but given I don't
> have write privileges that is okay.  I also have minimal/no
> understanding of how to apply patches that are not "committed" to
> something I am building.  (I know I need to read the manual.)  I have
> no allegiance to SVN other than I know I will face it again in the
> future.

I'll leave the distributed VCS part to Dominik as I think he's more
experienced in that area than myself (I'm a long time darcs user with
some git sprinkled in but have never used hg or Bitbucket myself).

Let me try to address the current process.  My I assume you are familiar
with TFS?

svn is pretty similar to TFS with the major exception being that by
default the svn server doesn't track who has checked out what - all your
checkouts are local only.  This also means "shared checkout" is the
default, it is possible to lock files but this is frowned upon.  In the
eleven+ years I've been working on ASF code bases I've had less than 20
merge conflicts that I needed to resolve - in reality it is very rare
that two developers touch the same code at the same time.  Commit early
and commit often.

I am a command line guy so I apply a patch by using the GNU patch
command from my Cygwin installation.  Unfortunately I'm not familiar
with any alternatives to that.

The process is "download the patch from JIRA", "apply it to your working
copy", "build and test" and finally "commit".

> I thought it was a duplication of effort, but Stefan seems to think it
> may have merit, so what is the merit?

[once I was ready I realized I did talk about the DVCS part as well,
sorry.  Dominik, please point out where I'm wrong or fill in what I've
forgotten to say.]

Basically using a site like Bitbucket allows others to have a public
workspace they have write access to.  This gives those others the
advantage of revision control while they develop a feature/fix and gives
log4net devs the ability to say "no, don't do it that way, take a
different route" and play back and forth until all sides are satisfied.

Basing such a workspace on a read-only clone of the "master" svn tree
means that this public workspace can be kept in sync with log4net's
current code.  The distributes VCSes are all pretty good at merging and
tracking what they have already merged.

Bitbucket, github, launchpad and similar sites make it easy to ship
patches from one workspace to another if they are related.  Say Dominik
had prepared some code change in a workspace and he's ready then he can
ask the maintainer of a Bitbucket copy of log4net's svn tree to pull in
a certain set of changes - and the infrstructure will perform all
necessary merge steps if the request is accepted.  A bridge from hg to
svn exists that would make it easy to then send the same changes to the
svn tree.

So what Dominik suggests is to enable a different workflow that is
proven and works well for people who are used to these tools.  This
alternative is more agile and more interactive - several people could be
working together on a changeset that is going fix a given bug or
implement a given feature - than the "central source tree", "patches in
issue tracker", "committer as gateway" process we usually employ.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-13, Stefan Bodewig wrote:

> svn is pretty similar to TFS

The version control part of TFS that is.

There are differences but both have similar (limited) support for merge
tracking, perform branching in the file-system space (i.e. copy a trunk
dir to a branches/X_Y_Z dir) and both are typical instances of a
centralized version control system and share quite a few concepts.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-13, Roy Chastain wrote:

> My immediate takeaway is that by using a distributed VCS we have the
> capabilities that I am more used to in that we are working "connected"
> instead of "disconnected" with the connection blocker being someone who
> can commit in SVN on ASF.

Yes, BUT.

But once the people who would be working "in connected mode" in a
distributed VCS have been doing it for long enough that the existing
committers have gained enough trust the whole thing won't be necessary
any longer.  The people who stick around long enough will get write
access to svn sooner or later.

The normal state of an ASF project is that all people who contribute
code on a regular basis have write access - if they want it.

> Is how do we track what we are doing so that the correct info gets into
> JIRA or is that the committers job to fix JIRA as he/she commit our
> code?

The normal process is that a committer resolves the JIRA issue once the
code is in svn.  Sometimes the user who opened the issue will close it
after the fix has been verified but this is truely optional.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-14, Dominik Psenner wrote:

> sorry for the late response. This sunny sunday took me for a trip into
> the mountains. :-) See the inlines below.

I live further up north in Germany (guessing from your name) so it
hasn't been as sunny around here 8-(

>> The normal state of an ASF project is that all people who contribute
>> code on a regular basis have write access - if they want it.

> I would not advise to commit to the ASF SVN repository directly. Changes
> put into SVN are carved into stone and immutable FOREVER. Mercurial
> allows a more flexible way for working on things. Just read this mail to
> the end to get there. :-)

I did, and I'm sorry that won't happen as it simply is not the way ASF
projects operate.  Immutable history actually is an asset.

One thing I've noticed when following github projects and similar
constructs has been that they have a hard time building a real
community.  Too much focus is put on code and branches and not much on
agreeing how to move forward and actually collaborating.  It is too easy
to simply create your own branch, go off and say "I know better" rather
than search for a compromise.  Yes, I am oversimplifying and
generalizing here.

The ASF model forces all people working on the project to build
consensus on what goes into the project.  This helps to have a real
community behind the code base - *the* code base as there is only one.
And a community rather than a few single devs who know better is what
makes a project sustainable and allows it to survive if the original
devs go away.

I really do appreciate what you've set up and I do understand the model
you describe has advantages and disadvantages over how the ASF works
traditionally, but it is at odds with the ideals of the ASFs in some
areas.

> You may ask yourself how we can discuss on a changeset if the others
> don't know about it? Mercurial offers some very convenient ways to share
> information between developers. One is to publish the information in a
> repository so that others can pull that information into their local
> clone (that's how mercurial works after all) or the other way would be
> to mail a patch to this list so that others can import it and comment on it.

See, we prefer to discuss on the mailing list - not in JIRA and not in
code via patches.  Discussions in plain English (or what people like me
consider English ;-) are easier to follow when you want to revisit them
five years later.  Yes, this happens.  The "why did we decide to use X
instead of Y" questions do come up.

>> The normal process is that a committer resolves the JIRA issue once the
>> code is in svn.  Sometimes the user who opened the issue will close it
>> after the fix has been verified but this is truely optional.

> Yes. Right now we can only comment on issues, which is obviously not
> enough to be productive. We should contact some people @ JIRA so that at
> least one of us gets write privileges to the repository and
> administrative privileges to the bugtracker ASAP.

This is on the way.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-15, Curt Arnold wrote:

> Code development at the ASF should be done in the open and not in a
> private branch that unveiled to the community (has happened in the
> past) as that basically prevents anyone else from influencing the work
> while in process.

To be fair, this is not what Dominik suggested.  The mercurial branches
would be in the open just as the svn tree is and it would be even more
inclusive in a way as everybody could create a branch of his/her own
with write access immediately.

> Code should go into the SVN as it is developed so there can be
> feedback, etc. Which someones means there will be code that was bad,
> buggy, undesirable, etc, but that always can be undone.

I think it is important for us all, that we do have a single place with
the code to discuss - and once we have enough people with write access
it won't be necessary to think about any other place than svn for this.

The "hg or git clone of svn" model works very well for the odd case of
people who want to contribute larger patches but don't have write access
themselves - which should be the exception.

Stefan

Re: Open issues for 1.2.10 release

[Stefan Bodewig]

On 2011-08-13, Dominik Psenner wrote:

> There are 9 open issues targeted for 1.2.10. They should probably be
> rescheduled to be included in 1.2.11?

I've just been granted enough JIRA karma to at least re-assign those
issues to 1.2.11 (but can't create new versions, yet).

Without even reading the issues I've bulk-scheduled them to 1.2.11 for
now.

Stefan


pgpeCks3vf4LS.pgp
Description: PGP signature

Client Profiles (was Re: Open issues for 1.2.10 release)

[Stefan Bodewig]

On 2011-08-15, Dominik Psenner wrote:

> The other big story is the support for the .NET client profiles. As I
> understood it, we have to drop everything in log4net that is not
> supported in a .NET 4.0 client profile (i.e. references to System.Web).
> To achieve this we have at least two options:

> 1] refactor everything that doesn't fit with the client profile into a
> separate project / dll
> 2] maintain a .net 4.0 client profile branch with a subset of the
> log4net functionality

> * Solution [1] is a pain for everyone that uses log4net since they need
> to reference two libraries instead of one
> * Solution [2] is a pain to maintain with subversion

Not really, solution 2 doesn't require a branch IMHO.

Right now the NAnt build builds several different assemblies targeting
different platforms all out of the same source tree and it should be
straight forward to extend that to the client profile as well.

Tasos' patch basically works the same way as log4net supports the
compact framework now - it adds a conditional compilation symbol and
simply excludes all System.Web stuff if that is set.

We could extend the NAnt build to create even more assemblies (4.0 had
to be added and 3.5 client profile as well as 4.0 client profile), set
the CLIENT_PROFILE symbol and be done.  This should even be possible for
1.2.11 - at the expense of even more assemblies.

The main hurdle may be NAnt's limited support for .NET 4.0 (need to use
a nightly build for now) and I don't think there is a target defintion
for client profiles at all - but that should be doable.  I'm willing to
invest some effort here.

Longer term switching to MSBuild or the solution task in NAnt and using
Visual Studio 2010 solution files targeting the correct platform may
work should we plan to drop support form 1.x, Compact Framework and
explicit support for Mono.

What I wonder is: do we really need 3.5 and 4.0 assemblies at all?
Wouldn't a 2.0 assembly including System.Web and a 3.5 client profile
assembly without it work for .NET 3.5/4.0 projects and and their client
profile subsets well enough?  For 1.2.11 that is, later we may want to
use LINQ or WCF or whatever.

Stefan

Moving Forward

[Stefan Bodewig]

Hi all,

it seems that so far we agree that the very next steps should be

* release 1.2.11 ASAP.

  This should be current trunk plus all known good patches from JIRA that
  won't make it impossible to build for 1.0 or compact framework.

  I think it may be possible to provide client profile versions of this
  as well.

* poll users which target platforms are actually needed.

Am I correct with this?

If so I think the major pieces of work for 1.2.11 release will be

(1) setting up a build environment on anybody's machine that is suitable
for a release build.

(2) wade through all 160+ open tickets, look for "good patches" and
assign them to 1.2.11.

Anything that is not too urgent or doesn't contain a test should be
pushed to a later release IMHO.  Curt, can you create some more
versions I JIRA (I don't have karma for this), I'd propose
1.2.MAINTENANCE to collect just what looks like a reasonable future
patch but shouldn't go into 1.2.11 immediately.

I volunteer to work on (1) but likely won't have any tangible results
before in about three to four weeks.  (2) could be done by all of us -
at least those with the required permissions.

Stefan

Re: Client Profiles

[Stefan Bodewig]

On 2011-08-15, Dominik Psenner wrote:

> On 08/15/2011 08:29 AM, Stefan Bodewig wrote:
>> Right now the NAnt build builds several different assemblies targeting
>> different platforms all out of the same source tree and it should be
>> straight forward to extend that to the client profile as well.

>> Tasos' patch basically works the same way as log4net supports the
>> compact framework now - it adds a conditional compilation symbol and
>> simply excludes all System.Web stuff if that is set.

> I get the idea. Until now I didn't understand how log4net was built at
> all. If it works, it's fine by me. :-)

>> The main hurdle may be NAnt's limited support for .NET 4.0 (need to use
>> a nightly build for now) and I don't think there is a target defintion
>> for client profiles at all - but that should be doable.  I'm willing to
>> invest some effort here.

> What I've read so far, NAnt 0.91 alpha 2 supports .NET 4.0. At least
> that's what they're writing in that table on their frontpage
> (http://nant.sourceforge.net/).

That's what they say, yes. 8-)

> Does that help us?

Like I said later, I'm not convinced we need to target 4.0 at all as the
2.0 version should just work.  For client profile we could use a
stripped down 2.0 version or explicitly target 3.5 (client profile).
But I may very well be missing some nuance.

>> Longer term switching to MSBuild or the solution task in NAnt and using
>> Visual Studio 2010 solution files targeting the correct platform may
>> work should we plan to drop support form 1.x, Compact Framework and
>> explicit support for Mono.

> I would favorise that, but I don't know if that's possible with ASFs
> continuous integration.

We don't have any (working) CI for log4net right now.  The only one I'm
aware of is Gump and this one only builds the Mono parts so isn't really
useful.  It doesn't perform any tests either.

Jenkins - one option available from ci.apache.org - does support MSBuild
(on Windows, of course) and likely NAnt as well.  I know the Lucene.NET
project is looking for CI builds so the infrstructure for "real" .NET
builds should be there at one point.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-15, Dominik Psenner wrote:

> On 08/15/2011 07:26 AM, Stefan Bodewig wrote:
>> I think it is important for us all, that we do have a single place with
>> the code to discuss - and once we have enough people with write access
>> it won't be necessary to think about any other place than svn for this.

>> The "hg or git clone of svn" model works very well for the odd case of
>> people who want to contribute larger patches but don't have write access
>> themselves - which should be the exception.

> And it makes sense in cases where people work together on a bugfix
> without the need of spamming the svn log with stuff that doesn't work.

That's what I meant when I said the approach allows contributors to have
the advantage of revision control while developing the patch.

Most of our patches aren't really that big, though.  There won't be much
back-and-forth.  svn logs of failed attempts do provide some value as
well, BTW.

If there is anything bigger to develop, a svn branch can work as well -
contrary to popular belief, svn does support branching and merge
tracking and it isn't all bad.  Note, the ASF has used and survived CVS
before. ;-)

> Right now the most useful log4net that people use is the svn trunk. We
> shouldn't break it!

If we get back on track with regular releases the occasional trunk
breakage will be OK as people won't be forced to use arbitrary trunk
revisions.

> Indeed the history how a single patch evolves is not at ASF, but since
> patches should be sent to the mailing list

Nope. JIRA.

> and discussed there (mbox extension) it is not that far from ASF at
> all.

> Please correct me if I'm wrong.

No, you are not wrong per se.  But for simple cases it is more complex
than what I'd do otherwise.

Looking through your explanations how to review certain patches I
thought the old fashioned way would be way easier for anybody with svn
write access.

My typical workflow for any other ASF project is

* read the bug report and the attached patch

* if it looks reasonable, apply the patch to my local working copy of
  svn trunk (that's patch -p0 < patchfile).

* rebuild the tests, run them and watch them fail

* rebuild main code base, rebuild the test, run all tests and watch them
  pass

* commit

Of course this is an oversimolification and I may very well stop at
"read the patch".  And TBH many times I drop the patch, apply only the
tests and write a different fix myself - and even more often there is no
test and no patch at all.  In the case of no patch and no tests it
doesn't matter that the only repo I have is svn.

Stefan

Re: Client Profiles

[Stefan Bodewig]

On 2011-08-15, Dominik Psenner wrote:

> On 08/15/2011 11:26 AM, Stefan Bodewig wrote:
>> Like I said later, I'm not convinced we need to target 4.0 at all as the
>> 2.0 version should just work.  For client profile we could use a
>> stripped down 2.0 version or explicitly target 3.5 (client profile).
>> But I may very well be missing some nuance.

> You once asked if VS2010 can change the target profile.

I know that my Premium Edition can, I was asking about the no-cost
editions (Express or whatver they are called for 2010 this time).

>> We don't have any (working) CI for log4net right now.  The only one I'm
>> aware of is Gump and this one only builds the Mono parts so isn't really
>> useful.  It doesn't perform any tests either.

> Now that you say it. I just ran nant from my ubuntu laptop and was
> impressed that it went through without complains. :-) I just built
> log4net for mono 1.0 and 2.0. *laughing* I'm going to copy that dll to
> my windows pc and see if I can use it across different projects (2.0,
> 3.0, 3.5, 4.0, 3.5CP, 4.0CP) and report the results.

Works reasonably well in my experience, I know I've done so in the past.
the same is true for the other direction, that's why I doubt we need
specific Mono assemblies.

>> Jenkins - one option available from ci.apache.org - does support MSBuild
>> (on Windows, of course) and likely NAnt as well.  I know the Lucene.NET
>> project is looking for CI builds so the infrstructure for "real" .NET
>> builds should be there at one point.

> Where did you read up jenkins?

Ah, the ci.apache.org site still says Hudson and hasn't followed the
hostname changes we did when we switched from Hudon to Jenkins.  /me
takes note to bug infra.

<https://builds.apache.org/> is our Jenkins farm which also contains a
Windows 2008 Server instance.  The Chemistry build likely already uses
MSBuild (yes, looks like the 3.5 version).

> Btw, why does the nant build only produce mono files?

No, it doesn't do that at all.  I've built .NET 2.0 and 3.5 DLLs using
NAnt 0.90 with my installation on Win7 just fine.

The one running in Gump can't produce any other as Gump is running on
Linux (and some other OSes with no kind of .NET support installed at
all).

Stefan

Re: Client Profiles

[Stefan Bodewig]

On 2011-08-15, Roy Chastain wrote:

> A couple of issues
> 1) - There is no client profile for 2.0.  3.5 is the first version with
> a client profile.
> 2) - There is more to building against client profiles than removing
> namespaces.

I understand both of those points.

Let's assume we target 2.0 and nothing else and create the current
assembly.  This should work for 3.5 and 4.0 just fine, doesnt it?  I've
been using such a setup in production for months if not years (the 3.5
case) now and never saw any problems.  We are not using any of the more
fancy appenders, though.

And then we add conditional compilation on a CLIENT_PROFILE that removes
all System.Web referenes and target 2.0 again but this time with the
symbol set.  Shouldn't the resulting assembly work for the 3.5 and 4.0
client profiles?

> The references must be changed to remove the Framework Dlls that are
> not part of the client profile.  Again, I don't know the tool, NAnt.
> Can it do that?

I think csc is smart enough to drop references that aren't actually
used.  In theory NAnt can ensure we don't reference anything that
shouldn't be there but this is where it needs configuartion for the
target and I don't think there currently exist configurations for the
client profiles.

> 3) - (This probably should be in the 4.0 discussion, but it is related
> here too.)  When you retarget a project to 4.0 (or back to 3.5) VS
> changes the references.  Some of the namespaces and classes have been
> placed in different assemblies etc.  It COULD be more difficult than
> just retargeting and, I think, this issue may further push to releasing
> a 4.0 targeted assembly.  Again, the issue is adding/removing
> references.  Even if none of the referenced assemblies change names, the
> different versions of them must be targeted during the builds.

OK.  But this really only comes up once we try to build for the 3.5 and
4.0 targets explicitly.  As long as we don't use anything that's not
part of 2.0 then we don't have to do that, do we?

Stefan

Re: Client Profiles

[Stefan Bodewig]

On 2011-08-15, Roy Chastain wrote:

>>> What I wonder is: do we really need 3.5 and 4.0 assemblies at all?
> Two comments

> 1) - There seems to be a lot of confusion among developers about the
> Frameworks.  By reading the questions that have been asked on the list,
> I believe that many of them do not realize that a 4.0 framework app can
> call 3.5 framework code.  It is not necessarily our job to educate them,
> but there has been a lot of traffic about 4.0 and even numerous "bug
> reports" about failures.  I do not believe I ever saw a real description
> of the failure, but it seems that several of them dealt with ADO
> appenders, so there could actually be a problem with them.

In this case we should investigate this.  It should stick out when
triaging JIRAs.

> 2) - We certainly need code that will compile against the 4.0 Framework.

Against 2.0, no?

> I currently have a product that requires 4.0 and 3.5 and the amount of
> time to install it on an out of date XP system is absurd.  We all think
> XP should be gone, but the reality is that it is not.  Same for sever
> 2003.

I'm sure I know what you are talking about.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-15, Dominik Psenner wrote:

> On 08/15/2011 11:39 AM, Stefan Bodewig wrote:
>> If we get back on track with regular releases the occasional trunk
>> breakage will be OK as people won't be forced to use arbitrary trunk
>> revisions.

> No, it is not OK at all. IMHO every recorded history should be a
> monolithic working library. Only if you do that you make sure that every
> release is just fine because if you don't, people will make errors and
> people will forget some thing or the other.

Here we'll have to agree that we disagree.  I will make errors, trunk
will occasionally be broken.  We have a mailing list that receives
notifications of all changes that went into svn and my fellow committers
review my changes.  We have a CI system (well, not really in the case of
log4net, this will be fixed sooner or later) that will call me off it I
break things in a way it can detect.  We do all we can to ensure trunk
works as well as possible but it is bleeding edge code.

Not that we'd guarentee our releases work any better.

The real solution is to have more releases to get bugfixes out quicker.

> "Ok, I'm done with it, for now I commit it and tomorrow I'll fix the
> special case".

This is rare, and if it happens I leave a comment in source code and
likely even a failing but skipped unit test.  YMMV.

> If patches don't get revised, it results exactly in the situation we
> have in log4net right now:

I never said patches wouldn't be revised, at least I hope I never said
so.  They must just get revised after I have committed them  The "commit
then review" model is working well among many projects.

Only very few ASF project follow the alternative "review then commit"
model - Tomcat and httpd do so for their "stable" branches.  For this we
do have tools like reviewboad at the ASF but I've never used it.

> 101 revisions since the last release and nobody knows whether those
> "fixes" do really fix the issues or those revisions are safe to include
> in the next release because there are no unit tests. I don't think
> that's funny.

No it isn't, fortunately it isn't all that bad as many changes comes
with unit tests or are directly connected to JIRA tickets and most
changes are pretty small - this is from my cursory look, you may have
looked closer than myeself.

If anything it points out that we may want to diff currennt trunk
against the latest released code just to be sure we actually know what
type of changes we are pushing out.

The reason that "nobody knows" is neither svn nor JIRA nor the way you
or I or anybody else who is willing to help the project now wants to
work, though.

Stefan

Re: Client Profiles

[Stefan Bodewig]

On 2011-08-15, Roy Chastain wrote:

> Let me start at some basics just to ensure that we are starting at the
> same point.
> There are 3 CLR versions, 1.x, 2.0, 4.0.  Framework 3.0 and 3.5 are
> simply add on assemblies that target the 2.0 runtime.  This fact is why
> the 3.5, 3.0 and 2.0 interop works so well.  That is also why the
> service pack for 3.5 updates the 3.0 and 2.0 assemblies.

> 4.0 targeted runtime can call into 2.0 CLR code.  The problem is that
> both the 4.0 and 2.0 CLR must be present on the system.

I knew so much, but thank you anyway - I'd likely have needed way more
words.

> This leads to a distribution package that may need to install both the
> 3.5 SP1 (the best way to get a 2.0 Framework installed) and the 4.0
> frameworks.

This is what I didn't know.  My development machine doesn't list any
framework other than 4.0 as installed but still I can use the log4net
assembly that targets 2.0.  Probably the installation of VS installed
the older frameworks.  Anyway, for some reason I was under the
impression the 4.0 framework install would contain the 2.0 CLR.

> The dual framework package is not much of issue for Windows 7 systems,
> because Win 7 and Server 2008 r2 come with a completely patched 3.5
> framework.

OK, my case - and the production envs are either old Win 2003 servers
that used to have 2.0 installed before adding 4.0 or Win 2008 server,
this explains why we have never seen any issues.

> We need/must have a 4.0 targeted assembly (someday soon - not today) so
> that applications that are built against 4.0 will only require 4.0 and
> not 3.5 and the rest of the 2.0 CLR.

This should actually be doable for 1.2.11 with the latest NAnt alpha,
I'll see to it.

> We must also have assemblies that target both the full and client
> frameworks of 4.0 and (I believe lessor priority) 3.5 (again a polling
> question).

Yes, I agree by now.

> The second set of traffic is that "log4Net does not log anything when I
> call it for code compiled for .NET Framework 4.0".  When asked, the
> response has usually been that they were attempting to use an ADO
> appender.  I know the rolling file, SMTP and console appenders all work
> correctly, but I have never tried an ADO appender on any version.

Same here.

> I have just uncovered and am in the process of having Microsoft look
> at an issue in the 4.0 to 3.5 interop.  In my application that uses
> both, the 4.0 code runs just fine, but when it is attempts to call the
> 3.5 code it gets an untrapped but ignored exception.  This happens on
> a clean install of 3.5 SP1 and 4.0 on a clean XP system.  The
> interesting thing is that a system restart resolves the issue and the
> application then runs.

Ouch.

>>> And then we add conditional compilation on a CLIENT_PROFILE that
>>> removes all System.Web references and target 2.0 again but this time
>>> with the symbol set.  Shouldn't the resulting assembly work for the
>>> 3.5 and 4.0 client profiles?

> Assuming that the reference to the missing assembly is dropped as you
> suggested, I will agree to the 3.5 client profile.  (I am not saying
> that it is not dropped, I just do not have knowledge of that one way
> or the other.)  An application targeting the 4.0 client profile will
> still require the install of the 3.5 client profile if we do not
> target 4.0 during the build of the assemblies.

Let me try some things with NAnt, I'm pretty confident we'll be able to
create assemblies targeting both client profiles in time for the 1.2.11
release as well.

Stefan

Re: Questions for our poll

[Stefan Bodewig]

On 2011-08-16, Roy Chastain wrote:

> A starting point for the questions to be presented.  Please modify and
> add as you see fit.  These are in no particular order.

Looks good to me.

> 6) - Do you need an assembly targeting any version of Silverlight?  (if
> enough say yes, we come back and ask about what versions)

Just taking the opportunity to point out that NAnt claims to also
support Silverlight 2.0 as a target (as well as Mono 3.5 and Moonlight
2.0 if anybody should still be interested in assemblies targeted to
Mono) so producing those assemblies should be possible just by modifying
the NAnt build file.

Stefan

commits list

[Stefan Bodewig]

Hi all,

I've just received commit access to log4net and already applied my own
patches which don't address anyting major:

* ensured line-ends are correct (this will create a huge diff for those
  with a checkout on platforms where the native line-end is not CRLF)

  I still may have missed some files.

* ensured all files have the proper Apache license header - without that
  we wouln't be able to do a release.  Again, pretty big diff.

* ensured the tests compile on .NET 2.0 as this is what NAnt uses on my
  machine by default.

I plan to bring forward a release proposal and lay out which patches I
intend to apply in a separate mail later, maybe not even today.

All those commits - as well as future commits - generate diff emails
going to log4net-...@logging.apache.org that you can subscribe to by
sending an email to log4net-cvs-subscr...@logging.apache.org if you
interested in following the changes.  I don't think this page is
advertized on the log4net site.

Unfortunately the list doesn't appear to have a public visible archive,
I'll open a ticket to change that.

Stefan

Re: Patch for LOG4NET-38 EventLogAppender: Add support for setting the Category on Event Log messages.

[Stefan Bodewig]

On 2011-08-17, Isaac Devine wrote:

> Sorry I don't what your process is here, so I thought I would post to
> the dev-list to please review my patch for issue 38 (url below):

No real process right now, let's do what works. 8-)

> https://issues.apache.org/jira/browse/LOG4NET-38

As this is in the set of issues assigned to 1.2.11 it is on my list I
plan to review over the next few days anyway.  Nag us if you don't hear
anything.

Stefan

Re: .NET 4 branch

[Stefan Bodewig]

Hi Tasos,

On 2011-08-10, Tasos Vogiatzoglou wrote:

> Could anyone with write access make a .NET 4 (or 1.2.11 ?)  branch in
> the repos ? I have submitted some patches that would be helpfull to
> have them included and I am working on the same line on the test
> project.

What exactly would you need?  I could certainly copy current svn trunk
to a branch but don't expect to merge any of the patches that need to go
into the 1.2.11 release over there.  Does that help you?

Would it make sense to wait until 1.2.11 is released?

If you are familiar with hg or git it may be easier to work from
http://git.apache.org/log4net.git/ or the hg mirror Dominik has setup so
nobody had to manually maintain the svn branch.

Stefan

Re: .NET 4 branch

[Stefan Bodewig]

On 2011-08-17, Tasos Vogiatzoglou wrote:

> If there is a schedule for 1.2.11 I don't mind a branch after that. If
> there is not a schedule for 1.2.11 or there are resource constraints I
> could certainly help time to drive a good release.

It depends on how much help we can get, but I'm confident we can release
1.2.11 in about a month.  I might be too optimistic, though.

> As have been noted in other messages, there is an issue with the
> strong naming of log4net assembly. That prevents lots of people from
> creating their own assembly as there are dependencies that have to be
> recompiled. In my situation e.g. I have windsor IOC (among other
> things) that would take a great effort to build.

So far consenus seemed to be that we'll release two sets of assemblies,
one signed with the same key as 1.2.10 and one signed with a new key
that is not kept private and will be used for all future releases.

We may even release a third set of assemblies that isn't strong named at
all.

> So if what is needed to have stuff merged is resources, I am willing
> to do what is required.

I'm sure we can use any help we can get.  Short term there'll be a
bottle-neck in that only few people actually have write access to svn -
and things will be worse the coming two weeks due to time constraints on
my side (now that I have write access) - but one thing that everybody
can do is review patches.

I'll post some ideas on how I think we could release 1.2.11 soonish
later today.

Stefan

Re: .NET 4 branch

[Stefan Bodewig]

On 2011-08-17, Tasos Vogiatzoglou wrote:

> Does ASF have a build server or something that can build, run tests
> and produce binaries ?

It has, but there is nothing set up for log4net right now.

The most sane choice would be the Jenkins[1] installation as there already
are other .NET projects using it - and we may benefit from the
Lucene.NET folks doing the same.

If anybody is familiar with configuring builds for Jenkins (or Hudson,
shouldn't matter here) for .NET builds and could lend a hand, that
wouldn't hurt.  This is completely new to me (we are a CC.NET shop at
work).

Stefan

New versions in JIRA

[Stefan Bodewig]

Hi,

I've created new versions in JIRA eligible for "target version" that I'd
like to use to classify issues.  They are not meant to be real software
versions; if and when we do releases after 1.2.11 we'd pick issues from
there and re-assign them.

* 1.2 maintentance

  for everything that could be fixed/added in a backwards compatible way
  to 1.2.x after 1.2.11

  We may be willing to accept minor incompatibilies here, it depends.

* 2.0

  everything that requires .NET 2.0

* 3.5

  everything that requires .NET 3.5

* 4.0

  everything that requires .NET 4.0

Those later three may never come to existence or if a poll tells us we
don't need a 3.5 version then we'd move all issues from there to 4.0
later.

We need to triage the bugs and in the end I'd love to have each issue
examined and assigned to one of these versions (or 1.2.11) so we know
which issues haven't been looked at so far.

Does that make sense?

Stefan

Planning 1.2.11

[Stefan Bodewig]

Hi all,

this is how I think we could get to a 1.2.11 release in the timeframe of
about a month:

(1) look at all issues currently reported and assign them to
1.2.11 if

(a) they describe a reproducible bug that we know how to
fix

(b) they wish for a feature that looks desirable to more than just
the reporter, have a patch appended with the "licensed to the
ASF" checkbox checked, come with a unit test

(2) assign all other issues to one of the versions "1.2 maintenance",
2.0, 3.5 or 4.0 - or close them if they are user questions or
otherwise not appropriate at all.

(3) provide fixes for all (1)(a) items and attach them as patch checking
the "licensed to the ASF" checkbox

(4) apply all patches with target 1.2.11

(5) create a build environment that can produce all buiod artifacts
we've had for 1.2.10 plus assemblies targeting .NET 3.5 (already
done in trunk), .NET 4.0 and Mono 3.5.

(a) try to build client profile assemblies for 3.5 and 4.0 as well
but don't allow this to delay 1.2.11

(6) Release

Those things don't have to happen in that sequence, for example I
volunteer to set up a build environment for log4net locally - unless Ron
has time to do it, that is.

Everybody can help with steps (1) to (3), we'd just need to coordinate
so we don't duplicate effort.

As already mentioned in a separate mail, I likely won't find much time
to contribute (if any) the next two calendar weeks.  The major piece of
work will be the triage and fixing bugs anyway, nobody really needs to
wait for me or anybody else with commit access for that.

Does that sound reasonable?

If so, I'd also make some noise about it (for example on the user list)
so we may even get more active patch reviewers.

Please don't hesitate to tell me I'm wrong - that would neither be the
first nor the last time.

Stefan

Re: Planning 1.2.11

[Stefan Bodewig]

On 2011-08-17, Roy Chastain wrote:

> I like it all with the possible exception of attempting to produce 4.0
> targeted assembly in the short term 1.2.11.  I THINK that will delay the
> process.  If it does not, then fine - no problem.

I hope it is mainly a matter of upgrading NAnt and mimicing what already
happens for 3.5.

> I see NO benefit of creating an assembly that targets 3.5 since that is
> still the 2.0 CLR UNLESS we put in code that is only available in 3.5
> and I do not believe we are ready do that in the 1.2.11 time frame.

The build file in trunk already produces them, so we can as well
distribute them.

> We certainly may want to create a WCF appender somewhere down the
> line, but not now.  (Slap me for even thinking of such an appender.)

Feel slapped. 8-)

Yes, we will want to create one.

> Just to confirm, the current plan for doing the triage, for those of us
> without other privileges" is that we will "comment" on the issue that
> they are looking at it.  Of course people with permissions would assign
> it to themselves.

There is a "contributors" group in JIRA which may allow you to do more.

If the people who want to help out can create JIRA acounts and tell me
their login id I can add you to this group and we'll see which
permissions this will grant you.

Stefan

Re: Planning 1.2.11

[Stefan Bodewig]

On 2011-08-17, Tasos Vogiatzoglou wrote:

> My jira act is oglu

both you and Roy are now members of the contributors group.

Stefan

Re: Planning 1.2.11

[Stefan Bodewig]

On 2011-08-18, Dominik Psenner wrote:

>> this is how I think we could get to a 1.2.11 release in the timeframe of
>> about a month

> Looks fine, no objections.

Good.

I've managed to get NAnt 0.91apha2 working after some hassles, I hope to
be able to build assemblies targeting 4.0 by tommorow.

>> If the people who want to help out can create JIRA acounts and tell me
>> their login id I can add you to this group and we'll see which
>> permissions this will grant you.

> Here's my id anyway: nachbarslumpi

You should be in the contributors group now.

Stefan

NAnt 0.91alpha 2 (was Re: Planning 1.2.11)

[Stefan Bodewig]

On 2011-08-18, Dominik Psenner wrote:

>> I've managed to get NAnt 0.91apha2 working after some hassles, I hope to
>> be able to build assemblies targeting 4.0 by tommorow.

> That's great news! I ran out of luck the last time I tried it, but I'm quite
> unused to NAnt anyway. So that could have been the reason. ;-)

Not that I'd be an expert either.

The biggest hurdle was .NET's inability to provide useful error
messages.

When I downloaded the ZIP and extracted it, the ZIP was marked as
"downloaded from the internet" and "blocked for security reasons" and
all DLLs contained within inherited that flag.

When I first tried to run NAnt I got some CAS exception for file I/O - I
thought I had fixed that by removing the 

  

from NAnt.exe.config, which was complete nonsense but allowed me to get
a step further.  That step was NAnt starting up and then failing to load
any task DLLs because of 

,
| Could not load file or assembly 'file:///dll' or one of its
| dependencies. Operation is not supported. (Exception from HRESULT:
| 0x80131515)'
`

I should have searched the web for that HRESULT code by that time but
for some reason didn't and spent quite some time trying to play with
local permissions - and even managed to "unblock" all DLLs, but that
didn't help.  I must have missed some files.

Then I went back to my ZIP, unblocked that, extracted it again and used
the newly extracted version and finally things worked.

Stefan

Some trunk builds to play with

[Stefan Bodewig]

Hi all,

 contains DLLs I've built
from trunk targeting .NET 2.0, 3.5 and 4.0 respectively.  Neither of
them signed.  The ZIP contains all DLLs/XMLs/PDBs.

It would be nice if anybody apart from myself could confirm they look
OK.

Tasos, it would be good if you could verify they don't show the "name
resolution bug" you raised as part of LOG4NET-296.

Please don't consider them anything but a developer snapshot build and
don't communicate their existence outside of this list.

Stefan

ADO.NET Appender and FX 4.0

[Stefan Bodewig]

Hi,

Roy said in some thread people had reported problems with the ADO.NET
appender when running on .NET 4.0.

I managed to get to the point where NAnt at least tries to run the unit
tests on 4.0 and this is what I see:

Unhandled Exception: System.TypeLoadException: Inheritance security rules 
violated while overriding member: 
'log4net.Core.LoggingEvent.GetObjectData(System.Runtime.Serialization.SerializationInfo,
 System.Runtime.Serialization.StreamingContext)'. Security accessibility of the 
overriding method must match the security accessibility of the method being 
overriden.
   at log4net.Appender.BufferingAppenderSkeleton.Flush(Boolean flushLossyBuffer)

   at log4net.Appender.BufferingAppenderSkeleton.OnClose() in 
c:\OSS\log4net\src\Appender\BufferingAppenderSkeleton.cs:line 411
   at log4net.Appender.AdoNetAppender.OnClose() in 
c:\OSS\log4net\src\Appender\AdoNetAppender.cs:line 433
   at log4net.Appender.AppenderSkeleton.Close() in 
c:\OSS\log4net\src\Appender\AppenderSkeleton.cs:line 243
   at log4net.Appender.AppenderSkeleton.Finalize() in 
c:\OSS\log4net\src\Appender\AppenderSkeleton.cs:line 83

which may or may not be related.

I do not see this when I tell NAnt to use the .NET FX 2.0
(via Nant -t:net-2.0) - I "only" get the ten unit test failures I
already raised in JIRA.

Stefan

Re: ADO.NET Appender and FX 4.0

[Stefan Bodewig]

On 2011-08-19, Roy Chastain wrote:

> While, this is certainly a problem, it SHOULD not be the issue already
> reported, because those reports were against log4Net running on the 2.0
> CLR instead of the 4.0 CLR.

OK.


> I have done some research this morning, and have found a couple of
> articles suggesting "fixes", but I do not yet understand the
> ramifications.  This is all to do with a new code security model created
> in 4.0 and it is going to take time to understand.

I should add that NAnt.exe.config contains

  

and seems to need it.  This may complicate things even further.

Stefan

Re: ADO.NET Appender and FX 4.0

[Stefan Bodewig]

On 2011-08-19, Roy Chastain wrote:

> I have done some research this morning, and have found a couple of
> articles suggesting "fixes", but I do not yet understand the
> ramifications.  This is all to do with a new code security model created
> in 4.0 and it is going to take time to understand.

> If anyone reading this is a 4.0 code security model guru, then please
> look at
> http://connect.microsoft.com/VisualStudio/feedback/details/464751/inheri
> tance-security-rules-violated-while-overriding-member and throw out an
> opinion.

> The other solution seems to involve marking the calling code, but I have
> not figured it all out as yet.

The first two patches attached to LOG4NET-233 contain .NET 4.0 specific
attributes (and even remove some of the 2.0 code base when compiling
under .NET 4.0).  I'm no security model guru at all and will have some
reading up to do, but this may provide a starting point.

Stefan

Re: Client Profiles and Express Editions of Visual Studio

[Stefan Bodewig]

On 2011-08-19, Roy Chastain wrote:

> I just found this statement
> "In Express Editions of Visual Studio, a .NET Framework version or
> profile cannot be specified when a project is created. However, you can
> later retarget the project to any installed .NET Framework version."
> At http://msdn.microsoft.com/en-us/library/bb398202.aspx

> So yes, the Express Editions have full targeting capabilities.

OK, thank you.

Stefan

State of Client Profile and .NET 4.0 Support

[Stefan Bodewig]

Hi all,

I've hacked in client profile support - the NAnt build files are
becoming a bigger mess of copy-paste with each change, but this is a
different story.

I've taken Tasos' approach and defined a CLIENT_PROFILE compilation
symbol and conditionally excluded the ASP.NET stuff if it is present and
in addition NAnt won't reference System.Web.

I haven't performed any extensive testing but at least I was able to
build a minimal client profile command line app and write a log message
to a file using the 3.5 Client Profile assembly created (which in
reality is a 2.0 Client Profile assembly).

For 4.0 this doesn't work, but it is not due to Client Profile but to
the security related exception I already raised in a different thread.
As soon as I try to load any type from any of the two assemblies
targeting 4.0 a TypeLoadException is raised because of

Inheritance security rules violated while overriding member:
'log4net.Util.ReadOnlyPropertiesDictionary.GetObjectData(System.Runtime.Serialization.SerializationInfo,
System.Runtime.Serialization.StreamingContext)'.
Security accessibility of the overriding method must match the security
accessibility of the method being overriden.
log4net.Util.ReadOnlyPropertiesDictionary.GetObjectData(System.Runtime.Serialization.SerializationInfo,
System.Runtime.Serialization.StreamingContext)"}

So this isn't related to ADO.NET as I suspected in the other thread.

Of the three patches attached to LOG4NET-233 two contain security
related attributes in the 4.0 case - but they take different
approaches.  I'll have to read up on the differences of the security
models and the ramifications of either approach before deciding what to
do.  I can't promise this will happen this weekend (rather unlikely).

Any advice from people with more (should I say any?) knowledge is
welcome 8-)

Stefan

Re: ADO.NET Appender and FX 4.0

[Stefan Bodewig]

On 2011-08-20, Roy Chastain wrote:

>> I should add that NAnt.exe.config contains

>>  

>> and seems to need it.  This may complicate things even further.

> See this http://msdn.microsoft.com/en-us/library/dd409253.aspx

Yes, I knew that, I should have elaborated more.

> My gut says that this setting is a BAD thing.
> 1) - It is a RUNTIME not COMPILE time setting.  If code for legacy
> security being enabled, then anyone that uses log4Net will have to
> specify legacy security and that is just not going to work very well.

It is NAnt that seems to need it so it is inside the NAnt.exe.config.
And what I meant to say was that it is complicating things for running
the tests as it applies to the testcases - unless the NUnit task in NAnt
forks a new process, that is.

> 2) - It should only be set for code that explicitly defines a CAS
> policy.

NAnt apparently does.

> 3) - From reading more MS documents, this setting appears to be a
> "migration setting" and we should not plan on running that way
> indefinitely.

I'm not suggesting we should recommend any such setting for log4net at
all.

> I think we are already in too deep to make a 4.0 target for the 1.2.11
> release because we are going to have to
> 1) - Understand the new (non) CAS security model
> 2) - Make code changes to support it

+1

[for those new to the ASF, you're going to see this frequently as this
is how we vote and +/-1 has crept into non-vote discussions as well.  +1
simply means "I agree" in this case and I just typed it out of habit.]

> Now, that I have written all of this, I assume NAnt.exe.config is the
> config file for NAnt, not for what it builds.  If so, then this setting
> is simply telling the NAnt runtime to run with legacy security and that
> is not even meaningful unless NAnt is targeted to 4.0

Errm, should have read up to here before I started responding.  8-)

Yes.

Stefan

Compilation Symbols

[Stefan Bodewig]

Hi all,

before I started to modifiy things for 4.0 and client profile the NAnt
build was setting a compilation symbol for the "family" like "NET",
"NETCF", "MONO" and one for the specific version "NET_1_1", "NET_2_0"
and so on.  Also the conditional compilation sections seem to not assume
NET_2_0 was a superset of NET_1_1.

What I have done for now is piggy-back on NET_2_0 for both cases.

I have added CLIENT_PROFILE and NET_4_0 and define them in addition to
NET_2_0 and NET as this required the least changes to the code base.
This way I didn't need to hunt down all places that say NET_2_0 and add
a "|| NET_4_0".

But I start to feel that the correct way would have been to define NETCP
as a new "family", NETCP_3_5 ans NETCP_4_0 as new versions and to also
change all conditionals that rely on NET_2_0 so they apply to the (then)
two 4.0 and NETCP_3_5 as well.

So 

#if NET_2_0

would become

#if NET_2_0 || NET_4_0 || NETCP_3_5 || NETCP_4_0

This would create more complex conditionals but at the same time be
consistent with what has been done for the existing codebase.

What do you think?

Stefan

Re: State of Client Profile and .NET 4.0 Support

[Stefan Bodewig]

Hi Ron,

good to hear from you.

On 2011-08-25, Ron Grabowski wrote:

> Is your .NET 4 support just in the NAnt scripts?

Yes, exclusively.

> It's probably safe to replace the VS2008 solution file with a VS2010
> version.

I didn't go that far because my VS insisted on converting the project
files as well.  At least one of the several JIRA issues contains
attached solution files, one for 4.0 and one for 4.0 Client Profile.

Stefan

Re: Compilation Symbols

[Stefan Bodewig]

On 2011-08-21, Roy Chastain wrote:

> We must have "many" conditionals. As you noted 2.0 is not a superset of
> 1.1 and 4.0 is not a superset of 2.0. Because of CAS and other issues,
> 2.0 and 4.0 may be in direct opposition.

Agreed.

> 3.0 and 3.5 are indeed supersets of 2.0, but I doubt their importance as
> conditionals.  I would only see them as important IFF (if and only if)
> we do release a 3.5 targeted framework WITH a WCF appender.  I think the
> introduction of 3.5 as a tag should wait until later IFF we discover
> there is enough demand for a 3.5 target.

> I think that I like the idea of 4_0 and 4_0_FULL.  (Allow 4_0_COMPACT to
> be represented as !4_0_FULL.  So any 4_0 specific code that is not
> compact vs. full conditioned is under 4_0 and if it is only full it is
> under 4_0_FULL and it if is compact only it is under !4_0_FULL. I fear
> that NETCP will complicate things as we move from the 1.0/1.1 compact to
> the 4.0 compact and potentially to a 3.5 compact if that is necessary in
> the future.  (Right now, the 3.5 compact COULD be considered a 2.0
> compact.  Yes, you must target 3.5 to get the choice of compact, but you
> do not have to take advantage of 3.5 specific code.)

> I would further say that any code that works in 2.0 and 4.0 has NO
> conditionals around it, but not include compatibility with 1.0/1.1 as a
> requirement for no conditional. To elaborate, the 2_0 tag becomes 2_0
> specific code.  (Code that does not work in 4.0.)  Any 2.0 code that
> does not work in 1.0/1.1 becomes !1_0

Going forward I pretty much agree with you - but then again we may not
need to think about 1.x and compact framework at all then 8-)

For the 1.2.x branch I'd prefer to stick with the current approach in
order to minimize code changes.

> Other than MONO I do not believe the family concept will serve us going
> into the future.  What I am really saying is that the base code will
> favor 2.0/4.0 of the framework and anything that differs from that
> requires a conditional.

I'm not even convinced we'll need much Mono specific code at all -
outside of appenders, maybe.  Buth then again I must admit that there
are quite a few parts of trunk that I never really looked into, so I may
be wrong.

> This idea is probably not in keeping with the original concept, but the
> framework has grown well beyond what was envisioned when the project
> started and we might need to adjust our thinking to match.

+1

Stefan

Re: State of Client Profile and .NET 4.0 Support

[Stefan Bodewig]

On 2011-09-04, Stefan Bodewig wrote:

> On 2011-08-25, Ron Grabowski wrote:

>> Is your .NET 4 support just in the NAnt scripts?

> Yes, exclusively.

>> It's probably safe to replace the VS2008 solution file with a VS2010
>> version.

> I didn't go that far because my VS insisted on converting the project
> files as 

There now is a VS2010 solution (and corresponding project files for
log4net and the tests) that target .NET 4.0 and set the proper
compilation symbols.

I could have done the same for client profile builds but felt I'd
promise to maintain them if I did - and right now I don't really plan to
actively maintain any of the VS projects/solutions.

Stefan

New DEBUG Snapshots of trunk - with Client Profile

[Stefan Bodewig]

Hi,

I've run VS 2010's static code analysis using the security rule set on
the current code base and fixed all places where it complained about
transparent code referencing security-critical code or code overriding
security-critical methods.

The result is a bit more than the SecurityCritical attributes provided
in JIRA patches or in patches I found floating around on the web (there
are quite a few "make log4net work on 4.0 patchsets) - fortunately it
seems to be a super set.

By now I can log using .NET Client Profile and get the same 10 unit test
failures on 4.0 that I get on 2.0 - I'd call that progress.

The intermediate results can be found at
 with net-cp holding the
client profile compiled DLLs.  Again, this is in no way a release and I
may remove the directory without warning.

We'll need to review the places I've marked up as SecuritySafeCritical
in order to verify we don't need to perform additional security checks
beyond what the called code will already do.

The security ruleset also complains about a few other things that I may
turn into JIRA issues for a future release soemtime later (much later, I
guess).

Stefan

First JIRA triage run complete

[Stefan Bodewig]

Hi all,

as you have seen in the storm of JIRA emails I went through all JIRA
issues and assigned them to some "fix version".  Some of them looked
invalid but I only closed the most obvious ones.

After I now have read all of them, on piece of code is sticking out as a
major pain point: RollingFileAppender.  A double digit number of issues
are raised against it.  I have assigned two or three of them to 1.2.11
but we can also push the whole thing back if it seems as if the code
needs some re-thought to get it right.

If anybody is looking for an isolated piece of code that needs to be
fixed without any need to understand the whole code base,
RollingFileAppender it is.  If anybody wants to play with it, please
raise your hand so we don't duplicate effort.

The next things I intend to focus on is fixing the currently failing
unit tests on Windows 7, generating the site (and fixing some related
doc issues while I'm at it) and the whole build system so we can
actually create a distribution.

Stefan

Does MinimalLock actually work with AppendToFile = false?

[Stefan Bodewig]

Hi,

while looking into the failing unit tests I started to wonder whether
TestMinimalLockUnlocks in RollingFileAppenderTest has ever passed - and
if it actually can.

The test uses a RollingFileAppender with AppendToFile=false and a
MinimalLock locking model.  Since the MinimalLockingModel re-opens the
file for each message it is going to overwrite the existing file - this
is what the code does and why the test fails.

As I've never used MinimalLock myself I don't know whether it is
supposed for the append=false case at all - at least the docs don't say
it wouldn't work.

Stefan

Re: Does MinimalLock actually work with AppendToFile = false?

[Stefan Bodewig]

On 2011-09-06, Stefan Bodewig wrote:

> while looking into the failing unit tests I started to wonder whether
> TestMinimalLockUnlocks in RollingFileAppenderTest has ever passed - and
> if it actually can.

I should have looked through svn history first.  svn revision 607475
which adds the new (undocumented AFAICS) MutextLock LockingModel has
broken the test by removing a tiny little line (resetting m_append to
true after opening the file for the first time).  Should be fixed in a
second.

Stefan

Re: First JIRA triage run complete

[Stefan Bodewig]

On 2011-09-06, Roy Chastain wrote:

> I will take on RFA.  I have had my issues with it and even added a
> different rolling method for my local use.

Great.

I'll likely modify the test case to add tests for the MutexLock (I
suspect it doesn't work as advertized).  The resulting fixes won't touch
RFA but rather FileAppender, though.

> This brings us back to how do I get the current code with any additions
> to start working from.

First pull the current trunk from subversion - there now is a VS2010
solution that targets 4.0 you can start from.  I have also used NUnit's
GUI test runner on the test DLL created by VS and it works OK (I have
some test failures, but some of them happen with NAnt as well).

I don't think there are any patches appended to any of the open JIRA
issues WRT RollingFileAppender so svn is all you have.  In one of the
tickets Ron even mentions major changes in RFA since 1.2.10 so if there
were any patches they likely wouldn't apply anymore anyway.

It is also possible that some of the issues reported against 1.2.10 have
already been fixed by some of the changes Ron mentions.  It is probably
best to start with a test case (we always do that anyway, no ;-).

Once you are done, run "svn diff" in the top level directory and attach
the result as patch to the JIRA ticket.  I'll take care of it from
there.

Stefan

mvn based log4net website

[Stefan Bodewig]

Hi all,

based in major parts on work done by Curt earlier and inspired by
log4php I've created a mvn site-plugin based version of the log4net
site.  The current result can be seen here
 and it should be very
similar to the existing site.

The major difference is that I've removed the list of contributors from
the landing page, the same list (with my name added) is available from
the "Project Team" page.

Other than that the site should comply with all branding requirements -
this means it has a few "Apache"s and "TM"s sprinkled all over the site
and a new footer on every page.  I've also fixed a few other JIRA issues
about broken links on the way.

I have not modified the download page as there is a reason it doesn't
use mirrors right now.  The only log4net releases that have ever been
made at the ASF are Incubator releases and the release artifacts have
never been moved under the logging dist area.  By now they have also
been removed from the incubator area.  This means they are not available
from www.apache.org at all (which also mean not from any mirror at all)
and all download links point to archives.apache.org.  This will be fixed
once we have our next release.

Unless anybody yells I plan to replace the current log4net site with the
directory linked above in a few days.

Stefan

Re: mvn based log4net website

[Stefan Bodewig]

On 2011-09-07, Christian Grobmeier wrote:

> looked at it - great job Stefan.

Curt had already done most of the conversion from the Anakia based site.

> There is only thing I found so quick - look at the logo top left you have 
> used.
> You could replace it with the logo here:
> http://logging.apache.org/log4php/
> It has a (tm) symbol in it.

Thanks!  Fixed (and I also copied the mvn feather from log4php while I was
at it).

Stefan

Distribution Formats

[Stefan Bodewig]

Hi all,

1.2.10 is distributed as a single ZIP with source and binaries for all
supported platforms.  "Normal" ASF procedure is to have separate
downloads for source-only and binary-plus-doc releases and to provide
ZIPs as well as tar.gz tarballs.

How do we want to package 1.2.11?

I personally would stick with ZIPs only but create three archives:
source only, binaries signed with new key plus docs, binaries signed
with old key plus docs.

Any other preferences?

Stefan

Forth digit in version number

[Stefan Bodewig]

Hi,

I don't expect us to release betas or any other kind of two releases
that would only differ in the forth digit of the version number.  So we
could simply set it to 0 (which I think currently happens in trunk,
didn't check).

Right now I'm afraid I won't be able to build all binaries on the same
machine so ".*" would result in different versions depending on the
platform.

An alternative would be to use the svn revision number.

Other ideas?

Stefan

Re: Forth digit in version number

[Stefan Bodewig]

On 2011-09-08, Michael Schall wrote:

> We set the forth digit to 0 for the AssemblyVersion attribute and SVN
> revision number for the AssemblyFileVersion attribute.  This way you can
> slipstream fixes without breaking compatibility with other's code, but you
> still have the revision number if you want it.

I'd rather release 1.2.NEXT then.  YMMV.

> We also add the actual SVN url to the AssemblyDescription so you can grab
> the exact code easily.

Interesting.  How do you integrate this with your build process?

I was thinking about using "svn info" or even parsing the .svn contents
but don't really feel comfortable enough with NAnt to do that (and don't
know whether things like TutroiseSvn or AnkhSvn or whatever provide a
svn command line client for svn info to work).

Stefan

Re: Forth digit in version number

[Stefan Bodewig]

On 2011-09-08, Michael Schall wrote:

>> Interesting.  How do you integrate this with your build process?

> I can give you specifics if you want, but we use MSBuild and MSBuild
> Community Tasks (http://msbuildtasks.tigris.org/)...

> We have a target that uses the SvnInfo task to find the SubersionRevision
> and RepositoryPath properties, and use the FileUpdate task update the
> AssemblyInfo files as needed.

I see.  For our NAnt build Dominik's response should point me into the
best direction.

Thanks

Stefan

Re: Forth digit in version number

[Stefan Bodewig]

On 2011-09-08, Dominik Guder wrote:

> using nant for retreiving svn revision to property svn.revision:
> use svn log (repository access)

>output="_svnrevision.xml" failonerror="true" >
> 
> 
> 
> 
> 
>   xpath="/log/logentry/@revision"
>  property="svn.revision"
>  failonerror="true"/>

It is likely fair to assume that whoever uses NAnt also has a svn
command line client around - or I need to provide some sort of fallback
if it isn't.

Thanks.

Stefan

Re: Distribution Formats

[Stefan Bodewig]

On 2011-09-09, Ron Grabowski wrote:

> New key? I think I Nicko sent me the current assembly keya long time
> ago. People always complain when keys change

Search a while back through your mail backlog (about a month).

There is consensus to move to a new key that is deliberately not kept
secret so people can build their own patched versions of log4net and get
the same strong name.

We will explain that the key does not provide any sort of security
promise - people are supposed to verify the PGP signature for that.

Some people may rely on the implied promise of "this is the real thing"
of the old key which is why Curt asked us to not make the old key public
(this is the only reason why we need a new key).

1.2.11 and maybe later releases should be available with two different
strong names.

Stefan

What to do with EventLogAppender on Vista and newer?

[Stefan Bodewig]

Hi,

as stated in LOG4NET-310 EventLogAppender runs into a SecurityException
on Vista and newer if the event source doesn't exist.

ActivateOptions tries to see whether the source exists and create it if
it doesn't.  Starting with Vista even looking for a source that doesn't
exist will throw a SecurityException as you'd need to look into the
Security log as well and this requires Local Administrator privs.

I don't really know what we are supposed to do here.  All we can do is
(1) document that you need to create your event sources outside of your
application (usually during deployment) and (2) deal with the
SecurityException in a more graceful way (log something and disable the
appender, likely).

Any other ideas?

Stefan

Re: First JIRA triage run complete - RFA issues

[Stefan Bodewig]

On 2011-09-11, Roy Chastain wrote:

> I picked up Visual NUnit for VS 2010.  Once I installed it and ran the
> tests under it, none of the RFA tests failed.  The plugin indicates that
> 5 are them are "not implemented" and indeed they are not.

Great.  Six of them fail on my Linux box - likely because of hard-coded
line-ends - and I intend to look into that some day, but other than that
this is what I get as well.

> When the test is running under NUnit, the current directory is
> log4Net\tests\bin\debug, yet the logger creates its log file in
> log4Net directory.  Therefore, the two files are different and there
> is no error.  This means the tests are going to need revamping to work
> under NUnit GUI.  (Could this be a similar problem to what you have
> with NAnt?).

No, it works in both cases for me as well by now.  For the NUnit GUI it
might be some sort of setting (I use the "Run tests in a single separate
process" model).

> It appears that there is no way to change the current directory in
> NUnit GUI, so the tests would need modifications to have a consistent
> current directory while running.

> Comments/Suggestions?  I am new to the whole NUnit thing, so maybe there
> is an obvious solution I do not know about.

Just don't bother with them for now (emphasis on "for now").  You have a
way of passing the tests and so have I.

> FYI. Only 2 of the total 129 tests failed under the Visual NUnit plugin.
> TestGetEntryType in EventLogAppenderTest (looks like an expected
> SecurityException under Windows 7) and TestFullFix in
> RemotingAppednerTest.

The later might be a timing issue.  I have increased the delay between
logging a message and validating it has been written to the sink last
Wednesday - are you working on this version?  If so, then maybe the very
first wait-time must be made even bigger.

Stefan

Re: What to do with EventLogAppender on Vista and newer?

[Stefan Bodewig]

On 2011-09-11, Roy Chastain wrote:

>> (1) document that you need to create your event sources outside of
>> your application (usually during deployment) and (2) deal with the
>> SecurityException in a more graceful way (log something and disable
>> the appender, likely).

> +1 for each 1 and 2

OK, I'll see what I can come up with.

Stefan

Re: The state of RollingFileAppender

[Stefan Bodewig]

On 2011-09-12, Roy Chastain wrote:

> When I looked at this code a few years ago, I thought it was overly
> complicated and obtuse.  Since spending the day with it today, and
> discovering the invalid assumption, I stand by my original opinion.

I was afraid you'd say that when you volunteered to look into it.

So far I stayed away from RFA and concentrated on the other issues - and
never had any reason to read into RFA's code in the past.  We seem to
belong to the lucky few who haven't faced any of its internal issues.
But just from reading through the sevaral issues raised against it it
was clear to me that it must contain a multitude of problems that have
historically piled up.

> After looking at the 14 or so bug reports against RFA and remembering a
> few that I never submitted, I think RFA needs a major simplification via
> a rewrite to better handle gaps in the file names/numbers etc.

OK.

I think it would be good to push all of the RFA issues from 1.2.11 to
1.2 MAINTENANCE then and live with the fact that there will be known
issues with it in 1.2.11 - or do you expect to have a drop-in
replacement ready in a time frame of - say - a few weeks?

Unfortunately I still don't have a build environment for the "older"
frameworks (but am far from having given up on it) and this seems to be
the major hurdle for the 1.2.11 release right now.

> I am open to suggestions as to what features to add/delete from a
> rewritten RFA.  I know many people, including myself, have wanted a max
> number of files per time increment when rolled by size and time.

I think there is a JIRA issue (with patch IIRC) to that effect.

Stefan