Moving Forward

[Stefan Bodewig]

Hi all,

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

* release 1.2.11 ASAP.

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

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

* poll users which target platforms are actually needed.

Am I correct with this?

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

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

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

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

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

Stefan

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

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.
Right now the most useful log4net that people use is the svn trunk. We
shouldn't break it!

Indeed the history how a single patch evolves is not at ASF, but since
patches should be sent to the mailing list (patchbomb extension) and
discussed there (mbox extension) it is not that far from ASF at all.

Please correct me if I'm wrong.
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

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

[Dominik Psenner]

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/). Does that help us?

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

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

Yes, it should. That's also one thing I wanted to try. If MSbuild can
produce something that works for .NET 3.5/4.0 client profile and .NET
4.0 we may be able to reproduce it with NAnt. Otherwise we don't even
have to try, do we?
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Client Profiles

[Stefan Bodewig]

On 2011-08-15, Dominik Psenner wrote:

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

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

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

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

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

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

> Does that help us?

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

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

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

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

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

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-15, Dominik Psenner wrote:

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

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

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

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

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

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

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

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

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

Nope. JIRA.

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

> Please correct me if I'm wrong.

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

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

My typical workflow for any other ASF project is

* read the bug report and the attached patch

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

* rebuild the tests, run them and watch them fail

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

* commit

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

Stefan

Re: Client Profiles

[Dominik Psenner]

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. Yes, it can. I
did it at work some time. But unfortunatly it is something that defines
a projects dependencies. So it is not something that can simply be
changed by a built tool. In VS2010 you have to configure the project to
be targeted for a specific .NET framework and VS makes sure the project
finds the correct libraries.

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

*ouch*

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.

> 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? There's continuum and buildbot. The
latter runs on a win7 machine and therefore could be able to run msbuild.

Btw, why does the nant build only produce mono files?
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Client Profiles

[Stefan Bodewig]

On 2011-08-15, Dominik Psenner wrote:

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

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

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

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

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

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

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

> Where did you read up jenkins?

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

 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: Moving forward with updates, builds and versions

[Dominik Psenner]

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.

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

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

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.

If there's the risk that your logging dll crashes a software responsible
to do your money transfers just because some patch was included that
shouldn't have been, the fun ends for sure.

Well, maybe I'm overdoing it a little but IMHO a library that is well
spread should be developed "safe".

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

Then the medium to transfer a patch is JIRA and not the mailing list.
Doesn't change much, does it? :-)
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

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

[Roy Chastain]

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

2) - We certainly need code that will compile against the 4.0 Framework.
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 think we should produce the assemblies because of the 3rd party
apps.

--
Roy Chastain




-Original Message-
From: Stefan Bodewig [mailto:bode...@apache.org] 
Sent: Monday, August 15, 2011 02:29
To: log4net-dev@logging.apache.org
Subject: 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

RE: Client Profiles

[Roy Chastain]

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

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.

--
Roy Chastain




-Original Message-
From: Stefan Bodewig [mailto:bode...@apache.org] 
Sent: Monday, August 15, 2011 06:15
To: log4net-dev@logging.apache.org
Subject: 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.

 is our Jenkins farm which also contains a
Windows 2008 Server instance.  The Chemistry build likely already uses
MSBuild (yes, looks like the 3.5 version).

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

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

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

Stefan

Re: Client Profiles

[Stefan Bodewig]

On 2011-08-15, Roy Chastain wrote:

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

I understand both of those points.

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

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

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

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

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

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

Stefan

Re: Client Profiles

[Stefan Bodewig]

On 2011-08-15, Roy Chastain wrote:

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

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

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

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

Against 2.0, no?

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

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

Stefan

[jira] [Commented] (LOG4NET-108) [PATCH] add support for multiple evaluators in BufferingAppenderSkeletan

[Curt Arnold (JIRA)]

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

Curt Arnold commented on LOG4NET-108:
-

The patch file did not apply cleanly for me, perhaps the underlying source has 
changed since the patch was released.

This appears to be an API breaking change since the Evaluator property is 
removed. The number of places the code changes is very high relative to the 
potential value. Adding System.Collections.Generic may impact compatibility.

I'd agree with Nicko and Ron that this is likely better done by providing a 
CompositeTriggeringEventEvaluator that could combine several evaluators and 
combine them to expose the existing interface. That would result in only those 
people who need the feature from flowing through any new code.


