Re: cvs commit: logging-log4net/src/Util PatternString.cs
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
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
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
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: [g...@vmgump]: Project logging-log4net (in module logging-log4net) failed
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
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
Re: abandoned?
On 2010-05-03, Ron Grabowski rongrabow...@yahoo.com 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: Compiling log4net with strong name and 3rd party dependencies (also is log4net in a cul-du-sac)
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)
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 junit 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)
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
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
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
Re: Moving forward with updates, builds and versions
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
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
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
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
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
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
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
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
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
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
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
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
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: Open issues for 1.2.10 release
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)
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
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
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
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
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
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
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
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
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
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
Re: .NET 4 branch
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
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
Planning 1.2.11
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
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
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)
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 NetFx40_LegacySecurityPolicy enabled=true/ 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
Hi all, http://people.apache.org/~bodewig/log4net/ 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
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
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 NetFx40_LegacySecurityPolicy enabled=true/ and seems to need it. This may complicate things even further. Stefan
Re: ADO.NET Appender and FX 4.0
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
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
Re: ADO.NET Appender and FX 4.0
On 2011-08-20, Roy Chastain wrote: I should add that NAnt.exe.config contains NetFx40_LegacySecurityPolicy enabled=true/ 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
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
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
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
New DEBUG Snapshots of trunk - with Client Profile
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 http://people.apache.org/~bodewig/log4net/ 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
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
Re: Does MinimalLock actually work with AppendToFile = false?
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
mvn based log4net website
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 http://people.apache.org/~bodewig/log4net/site/ 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 Apaches and TMs 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
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
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
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
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
On 2011-09-08, Dominik Guder wrote:
using nant for retreiving svn revision to property svn.revision:
use svn log (repository access)
exec program=svn.exe workingdir=${svnroot} verbose=false
output=_svnrevision.xml failonerror=true
arg value=log /
arg line=${svnroot} --xml --limit 1 -q /
arg line=--username=foo --password=bar --no-auth-cache /
/exec
sleep milliseconds=500 /
xmlpeek file=_svnrevision.xml
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
What to do with EventLogAppender on Vista and newer?
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: The state of RollingFileAppender
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
Re: What to do with EventLogAppender on Vista and newer?
On 2011-09-12, Stefan Bodewig wrote: 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. (1) has already been done http://logging.apache.org/log4net/release/faq.html#trouble-EventLog and it doesn't even apply to Vista and newer only (what is new is that you need local admin privs to even check whether an event source exists). I've improved the error logging that is going to happen and closed the issue. Stefan
Re: Forth digit in version number
On 2011-09-12, Dominik Guder wrote:
Am 09.09.2011 05:52, schrieb Stefan Bodewig:
On 2011-09-08, Dominik Guder wrote:
using nant for retreiving svn revision to property svn.revision:
use svn log (repository access)
exec program=svn.exe workingdir=${svnroot} verbose=false
output=_svnrevision.xml failonerror=true
arg value=log /
arg line=${svnroot} --xml --limit 1 -q /
arg line=--username=foo --password=bar --no-auth-cache /
/exec
sleep milliseconds=500 /
xmlpeek file=_svnrevision.xml
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.
Hi Stefan, since we are using CC.Net as CI and build tool svn.exe is
required on our buildserver. The only point we need assembly
versioning. Another solution could be tortoisesvn.net
subwcrev.exe. See
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html
Using #svn and create a svn nant task is possible, but currently out
of scope for me.
Well, in our case I think - at least for now - I can simply limit it to
command line svn because it is going to be available on the machine that
builds the release binaries.
We want people to be able to build log4net from the source package
downloaded from our website. In this case the extracted tree doesn't
have any svn information at all (in fact it doesn't correspond to a
revision number at all if local changes have been made) and the build
file has to cater for this.
I'll try to set up something that uses svn.exe to determine the
information I want and uses 0 as forth digit and an URL of unknown
revision of log4net_trunk_url_here as fallback.
Stefan
Re: Possible new code - DynamicPatternLayout
On 2011-09-12, Roy Chastain wrote: I have a new class that I implemented several years ago. It provides a DynamicPatternConverter. Its primary purpose is to provide dynamic headers and footers in logs. Aren't you paying a big price for this by also making the normal pattern dynamic? Maybe there is room for something in between where only Header and Footer are dynamic? I do not have test cases. But could add some ;-) This code is available for inclusion in log4Net if anyone feels that it is worth including. I think it is (post 1.2.11). Stefan
Name for MutexLock?
Hi, LOG4NET-164 introduced a new locking strategy for FileAppender which technically uses a System.Threading.Mutex with a name built from the log file's name. This should allow separate processes to share a log file without repeatedly opening and closing it. The main remaining issue is its name (apart from docs which will follow once the name is settled). Right now it is called MutexLock but that may not convey to users what this actually does - they'd need to know what a Mutex is in the first place. I'm notoriously bad at names so I'm asking here now. Names suggested in the JIRA ticket are InterProcessLock, SystemWideLock and GlobalLock. Stefan
Re: Name for MutexLock?
On 2011-09-13, Dominik Psenner wrote: LOG4NET-164 introduced a new locking strategy for FileAppender which technically uses a System.Threading.Mutex with a name built from the log file's name. This should allow separate processes to share a log file without repeatedly opening and closing it. The main remaining issue is its name (apart from docs which will follow once the name is settled). Right now it is called MutexLock but that may not convey to users what this actually does - they'd need to know what a Mutex is in the first place. I'm notoriously bad at names so I'm asking here now. Names suggested in the JIRA ticket are InterProcessLock, SystemWideLock and GlobalLock. Are we talking about the variable name? In that case I would prefer a name that makes it obvious what it is behind: MutexLock Not only, it would also appear inside the config file in order to set the locking model of FileAppender like in the third example of http://logging.apache.org/log4net/release/config-examples.html#fileappender Right now it would be lockingModel type=log4net.Appender.FileAppender+MutexLock / Did you actually do performance tests too? A mutex is rather expensive and it should be avoided to acquire/release it multiple times unless really necessary. It would be aquired and released for each single logging event. The alternatives are (1) don't share the same log file between different processes or (2) repeatedly open and close the file (which is the MinimalLocking model). Whether the mutex performs better or worse than MinimalLocking depends on the concrete circumstances, I guess, but I'd expect the overhead of opening a file to be significant as well. Stefan
diffs between 1.2.10 and current trunk
Hi all, in order to shape up for the release I diffed the 1.2.10 release ZIP source tree against current trunk's src and used BitDiffer from bitwidgets[1] to compare the DEBUG assemblies targeting 2.0 in binary. The results can be found in http://people.apache.org/~bodewig/log4net/diffs/ The source code diffs are mainly there so we can put together proper release notes and see whether there are changes not covered by resolved JIRA issues. They may also be useful to catch mistakes now, but that is going to require a long time and sharp eyes, I'm afraid. I've set up BitDiffer to not compare implementations but really only signatures. The breaking changes it flags right now: (1) the several variations of static Configure methods in configurators now return ICollection, they used to be void methods. (2) ConverterInfo used to be a nested class of PatternLayout and has been moved to the Util namespace. (3) The signature of the CreateLogger method in ILoggerFactory has changed. (4) Several LogLog method signatures have changed. Of this only (3) really concerns me as I consider ConverterInfo and LogLog internal to log4net and the change in return type shouldn't cause anything to break IMHO. The change in ILoggerFactory happend in svn revision 515275[2] for LOG4NET-97[3]. Back then Nicko was aware this was breaking BWC (the commit log says so) but accepted it as necessary. This likely means we should document the change and live with it. Stefan [1] http://bitwidgets.com/ [2] https://svn.apache.org/viewvc?view=revisionrevision=515275 [3] https://issues.apache.org/jira/browse/LOG4NET-97
Re: Name for MutexLock?
On 2011-09-14, Ron Grabowski wrote: Can you share a config snippet showing how to use the RemotingAppender like you've described? We used to have an extraordinally simple Windows Service at $work that didn't do much but using log4net writing to a file and starting the RemoteLoggingServerPlugin. Unfortunately I don't think I can share the code (trivial as it is). The real applications would then all use RemotingAppenders. What happens when one of the apps goes down? The RemotingAppender tries to flush all message in shutdown but if things go really bad you may be losing some messages, this is true. Stefan
Does anybody have any idea on where to find the really old framework (and CF) SDKs?
Hi all, I now have an environment that builds .NET 1.1 up to 4.0 (including client profile) and both Mono targets. For .NET 1.0 and ECMA I can't find any traces, for SSCLI 1.0 I do find hints at a source code only download for the 2.0 version but don't have any idea whether this would work with NAnt (and needed to figure out how to build it in the first place). Any ideas? For compact framework I have installed the 3.5 runtime but the thing closest to a SDK I have found is the Windows Phone 6 SDK which requires VS 2008 (the real one, not Express) and before I try my luck and try to install it on a system with VS 2010 I thought I'd better ask whether I'm overlooking something here as well. Stefan
ExclusiveLock on Mono/Linux
Hi, I'm down to one failing test on my Ubuntu Linux box (Ubuntu 10.4 with Mono 2.4, I'm conservative 8-): RollingFileAppender.TestExclusiveLockLocks. What happens on Linux is that an attempt to open a locked file throws an exception (as expected by the test) but the file is truncated anyway. After that when the next statement gets written the file is filled with zero bytes up to the length it had before and then the new text is appended. This likely is a bug in the specific version of Mono but may be worth highlighting in the docs - something like ExclusiveLock is known to have issues with some versions of Mono on Linux. Stefan
Re: Does anybody have any idea on where to find the really old framework (and CF) SDKs?
On 2011-09-16, Stefan Bodewig wrote: On 2011-09-15, Roy Chastain wrote: You have to go back to VS.NET (circa 2000) for .NET 1.0. I really hope no one is still using 1.0. Maybe it is time to drop support for it with 1.2.11 already. A kind soul still found the .NET 1.0 SDK and made it available to me. I'll have to uninstall all newer frameworks (and SDKs) in order to install 1.0 and re-install them later but this should give us .NET 1.0 assemblies for log4net 1.2.11. Stefan
Re: Does anybody have any idea on where to find the really old framework (and CF) SDKs?
On 2011-09-15, Stefan Bodewig wrote: For .NET 1.0 and ECMA I can't find any traces, Both are the same - and covered now. for SSCLI 1.0 I do find hints at a source code only download for the 2.0 version but don't have any idea whether this would work with NAnt (and needed to figure out how to build it in the first place). Any ideas? I'll try to play with this during the weekend. For compact framework I have installed the 3.5 runtime but the thing closest to a SDK I have found is the Windows Phone 6 SDK which requires VS 2008 (the real one, not Express) and before I try my luck and try to install it on a system with VS 2010 I thought I'd better ask whether I'm overlooking something here as well. And install VS2005 or 2008 with phone stuff unless a different solution can be found. Stefan
Re: Does anybody have any idea on where to find the really old framework (and CF) SDKs?
On 2011-09-16, Roy Chastain wrote: I am trying to remember if there were two version of the compact framework. I am not sure of my memory, BUT I think there was both CF 1.1 and 2.0 release. If so, that most likely means both versions. The NAnt build file has compilation targets for CF 1.0 and 2.0. Check out this link http://msdn.microsoft.com/en-us/netframework/aa497280 This link http://msdn.microsoft.com/en-us/netframework/aa569263 shows more downloads on the right. You SHOULD be able to download and install the .NET SDKs without Visual Studio. That's how I got my 1.1, 3.5 and 4.0 SDKs 8-) I did not install the 2.0 SDK but the 3.5SP1 one, maybe the CF tools are part of the 2.0 SDK, I'll give that a try as well. Stefan
Re: Does anybody have any idea on where to find the really old framework (and CF) SDKs?
On 2011-09-16, Stefan Bodewig wrote: I did not install the 2.0 SDK but the 3.5SP1 one, maybe the CF tools are part of the 2.0 SDK, I'll give that a try as well. After installing .NET SDK 2.0 the NAnt build also tries to build the CF 2.0 stuff, but not the 1.0 stuff. Getting closer. Stefan
Re: Does anybody have any idea on where to find the really old framework (and CF) SDKs?
Hi Gert, great to hear from you. On 2011-09-16, gert.drie...@telenet.be wrote: If I recall correctly, the CF tools are/were only available as part of Visual Studio. The .NET 2.0 SDK provided the command line tools required to build the CF 2.0 assembly. The same is not true for CF 1.0. I can provide you with the .NET Framework 1.0 redistributable, SDK and SP3 if you still need them. I already have those, thanks. What I'm missing now is SSCLI - I have the sources but it requires Visual C++ to build - and CF 1.0, all other things are there. I guess I'll byte the bullet and install some old Visual Studio including C++ and phone tools. I wonder whether 2003 will work or I'd even have to go back to the 1.0 version. Also this is going to take time. The alternative would be for us to now drop support for SSCLI and CF 1.0. Stefan
Are we going to ship the examples with the binary distributions?
Hi all, I'm currently trying to make the necessary site modifications for the 1.2.11 release (for example we no longer build with VS 2008) and wondered whether we intend to bundle the examples with the binary distributions. If not, I can remove all links to them as the source dirstribution will not contain the (generated) website. Of course I don't have any intention of migrating the examples to more modern .NET environments. No matter whether we ship them bundled with the binaries. Stefan
Re: New RollingFileAppender semantics
On 2011-09-18, Roy Chastain wrote: After having spent two weekends looking at and playing with the code, I have decided that I do not have clear understanding of my target. Poor you. Given that it appears that I am going to break the internal contract for RFA and the ambiguity in the current implementation it appears that we should create a new RFA. (Perhaps called RollingFileAppender2??) with a clear definition of its semantics. +1 - I don't like the 2 suffix so we may want to search for a better name. As such I would like to propose 1) - Make CountDirection default to positive 2) - Make PreserveLogFileNameExtension default to true 3) - Any date portion in a file name be prefixed with a . as if it were an extension. +1 3) - Decide if PreserveLogFileNameExtension applies to both the datePattern and the size roll index or just to the size roll index. I propose that it applies to size roll index and a new parameter (PreserveLogFileBase - defaults to true) be used to apply to the date roll. [Oh, another item 3. Probably used RFA to number them ;-)] I like your proposal. 4) snip/ In other words, only allow date editing within the datePattern. The following config would achieve almost same file names. file value=./output/LoggerTest.log/ datePattern value=MMddHHmm/ PreserveLogFileBase value=true/ Generated file name would look like LogTest.201109181715.log If roll type become composite, then the files would look like LogTest.201109181715.1.log, LogTest.201109181715.2.log +1 for everything that makes things more predictable. 5) - I propose that in the case of a maximum fixed size of roll backups, that the roll index become a fixed width field with leading zeros. 6) - Include a new MaxDateRollBackups parameter to limit the number of date periods that will be +1 7) - Personally I would feel no loss if StaticFileName went away and was always treated as false, but I expect that many people would want to keep it. I know the Ops folks of one of my team's bigger deployments would want it. Stefan
Re: New RollingFileAppender semantics
On 2011-09-19, Dominik Psenner wrote: file value=bla.log/ datePattern value=MMddHHmm / rollFileConfiguration rollFileCondition size=5MB / rollFileLimitation maxcount=5 / /rollFileConfiguration Grouping the properties that affect the rolling strategy and separating them from the others makes sense to me. It may be even a nice to implement it like that. This opens ways to something like this: rollFileConfiguration rollFileAndCondition rollFileCondition size=5MB / rollFileCondition when=daily / /rollFileAndCondition /rollFileConfiguration You realize you are going down the road of boolean combinators here, aren't you? Do we roll the file if one of the conditions is met, or all of them? But I don't know if that really fits into the log4net is a clone of log4j philosophy. :-) No problem here as we are not touching the architecture only one of the appenders - and a lot of variance is allowed here. I realize you haven't been serious. Stefan
Re: Name for MutexLock?
On 2011-09-13, Roy Chastain wrote: I like InterProcessLock and would like to propose MultiProcessLock as my favorite. InterProcessLock it is. I HOPE that the documentation will indicate what a bad plan this is and that a remoteing appender etc might be a better plan. Please take a look at the re-worded FAQ entry in https://svn.apache.org/repos/asf/logging/log4net/trunk/src/site/xdoc/release/faq.xml Stefan
Re: Name for MutexLock?
On 2011-09-20, Roy Chastain wrote: https://svn.apache.org/repos/asf/logging/log4net/trunk/src/site/xdoc/re lease/faq.xml looks good with the exception of ) and has also be paid for by a loss in performance. May I suggest a rewording of . The acquisition and release of a Mutex for every log entry to be written will result in a loss of performance, but the Mutex is preferable to the use of MinimalLock. Will change it. Are you seriously suggesting that we allow the use of a Mutex lock in the new RFA? I didn't intend to. But since the current RollingFileAppender (and that's the one I'm talking about in the FAQ) extends FileAppender it can (and will) be used together with a Mutex. Rolling doesn't take the locking model into account at all and there are JIRA issues (or at least have been until they've been closed as invalid) raised by people who expect RollingFileAppender to work at least as well as FileAppender in the multiple processes write to a single file scenario. I mention RollingFileAppender in the FAQ to say it is going to make things worse. Stefan
Re: Name for MutexLock?
On 2011-09-20, Roy Chastain wrote: Based on the below, I would suggest a big disclaimer that RFA will NOT LOCK with Mutex during the rolling and will lead to extremely unpredictable results. Just put the disclaimer where you mention that RFA will make it worse. Done, at least I think so. Stefan
Dropping Support for .NET CF 1.0 and SSCLI 1.0 in log4net 1.2.11
Hi all, sorry for the cross-post but I'd like to catch oh no, you can't do that! responses as soon as possible. Apart from a few documentation and packaging issues Apache log4net 1.2.11 seems to be pretty much ready for a release. One thing that is holding up the process is the - let's say dated - build environment required to build all target binaries. So far I've been able to set up a machine with all SDKs that are freely available - what I'm still missing are the .NET Compact Framework 1.0 and SSCLI 1.0. It seems as if CF 1.0 requires an installation of Visual Studio (2003, likely) while it was sufficient to install the .NET 2.0 SDK in order to build the CF 2.0 assemblies. For SSCLI I can find the sources but it requires Visual C++ to build. So before I try to find Visual Studio 2003 - and accept that you can't build a log4net release without an IDE you have to pay for - I thought I might simply ask if anybody was opposed to have log4net 1.2.11 simply strike the two platforms. We will poll users for future directions later, so please let us limit this thread to the two frameworks in question. Stefan
Re: I will not be working on RFA Next Gen
On 2011-09-28, Roy Chastain wrote: Best of luck to all. Sorry to hear that. Stefan
Status of 1.2.11
Hi all, unfortunately I had real-life interfere and was unable to devote as much time as I wanted to. AFAICS the only things missing now are some updates to the NAnt build system to create the distribution files - which are different from what was packaged as 1.2.10 - and some updates to the site. I'll focus on getting the build infrastructure ready and intend to create some test builds from trunk for you to review by the weekend. If things go well we may be able to vote on the release sometime next week. As for site changes, I'd like to add a few FAQs. One along the lines of LOG4NET-274 (assembly load order may depend on DEBUG/RELEASE, ensure you have the attribute on correct assembly, log as early as possible). Another about why we now have two strongly named assemblies and which to use for what. LOG4NET-246 is lacking documentation but then I can't find the current documentation for the log4net.Config appsettings key at all. So we may need to add this somewhere on the configuration page. And then there is the release notes stuff which will basically be generated by JIRA with some additional notes about framework support - no binaries for CF 1.0 and SSCLI, new binaries for 4.0 and CP. Any input for the documenation tasks is more than welcome. Stefan
Testbuilds for 1.2.11
Hi all, there are three ZIPs in http://people.apache.org/~bodewig/log4net/ that correspond to what a release would look like. I mainly created them to validate the build scripts but if you want to you may view them as some sort of release candidate. The archives have been created from trunk, there is one source archive and two binaries coresponding to the two strong name keys. Please take a look at them, play with them and raise any issues you encounter. Right now I haven't created checksums as I'm pondering whether it is worth adding a build-time requirement for NAntContrib just for the checksum task if I'm going to PGP-sign the ZIPs on the command line on a box with a working md5sum tool anyway. I plan to finish the necessary site changes by the middle of next week and unless anybody finds any serious flaws intend to build and call for a vote of the final release then. Cheers Stefan
Re: RFA-NG review
Hi Dominik, On 2011-09-30, Dominik Psenner wrote: I request some feedback on the RFA-NG patch while I'm working on it. Thank you for working on it and thank you for nagging. The coming weekend - including the German holiday on Monday - is going to be quite hectic (two birthdays in the family and a Polterabend[1] in the neighborhood) for me. I don't expect to find time looking over your code until next week. But I promise I'll do. Cheers Stefan [1] Google translates this is stag party which I think is badly wrong. A Polterabend is a party organized by both people who are going to marry each other for all their friends and the neighborhood. Traditionally guests bring along old dishes and cups and so on in order to break them at the pair's doorway as Scherben bringen Glück a German saying that translates to broken crockery brings you luck and likely doesn't mean anything in English.
Re: RFA-NG review
On 2011-10-04, Dominik Psenner wrote: Don't forget the böllern Fortunately we don't do that in the lower rhine area 8-) How comes that? The last time I've seen it was about a month ago. There they used flasks of gas having the length of half a meter. It could have easily been mistaken for an airstrike. *laughing* But, to tell you the truth, I only love it as far as I'm not a witness of the terrible noise. :-D Oh, I'm sure it is fun as long as it is not your neighbor who gets woken up. I've never used ReviewBoard before but the described pre-commit workflow sounds as if it was exactly what you described with the email based workflow. Sounds great! I try to dig up some spare time. Please let me know once the organizational part is settled. Will do Stefan
Re: WebSite for 1.2.11 - Please Review
On 2011-10-05, Dominik Psenner wrote: I believe the prerequisites in FAQ could be updated to not mention .net runtime 1.0/1.1 since the release doesn't include binaries for them. It does (it won't contain binaries for Compact Framework 1.0). Stefan
Re: WebSite for 1.2.11 - Please Review
On 2011-10-05, Christian Grobmeier wrote: I looked at all pages, nothing found. I have checked brandmark requirements, all well. Thanks Just a minor thing, not important: if you go to this link: http://people.apache.org/~bodewig/log4net/site/issue-tracking.html Issue tracking is 2 times in the navigation. Not a problem, but one time is better. Hmm, this is mvn's site generation. I somehow need to suppress the Issue Tracking page from Project Documentation. Will look into this after the release. On the content of the FAQ/Release notes I have no idea :-) At least it has now been proof-read by two Germans and at least one other non-native-speaker - Dominik said he was kind-of-German. Stefan
ReviewBoard for log4net
Hi, for anybody who wants to give it a try, there now is a ReviewBoard group at https://reviews.apache.org/groups/logging-log4net/ Stefan
[RESULT] Release Apache log4net 1.2.11 based on RC1
Hi all, the vote has passed with five +1s by PMC members (Scott, Ivan, Christian, Ron, myself) and two further +1s by community members (Javier, Dominik) and I'll proceed with the process. The release artifacts are already in the dist area and are waiting for the mirrors to pick them up. Once I see them on mirrors I'll publish the new website and once that is updated I'll announce the release. Many thanks to everybody who took the time to review the release Stefan
Re: [VOTE] Release Apache log4net 1.2.11 based on RC1
On 2011-10-11, Curt Arnold wrote: both bin/2.0/release/log4net.dll and bin/3.5/release/log4net.dll describe themselves as Apache log4net for the .NET Framework 2.0. Everybody else has the expected application description. Those two DLLs are the same file as there currently is no difference between the 2.0 and 3.5 builds. Maybe I shouldn't have created the 3.5 version at all. log4net-sdk-net-4.0.chm uses a page header reading log4net SDK Documentation ... that would be better as Apache log4net SDK Documentation. Will fix that once I figure out how to do it with NDoc. doc/index.html refers to log4j and not Apache log4j. It uses Apache log4net three times before using the shorter version, I think that's OK. doc/index.html refers to the .NET runtime. The Microsoft .NET trademark guidelines are at http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/Usage/Net.aspx. At least we should have a Microsoft(r) .NET at the first menion. Will fix that - for the site as well. This likely affects other pages as well. newzip.zip: log4net-sdk-net-4.0.chm always displayed Navigation to the webpage was cancelled for any content. Seems totally broken. You probably need to unblock the .chm. I wonder why you didn't have to do that for the oldkey archive. I'm thinking it would be better to scuttle RC1 and try again, but I won't force the issue. 1.2.11 is through. I expect us to follow this up with 1.2.12 pretty soon as there still are enough issues to address and I'm sure new issues with Client Profile and .NET 4.0 builds will arise now that they become available. Stefan
Re: [VOTE] Release Apache log4net 1.2.11 based on RC1
On 2011-10-12, Curt Arnold wrote: On Oct 11, 2011, at 4:02 AM, Stefan Bodewig wrote: On 2011-10-11, Curt Arnold wrote: both bin/2.0/release/log4net.dll and bin/3.5/release/log4net.dll describe themselves as Apache log4net for the .NET Framework 2.0. Everybody else has the expected application description. Those two DLLs are the same file as there currently is no difference between the 2.0 and 3.5 builds. Maybe I shouldn't have created the 3.5 version at all. I believe they were not binary identical, but that could have been timestamps or other insignificant differences. They have been compiled separately so yes, there will be differences in timestamps. doc/index.html refers to log4j and not Apache log4j. It uses Apache log4net three times before using the shorter version, I think that's OK. It does describe log4net as Apache log4net appropriately but it does not describe log4j as Apache log4j. I somehow missed you were talking about log4*j* - will fix that in trunk and update the site later today. doc/index.html refers to the .NET runtime. The Microsoft .NET trademark guidelines are at http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/Usage/Net.aspx. At least we should have a Microsoft(r) .NET at the first menion. Will fix that - for the site as well. This likely affects other pages as well. I think the guidelines might have become looser recently. I think at one time you would have to describe it as for the Common Language Runtime and could not refer to the Microsoft(r) .NET Framework. The site I've just deployed should be OK - not visible, yet. Frequent releases what a concept. 8-) No promises, though. Stefan
Re: All mirror links broken?
On 2011-10-12, cremor wrote: I just saw that the new site with the 1.2.11 release was published (many thanks for that btw!) so I assume it should be downloadable too. Yes, it is. But all the mirror links are broken for me. I know and that's why I haven't sent out the announcement yet. The page has been fixed by now and is just waiting for the live site to pick up the changes. http://tweedo.com/mirror/apache//logging/log4net/1.2.11/binaries/log4net-1.2.11-bin-newkey.zip The extra 1.2.11 directory is wrong, but you already know that. The same is true for the md5 and pgp-sig links (you didn't even try to check them, shame on you). The solution is easy: When I remove the 1.2.11 directory from the path all of those links work. But still, should be fixed on the site ;-) Yes, many thanks for the report! Btw: The double slashes in the paths look a bit weird too. They do, but that's something that is out of our immediate scope (its the foundation wide configuration of mirrors). Thanks Stefan
[ANN] Apache log4net 1.2.11 Released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Apache log4net team is pleased to announce the release of Apache log4net 1.2.11. The release is available for download at http://logging.apache.org/log4net/download.html 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. log4net 1.2.11 is not only a bugfix release, it also adds support for .NET 4.0 as well as the client profiles of .NET 3.5 and .NET 4.0. See the release-notes at http://logging.apache.org/log4net/release/release-notes.html for a full list of changes. Starting with this release log4net uses a new strong name key but we also provide a binary distribution using the old strong name key of log4net 1.2.10 and earlier. See the FAQ at http://logging.apache.org/log4net/release/faq.html#two-snks for details. The binary distributions no longer contain assemblies built for the Compact Framework 1.0 or the Shared Source CLI - you can build those yourself using the source distribution. Stefan Bodewig on behalf of the log4net community -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk6VV4cACgkQohFa4V9ri3KyCgCgvIpZ0iwfN4GkpRSXKe8YbD8T 52UAnRXLQ7gqfgfWMFguuSG0y80IWqq/ =YICR -END PGP SIGNATURE-
Re: Old / new key flaw
On 2011-12-23, Ramon Smits wrote: I can share some thought about this new key philosophy regarding they anyone should be able to patch it but I think it is wrong. How can I validate a package from untrusted sources if they have access to the 'official' private key ? The only official binary release is the one you download from an Apache mirror and you can validate the PGP signature. For example, somebody has created a log4net nuget : http://nuget.org/packages/log4net How can I validate if this is an official binary? It is not as the log4net community doesn't have any control over it. Stefan
Re: SDK docs on apache.org don't display properly
On 2012-01-13, Ron Grabowski wrote: Anyone know why there are extended chars in most of the log4net ndoc files? For example this page has empty-blocks in IE9 and triangle-question-marks in Firefox: No idea, I used the existing ndoc target in the NAnt build file that I assume has been used for the earlier releases as well. Stefan
Re: Proposed bug fix for AspNetRequestPatternConverter.Convert()
On 2012-04-11, Ron Grabowski wrote: The converter is trying to protect itself...the base class checks to make sure HttpContext.Current is not null then a check against Request is made: Sounds like checking the property throws an exception. Its probably ok to just add in a try/catch and document that the problems with trying to check Request. I agree, svn revision 1345626. Stefan
Trouble Creating API Docs
Hi all, we currently create the online API docs via the ancient NDoc and HTML Help compiler combo. When I put together the 1.2.11 release I was lucky enough to use a machine that had been in use for a long time and so had all the required pieces installed. Now my dev environment is a freshly setup VirtualBox VM running XP with all kinds of .NET SDKs installed and I have installed the HTML Help stuff I could find - but the pieces don't want to play togther. I can't manage to build them anymore. Rather than spending more time searching for a solution using tools that are way outdated (no support for generics, much less anything that happened after 2.0) I'm looking to replace NDoc with something more modern. I have used Sandcastle Help File Builder for $work in the past but don't know whether it fits into our NAnt build system. Any other suggestions? Stefan