> [PATCH] add support for multiple evaluators in BufferingAppenderSkeletan
> 
>
> Key: LOG4NET-108
> URL: https://issues.apache.org/jira/browse/LOG4NET-108
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders, Core
>Affects Versions: 1.2.10
>Reporter: Drew Schaeffer
>Assignee: Nicko Cadell
>Priority: Minor
> Fix For: 1.2.11
>
> Attachments: EvaluatorCollection.cs, patch-file.diff
>
>
> Currently BufferedAppenders only have support for one evaluator and one lossy 
> evaluator.  This is fine when the only available evaluator is LevelEvaluator 
> (as multriple LevelEvaluators do not make sense) but with the addition of 
> ExceptionEvaluator (LOG4NET-107) it would be nice for 
> BufferingAppenderSkeletan to have a collection of evaluators.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-15, Dominik Psenner wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Stefan

[jira] [Updated] (LOG4NET-233) Support .NET 4.0 including Client Profile

[Markus Ewald (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Ewald updated LOG4NET-233:
-

Attachment: log4net-1.2.10-net-4.0.patch

Patch that adds .NET 4.0 Client Profile compatibility to the official log4net 
1.2.10 release.

Uses fine-grained security settings (SecurityCritical and SecuritySafeCritical) 
instead of skipping verification for the whole assembly.

> Support .NET 4.0 including Client Profile
> -
>
> Key: LOG4NET-233
> URL: https://issues.apache.org/jira/browse/LOG4NET-233
> Project: Log4net
>  Issue Type: New Feature
>  Components: Appenders, Builds, Core, Documentation, Examples, Other
>Affects Versions: 1.2.11, v.Next
> Environment: Windows XP, Vista, 7 - .Net 4.0
>Reporter: Daniel mcGloin
> Attachments: 233b.patch, NET4.patch, log4net-1.2.10-net-4.0.patch
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Please add a release targeting .NET 4.0 (currently in Beta 2).  In addition, 
> to support the .NET 4.0 Client Profile, divide any server-side parts into a 
> separate library set that can be optionally referenced/deployed..

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LOG4NET-233) Support .NET 4.0 including Client Profile

[Markus Ewald (JIRA)]

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

Markus Ewald commented on LOG4NET-233:
--

I have added a patch with the changes I've been using for about a year now, 
enabling a .NET 4.0 Client Profile build. Maybe it can help in some way. If 
not, just ignore it or kill it :)

> Support .NET 4.0 including Client Profile
> -
>
> Key: LOG4NET-233
> URL: https://issues.apache.org/jira/browse/LOG4NET-233
> Project: Log4net
>  Issue Type: New Feature
>  Components: Appenders, Builds, Core, Documentation, Examples, Other
>Affects Versions: 1.2.11, v.Next
> Environment: Windows XP, Vista, 7 - .Net 4.0
>Reporter: Daniel mcGloin
> Attachments: 233b.patch, NET4.patch, log4net-1.2.10-net-4.0.patch
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Please add a release targeting .NET 4.0 (currently in Beta 2).  In addition, 
> to support the .NET 4.0 Client Profile, divide any server-side parts into a 
> separate library set that can be optionally referenced/deployed..

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: Client Profiles

[Roy Chastain]

Sorry, I probably did not express my points well.

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.  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.  (I have
one of those distributions right now.)  Even once the 3.5 SP1 package
that is "provided" by the SDK install is installed, there is still the
".NET Framework Family Update..." package that is only available via
Windows/Microsoft Update.  (This update fails on many older somewhat
corrupted XP systems.)  If a developer needs to release this update with
their install package, they would have to build package files for 3
different hotfixes (one for 2.0, 3.0 and 3.5) and for, I think, 4 (maybe
even more) different OS combinations. .  

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.  However, Windows XP, Vista, Server 2003 and 2008 do not come
with a 3.5 framework and therefore it MAY need to be installed.

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.

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

It is my contention that many of the users of log4Net have no idea about
the inoperability of the CLRs and that 4.0 can consume 2.0 targeted
code.  I believe this because of the number of questions that start
along the lines of, "I cannot find the 4.0 version of log4Net, how can I
use it in x".  Someone then explains to them that it will just work.
Unfortunately, the response never says that they need both frameworks
installed on the target system.

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.  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.  (Please note that the install sequence is 3.5 SP1 followed by 4.0
followed by a system restart followed by the application.  Another
restart must be done after the application is installed.)  While this is
not our problem, it does raise yet more obstacles to interoping a 2.0
targeted assembly with a 4.0 targeted application.

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


--
Roy Chastain




-Original Message-
From: Stefan Bodewig [mailto:bode...@apache.org] 
Sent: Monday, August 15, 2011 09:00
To: log4net-dev@logging.apache.org
Subject: 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

RE: Client Profiles

[Roy Chastain]

>> I think csc is smart enough to drop references that aren't actually
used.  
Apparently not.  Below is text from the announcement of the 3.5 client
profile at
http://blogs.windowsclient.net/trickster92/archive/2008/05/21/introducin
g-the-net-framework-client-profile.aspx.  I draw you attention to the
last sentence of the second paragraph.


Checking this option will update the project in two ways. First, the
compiler will check the project's assembly references against a list of
Client Framework Assemblies to see if there are any conflicts. If your
project references assemblies that are not in the Client Framework
Assemblies list, it will show up as a compilation warning. 

Developers will need to be aware of this compilation warning and make
the appropriate changes to their project in order to function properly
on the Client Profile. If this is not done, applications may see random
MethodNotFoundException error messages or their applications may not
function properly at all.

--
Roy Chastain




-Original Message-
From: Stefan Bodewig [mailto:bode...@apache.org] 
Sent: Monday, August 15, 2011 08:57
To: log4net-dev@logging.apache.org
Subject: 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

[jira] [Created] (LOG4NET-303) How to do configuration in assembly.cs file for log4net implementation?

[Vanitha (JIRA)]

How to do configuration in assembly.cs file for log4net implementation?
---

 Key: LOG4NET-303
 URL: https://issues.apache.org/jira/browse/LOG4NET-303
 Project: Log4net
  Issue Type: Bug
 Environment: .net 3.5 ..Implementing log4net for aspx and asp pages
Reporter: Vanitha


I am trying to implement the log4net. In my project ,i am referring a dll 
project,which has the log4net implementation and i am calling the dll from from 
my asp number. 
 
  The call is successful from asp to dll method and the logger is created just 
fine.
 

private static readonly ILog log = 
LogManager.GetLogger(typeof(ErrorLogging).Name);

But the problem is the logger is not enabled. I mean 
IsErrorEnabled/IsDebugEnabled are false.

The confusing part to me is assembly.cs,in which the place where we mention the 

[assembly: log4net.Config.XmlConfigurator(ConfigFileExtension = "log4net", 
Watch = true)]
// This will cause log4net to look for a configuration file
// called TestApp.exe.log4net in the application base
// directory (i.e. the directory containing TestApp.exe)
// The config file will be watched for changes.

So ,do i need to create a file with .log4net extension ,if so i tried and its 
not working.
And not working from my web.config also. 

Please see my web.config code 

  



  
  
  
  
  

  


  
  
  

  




And the dll method ,where i am accesing the log 

log4net.Config.XmlConfigurator.Configure();
log4net.ThreadContext.Properties["EventID"] = 6;

String tempdata=string.Empty;

if (!System.Diagnostics.EventLog.SourceExists(sourceName))
{
tempdata = sourceName + logName + objErr + strBotListPath;
System.Diagnostics.EventLog.CreateEventSource(sourceName, 
logName);
}
else
{
if (log.IsDebugEnabled)
{
log.Debug("This is a DEBUG level message. The most VERBOSE 
level.");
log.Info("Extended information, with higher importance than 
the Debug call");
log.Warn("An unexpected but recoverable situation 
occurred");
tempdata = "Source already exits";
}
else
{
tempdata = "Source already exits,but debug not enabled";
}
}

The output is 
 

Source already exits,but debug not enabled 

it works fine while doing in Global.asax file,but these issues are only 
accessing the external dll. So my questiona are in assembly.cs like where the 
.log4net config file should be placed?.Or am i doing anything wrong in the 
config part... 

Please give me some input...

Thanks

 **UPDATE**
After removing the below line 

[assembly: log4net.Config.XmlConfigurator(ConfigFileExtension = "log4net", 
Watch = true)]

and changing the line,by placing the log4net.config in 
C:\windows\system32\inetsrv,the error log is enabled.**But i am not seeing any 
errors in the eventLog its empty**

 log4net.Config.XmlConfigurator.ConfigureAndWatch(new 
FileInfo(AppDomain.CurrentDomain.SetupInformation.ApplicationBase+"log4net.config"));




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Questions for our poll

[Roy Chastain]

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

1) - Do you need an assembly targeting the 1.0 and/or 1.1 framework?
2) - Please prioritize the following
Producing an assembly targeting the 3.5 client profile
Producing an assembly targeting the 4.0 framework
Producing an assembly targeting the 4.0 client profile
3) - Do you need an assembly targeting the MONO framework?
4) - Do you need an assembly targeting the 1.0/1.1 compact framework?
5) - Do you need an assembly targeting the 2.0 compact framework?
6) - Do you need an assembly targeting any version of Silverlight?  (if
enough say yes, we come back and ask about what versions)
7) - Do you need an assembly targeting Silverlight on Windows Phone 7?

--
Roy Chastain

Re: Client Profiles

[Stefan Bodewig]

On 2011-08-15, Roy Chastain wrote:

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

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

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

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

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

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

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

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

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

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

Yes, I agree by now.

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

Same here.

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

Ouch.

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

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

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

Stefan

Re: Questions for our poll

[Stefan Bodewig]

On 2011-08-16, Roy Chastain wrote:

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

Looks good to me.

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

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

Stefan