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
[jira] [Resolved] (LOG4NET-233) Support .NET 4.0 including Client Profile
[ https://issues.apache.org/jira/browse/LOG4NET-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-233. Resolution: Fixed I think - apart from some tweaks that will inevitably become necessary - subversion revision should work for .NET 4.0 as well as Client Profiles of 3.5 and 4.0. https://svn.apache.org/viewvc?view=revisionrevision=1165341 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.10 Environment: Windows XP, Vista, 7 - .Net 4.0 Reporter: Daniel mcGloin Fix For: 1.2.11 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] [Updated] (LOG4NET-4) Allow user to override root directory for fileappenders
[ https://issues.apache.org/jira/browse/LOG4NET-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-4: - Fix Version/s: 1.2 Maintenance Release Allow user to override root directory for fileappenders --- Key: LOG4NET-4 URL: https://issues.apache.org/jira/browse/LOG4NET-4 Project: Log4net Issue Type: Improvement Components: Appenders Affects Versions: 1.2.9 Environment: From sourceforge - 804606 Reporter: Nicko Cadell Priority: Minor Fix For: 1.2 Maintenance Release When creating a COM-exposed object (or COM+), you can't readily use a relative file path in your fileappenders since log4net is hardcoded to use AppDomain.CurrentDomain.BaseDirectory which for a COM+ component hosted in dllhost would be systemroot\system32. I couldn't find a workaround save for regenerating the xml configuration. A call to set the root directory would be great. If there was a way to get a list of all appenders after configuration, maybe there could be a workaround. Anonymous -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-5) Support layouts that generate XML instead of text
[ https://issues.apache.org/jira/browse/LOG4NET-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-5: - Fix Version/s: 1.2 Maintenance Release Support layouts that generate XML instead of text - Key: LOG4NET-5 URL: https://issues.apache.org/jira/browse/LOG4NET-5 Project: Log4net Issue Type: Improvement Components: Core Affects Versions: 1.2.9 Environment: From sourceforge - 795051 - Curt Arnold Reporter: Nicko Cadell Fix For: 1.2 Maintenance Release I recently wrote an appender to an destination that could only accept XML documents and a custom layout that implemented the specific schema that it accepted. Unfortunately, only at that point did I realized that FormatXml was protected. I've hacked my copy to make XmlLayoutBase.FormatXml public to allow me to acheive my objectives without adding the complexity of serializing to a string and then trying to fixup encoding or other issues or reparsing. The XmlLayoutBase.Format went through a huge amount of complexity to efficiently produce string representations from calls to FormatXml. While that code could be retained for compatibility with arbitary appenders, I think the following would be beneficial. 1. Introduce an Xml specific layout interface containing FormatXml (say IXmlLayout) 2. Have XmlLayoutBase implement IXmlLayout 3. Have the file appenders check if the layout supports IXmlLayout, if it does then create one XmlWriter for the file and only use IXmlLayout.FormatXml in Append. Curt Arnold -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-8) XmlSchema for everything
[ https://issues.apache.org/jira/browse/LOG4NET-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-8: - Fix Version/s: 1.2 Maintenance Release XmlSchema for everything Key: LOG4NET-8 URL: https://issues.apache.org/jira/browse/LOG4NET-8 Project: Log4net Issue Type: Improvement Components: Appenders, Core Affects Versions: 1.2.9 Environment: From sourceforge - 776250 - Daniel Cazzulino (kzu) - dcazzulino Reporter: Nicko Cadell Fix For: 1.2 Maintenance Release It would be great to have an XSD file for the XMLLayout format, the log4j-compatible output and the log4net configuration. Thanks Daniel Cazzulino (kzu) - dcazzulino -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-6) Allow event logging on remote servers
[ https://issues.apache.org/jira/browse/LOG4NET-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-6: - Fix Version/s: 1.2 Maintenance Release I guess the original code to check is still available at sourceforge? Allow event logging on remote servers - Key: LOG4NET-6 URL: https://issues.apache.org/jira/browse/LOG4NET-6 Project: Log4net Issue Type: Improvement Components: Appenders Affects Versions: 1.2.9 Environment: From sourceforge - 791891 Reporter: Nicko Cadell Fix For: 1.2 Maintenance Release I need to be able to write to the event log on an NT server remote from my application. I have hacked up the event log appender to do this, but I am not sure that my code is right. Could someone check this code, and/or add this capability? Eric -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-9) Programmatic configuration saving
[ https://issues.apache.org/jira/browse/LOG4NET-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-9: - Fix Version/s: 1.2 Maintenance Release Programmatic configuration saving - Key: LOG4NET-9 URL: https://issues.apache.org/jira/browse/LOG4NET-9 Project: Log4net Issue Type: New Feature Components: Appenders, Core Environment: From sourceforge - 775738 - Daniel Cazzulino (kzu) - dcazzulino Reporter: Nicko Cadell Priority: Minor Fix For: 1.2 Maintenance Release I'm writing a front-end to log4net (which I will probably contribute to the project) and I have to resort to direct XML manipulation of a log4net.config file in order to change settings. It would be great if appenders, loggers and layouts have XML serialization attributes so I can load/save them directly from a file. I know the DOMHierarchyConfigurator.ParseLogger can do the load part, but there's no way to save changes back to XML (unless not without manually writing it). Worse, all constants to write it are private :(. Maybe you should follow the WSE style, defining an ElementNames class with all string constants for elements, and an AttributeNames class with all valid attribute names. This way, any third-party developer can generate and load valid log4net configuration files. Daniel Cazzulino (kzu) - dcazzulino -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-18) TcpAppender
[ https://issues.apache.org/jira/browse/LOG4NET-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-18: -- Fix Version/s: 1.2 Maintenance Release TcpAppender --- Key: LOG4NET-18 URL: https://issues.apache.org/jira/browse/LOG4NET-18 Project: Log4net Issue Type: New Feature Components: Appenders Affects Versions: 1.2.9 Reporter: Nicko Cadell Fix For: 1.2 Maintenance Release We have a UdpAppender that sends text via UDP. UDP is not designed to be robust. We should have an equivalent that uses TCP as the transport. This should just send the data in the stream similar to the FileAppender. The format of the data should be left upto the Layout. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-20) [PATCH] Adds extends attribute to appenders
[
https://issues.apache.org/jira/browse/LOG4NET-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-20:
--
Fix Version/s: 1.2 Maintenance Release
[PATCH] Adds extends attribute to appenders
-
Key: LOG4NET-20
URL: https://issues.apache.org/jira/browse/LOG4NET-20
Project: Log4net
Issue Type: Improvement
Components: Appenders
Affects Versions: 1.2.9
Environment: WinXP, .NET Framework 1.1
Reporter: Dag Christensen
Priority: Trivial
Fix For: 1.2 Maintenance Release
Attachments: DOMHierarchyConfigurator.patch
Adds extends attribute to appenders. Improvement suggested by Ron Grabowski
on log4net-user.
Sample usage:
appender name=LogFileAppenderBase
type=log4net.Appender.RollingFileAppender
param name=CountDirection value=1/
param name=AppendToFile value=true/
param name=MaxSizeRollBackups value=10/
param name=MaximumFileSize value=5MB/
param name=RollingStyle value=Size/
param name=StaticLogFileName value=true/
/appender
appender name=LogFileAppenderDefaultLayout extends=LogFileAppenderBase
layout type=log4net.Layout.PatternLayout
param name=ConversionPattern value=%d{dd.MM.yy HH:mm:ss}
[%t] %-5p %c{1} %m [%x]%n/
/layout
/appender
appender name=LogFileAppender extends=LogFileAppenderDefaultLayout
param name=File value=log.txt/
/appender
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-30) Add support for type aliases in config file
[
https://issues.apache.org/jira/browse/LOG4NET-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-30:
--
Fix Version/s: 1.2 Maintenance Release
Add support for type aliases in config file
---
Key: LOG4NET-30
URL: https://issues.apache.org/jira/browse/LOG4NET-30
Project: Log4net
Issue Type: New Feature
Reporter: Ron Grabowski
Priority: Trivial
Fix For: 1.2 Maintenance Release
IBatisNet uses type attributes in their xml config files:
type=Company.Project.Foo.Data.Entity.Product, Company.Project.Data
type=Company.Project.Foo.Data.Entity.Category, Company.Project.Data
type=Company.Project.Foo.Data.Entity.User, Company.Project.Data
to save the user from having to re-type long strings every time something
references a Product, Category, etc. They define an alias node that
contains typeAlias entries:
alias
typeAlias alias=Product type=Company.Project.Foo.Data.Entity.Product,
Company.Project.Data /
typeAlias alias=Category type=Company.Project.Foo.Data.Entity.Product,
Company.Project.Data /
typeAlias alias=User type=Company.Project.Foo.Data.Entity.Product,
Company.Project.Data /
/alias
Wherever I have to specify a type, I may use one of the aliases I defined at
the top of the file.
It would be nice if log4net supported a similiar concept. It would also be
nice if log4net shipped with some default aliases. I think normal casing
would be ok:
FileAppender - log4net.Appender.FileAppender
An example incorporating the above suggestions would be (this will probably
wrap when it posts to the mailing list):
alias
typeAlias alias=SessionContextPatternConverter
type=log4netAspExtensions.SessionContextPatternConverter,
log4netAspExtensions /
typeAlias alias=CacheContextPatternConverter
type=log4netAspExtensions.CacheContextPatternConverter,
log4netAspExtensions /
typeAlias alias=RequestContextPatternConverter
type=log4netAspExtensions.RequestContextPatternConverter,
log4netAspExtensions /
typeAlias alias=ApplicationContextPatternConverter
type=log4netAspExtensions.ApplicationContextPatternConverter,
log4netAspExtensions /
/alias
appender name=LoginFileAppender type=FileAppender
file value=c:/inetpub/wwwroot/Logs/Logins.txt /
layout type=PatternLayout
converter
name value=asp-session /
type value=SessionContextPatternConverter /
/converter
conversionPattern value=%5p %d (%c:%L) - [%asp-session{UserId}] %m%n /
/layout
/appender
I haven't fully looked into the convertor node to see if it can support
this style of attributes but an even shorted syntax might be:
appender name=LoginFileAppender type=FileAppender
file value=c:/inetpub/wwwroot/Logs/Logins.txt /
layout type=PatternLayout
converter name=asp-session type=SessionContextPatternConverter /
conversionPattern value=%5p %d (%c:%L) - [%asp-session{UserId}] %m%n /
/layout
/appender
It should be possible to overwrite the builtin aliases. Had I overridden
FileAppender:
typeAlias alias=FileAppender
type=log4netAspExtensions.AspNetFileAppender, log4netAspExtensions /
I would be able to declare my appender with support for the ~ character:
appender name=LoginFileAppender type=FileAppender
file value=~/Logs/Login.txt /
layout type=PatternLayout
converter name=asp-session type=SessionContextPatternConverter /
conversionPattern value=%5p %d (%c:%L) - [%asp-session{UserId}] %m%n /
/layout
/appender
I think that the above changes would descrease the size of the config file
and increase the files readability.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-71) Reorganise source repository to support multiple src projects
[ https://issues.apache.org/jira/browse/LOG4NET-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-71: -- Fix Version/s: 2.0 I agree reshuffling the source try may be a good idea but prefer to do that at the same time where we are going to touch a lot of code anyway. Reorganise source repository to support multiple src projects - Key: LOG4NET-71 URL: https://issues.apache.org/jira/browse/LOG4NET-71 Project: Log4net Issue Type: Task Reporter: Nicko Cadell Fix For: 2.0 The log4net source code repository needs to be updated to allow multiple projects under the src folder. Currently the source for the log4net assembly is directly in the src folder. A better structure would be: src/ log4net/ log4net.Tests/ log4net.Experimental/ xdocs/ We may want to move the examples in to the src folder, or we may want to leave then outside. The major impact of this change is to the NAnt build scripts that we use to build the log4net assembly, the examples and the tests. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-76) TextWriterAdapter is not thread safe
[ https://issues.apache.org/jira/browse/LOG4NET-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-76: -- Fix Version/s: 1.2.11 TextWriterAdapter is not thread safe Key: LOG4NET-76 URL: https://issues.apache.org/jira/browse/LOG4NET-76 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.10 Environment: Windows XP Pro sp2 with .Net 2 Reporter: Bob Peterson Priority: Minor Fix For: 1.2.11 Attachments: TextWriterAdapter.cs When logging using the XmlAppender, our company application can generate overlapping appender calls. TextWriterAppender is not thread safe. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-80) Allow LogitcalThreadContextProperties to be stored in HttpContext.Items instead of CallContext
[
https://issues.apache.org/jira/browse/LOG4NET-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-80:
--
Due Date: 13/Jul/05 (was: 13/Jul/05)
Fix Version/s: 1.2 Maintenance Release
Allow LogitcalThreadContextProperties to be stored in HttpContext.Items
instead of CallContext
--
Key: LOG4NET-80
URL: https://issues.apache.org/jira/browse/LOG4NET-80
Project: Log4net
Issue Type: Improvement
Components: Other
Affects Versions: 1.2.10
Reporter: Ron Grabowski
Priority: Minor
Fix For: 1.2 Maintenance Release
Attachments: httpContextPatch.patch
According to these posts:
http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html
http://forum.springframework.net/showthread.php?t=572
and this thread on the mailing list:
http://www.mail-archive.com/log4net-dev@logging.apache.org/msg01236.html
it might be a good idea to investigate storing LogicalThreadContext values
inside the HttpContext.Items if log4net is being used within an ASP.Net
application. Other projects such as IBatisNet, Spring.Net, Castle Project's
Active Record, etc. do this. In a nutshell, IIS may change the thread on
which a request is processed on durings the request's lifetime. Accoring to
the post on springframework.net, a worse case scenerio is for each ASP.Net
page lifecycle event to be switched to a different thread. Even though
HttpContext uses CallContext internally its supposedly does other things to
make it a safer place for storing per-request values.
I haven't studied the other projects implementations in depth but the basic
idea is to replace this code in LogicalThreadContextProperties:
PropertiesDictionary properties =
(PropertiesDictionary)CallContext.GetData(SLOT_NAME);
with this:
PropertiesDictionary properties =
(PropertiesDictionary)contextAccessor.GetData();
where contextAccessor is CallContextAccessor:IContextAccess,
HttpContextAccessor:IContextAccessor, etc.:
internal LogicalThreadContextProperties(IContextAccessor contextAccessor)
{
this.contextAccessor = contextAccessor;
}
The decision on which IContextAccessor to use could come from a factory:
public class DefaultContextAccessorFactory : IContextAccessorFactory
{
private const string SLOT_NAME =
log4net.Util.LogicalThreadContextProperties;
public IContextAccessor CreateContextAccessor()
{
// another implementation might _always_ use CallContext instead
// of first testing for HttpContext
if (HttpContext.Current != null)
{
return new HttpContextAccessor(SLOT_NAME);
}
else
{
return new CallContextAccessor(SLOT_NAME);
}
}
}
I haven't figured out a good way for LogicalThreadContext to know which
factory to be initialized with. This was my first attempt:
static LogicalThreadContext()
{
// we should retrieve the IContextAccessorFactory from the configuration
system...
IContextAccessorFactory contextFactory = new
DefaultContextAccessorFactory();
s_properties = new
LogicalThreadContextProperties(contextFactory.CreateContextAccessor());
s_stacks = new ThreadContextStacks(s_properties);
}
The problem is that IContextAccessorFactory should be coming from the
configuration system some how. Contexts don't know about ILoggerRepository
and vice versa. Maybe its acceptable for LogicalThreadContext's static
constructor to always use the DefaultContextAccessorFactory when its
initialized and the user can specify another factory via a setter.
Has anyone actually run into a problem with requests being switched to
different threads? I mostly understand the reasoning for it but I can't
imagine it being a regular occurance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-83) Allow flushing into file every X milliseconds
[ https://issues.apache.org/jira/browse/LOG4NET-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-83: -- Fix Version/s: 1.2 Maintenance Release Allow flushing into file every X milliseconds - Key: LOG4NET-83 URL: https://issues.apache.org/jira/browse/LOG4NET-83 Project: Log4net Issue Type: New Feature Components: Appenders Affects Versions: 1.2.10 Environment: All Reporter: Tal G Priority: Minor Fix For: 1.2 Maintenance Release In FileAppender you can specify either immediate flush on every message or not flushing at all. Immediate flushing reduces performance in 10% - 20%, but when flushing is skipped, then it is likely that the last few log events will not be recorded on disk when the application exits. I suggest adding a parameter that flushes to file every X millisecond. In this case you will gain most of the 10%-20% performance, and you will minimize the lost of logs when the application exits. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-82) RollingFileAppender: Cannot RollFile ... Source does not exist
[
https://issues.apache.org/jira/browse/LOG4NET-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-82:
--
Fix Version/s: 1.2.11
RollingFileAppender: Cannot RollFile ... Source does not exist
---
Key: LOG4NET-82
URL: https://issues.apache.org/jira/browse/LOG4NET-82
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.9, 1.2.10
Environment: Windows 2003 Server
Reporter: Kenneth Oberleitner
Fix For: 1.2.11
The following logging configuration will produce an endless loop of warnings
under the following circumstances:
appender name=AppRollingFileAppender
type=log4net.Appender.RollingFileAppender
param name=Threshold value=ALL/
param name=File value=Log\\Audit\\audit.txt /
param name=AppendToFile value=true /
param name=MaxSizeRollBackups value=-1 /
param name=RollingStyle value=Date /
param name=StaticLogFileName value=true /
param name=CountDirection value=1 /
param name=DatePattern value=.MMdd /
layout type=log4net.Layout.PatternLayout
param name=ConversionPattern value=%date
[%c(%property{log4net:HostName})-lt;%ndcgt;] - %message%newline /
/layout
/appender
1.) set your system clock back at least three days
2.) run an application to create the static log file dated 3 days prior
3.) set your system clock forward a day (i.e. from Monday to Tuesday)
4.) run the application again, the log file will roll and a new static
log file is written
5.) set your system clock forward a day (i.e. from Monday to Tuesday)
6.) run the application
repeated warnings will be issued until the application is killed
log4net:WARN RollingFileAppender: Cannot RollFile
[E:\tmp\LoggingFileLockBug\LoggingFileLockBug\bin\Debug\Log\Audit\audit.txt.XXX]
-
[E:\tmp\LoggingFileLockBug\LoggingFileLockBug\bin\Debug\Log\Audit\audit.txt.20060719.XXX].
Source does not exist
where XXX is infinitely incremented until the process is halted
Two workarounds found so far both involve changing the date pattern. Both
MMdd and .-MM-dd seem to work without issue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-103) RollingFileAppenders that log to a network share from a web application fail to resume logging in the event the network share is disconnected/reconnected/failsover
[ https://issues.apache.org/jira/browse/LOG4NET-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-103: --- Fix Version/s: 1.2 Maintenance Release RollingFileAppenders that log to a network share from a web application fail to resume logging in the event the network share is disconnected/reconnected/failsover --- Key: LOG4NET-103 URL: https://issues.apache.org/jira/browse/LOG4NET-103 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.9, 1.2.10 Environment: Windows 2003, ASP.NET, C# Reporter: Kenneth Oberleitner Fix For: 1.2 Maintenance Release We have seen an issue when logging from our web applications to a clustered SAN which fails over to a backup. I have recreated the scenario locally with two machines and writing a log file to a network share. 1) Enabled internal logging in log4net to a local file on MACHINE-C 2) Set up a share on MACHINE-B, and started a web application logging to that share from MACHINE-C; logs appeared on the share as expected 3) Disabled the share on MACHINE-B, refreshed the web application, the following error was reported in log4net's internal debugging log4net:ERROR [RollingFileAppender] Failed in DoAppend System.IO.IOException: The handle is invalid. at System.IO.__Error.WinIOError(Int32 errorCode, String str) at System.IO.FileStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count) at System.IO.FileStream.FlushWrite() at System.IO.FileStream.Flush() at log4net.Appender.LockingStream.Flush() at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder) at System.IO.StreamWriter.Flush() at log4net.Util.TextWriterAdapter.Flush() at log4net.Appender.FileAppender.Append(LoggingEvent loggingEvent) at log4net.Appender.RollingFileAppender.Append(LoggingEvent loggingEvent) at log4net.Appender.AppenderSkeleton.DoAppend(LoggingEvent loggingEvent) 4) Re-enabled the share on MACHINE-B, refreshed the web application; no logging appeared in the shared log file, and the following error appeared in log4nets internal debugging log4net:ERROR [RollingFileAppender] Failed in DoAppend System.ObjectDisposedException: Cannot access a closed file. at System.IO.__Error.FileNotOpen() at System.IO.FileStream.Write(Byte[] array, Int32 offset, Int32 count) at log4net.Appender.LockingStream.Write(Byte[] buffer, Int32 offset, Int32 count) at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder) at System.IO.StreamWriter.Flush() at log4net.Util.TextWriterAdapter.Flush() at log4net.Appender.FileAppender.Append(LoggingEvent loggingEvent) at log4net.Appender.RollingFileAppender.Append(LoggingEvent loggingEvent) at log4net.Appender.AppenderSkeleton.DoAppend(LoggingEvent loggingEvent) 5) Touched web.config, refreshed the web application; no logging appeared in the shared log file, and the following errors appeared in log4net's internal debugging log4net: Hierarchy: Shutdown called on Hierarchy [log4net-default-repository] log4net:ERROR [RollingFileAppender] Could not close writer [log4net.Util.CountingQuietTextWriter] System.ObjectDisposedException: Cannot access a closed file. at System.IO.__Error.FileNotOpen() at System.IO.FileStream.Flush() at log4net.Appender.LockingStream.Flush() at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder) at System.IO.StreamWriter.Dispose(Boolean disposing) at System.IO.StreamWriter.Close() at log4net.Util.TextWriterAdapter.Close() at log4net.Util.QuietTextWriter.Close() at log4net.Appender.TextWriterAppender.CloseWriter() ... log4net:ERROR [RollingFileAppender] Unable to acquire lock on file \\MACHINE-B\Log\log-file.txt. The process cannot access the file \\MACHINE-B\Log\log-file.txt because it is being used by another process. log4net:ERROR [RollingFileAppender] OpenFile(\\MACHINE-B\Log\log-file.txt,True) call failed. LockStateException: The file is not currently locked at log4net.Appender.LockingStream.AssertLocked() at log4net.Appender.LockingStream.get_CanWrite() at System.IO.StreamWriter..ctor(Stream stream, Encoding encoding, Int32 bufferSize) at System.IO.StreamWriter..ctor(Stream stream, Encoding encoding) at log4net.Appender.FileAppender.OpenFile(String fileName, Boolean append) at log4net.Appender.RollingFileAppender.OpenFile(String fileName, Boolean append) at log4net.Appender.FileAppender.SafeOpenFile(String fileName, Boolean append) ... log4net:ERROR [RollingFileAppender]
[jira] [Resolved] (LOG4NET-114) Unit tests only support .NET 1.0
[ https://issues.apache.org/jira/browse/LOG4NET-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-114. Resolution: Fixed At least the original issue has long been resolved, tests can be run for all platforms up to 4.0 in current trunk. Unit tests only support .NET 1.0 Key: LOG4NET-114 URL: https://issues.apache.org/jira/browse/LOG4NET-114 Project: Log4net Issue Type: Bug Components: Other Reporter: Curt Arnold Attachments: tests.log, tests.log tests/nant.build only supports running the unit tests on .NET 1.0, but supports compilation on .NET 1.1 and .NET 2.0. Mono is not supported for either test compilation or running. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-105) [PATCH] logical thread context
[ https://issues.apache.org/jira/browse/LOG4NET-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-105: --- Fix Version/s: 1.2 Maintenance Release [PATCH] logical thread context --- Key: LOG4NET-105 URL: https://issues.apache.org/jira/browse/LOG4NET-105 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.9, 1.2.10 Environment: Windows XP SP2, .NET 2 Reporter: Christian Kihm Fix For: 1.2 Maintenance Release Attachments: Log4NetTest.zip, LogicalThreadContext.patch The logical thread context don't propagate properties outside of the current Thread. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-118) RollingFileAppender: RollingStyle=Size with StaticLogFileName=false does not work
[
https://issues.apache.org/jira/browse/LOG4NET-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-118:
---
Fix Version/s: 1.2.11
RollingFileAppender: RollingStyle=Size with StaticLogFileName=false does not
work
-
Key: LOG4NET-118
URL: https://issues.apache.org/jira/browse/LOG4NET-118
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.10
Environment: Windows 2003 / Microsoft .NET Framework 2.0
Reporter: Patrick Gautschi
Priority: Minor
Fix For: 1.2.11
When using the an appender configuration like
appender name=InfoFile type=log4net.Appender.RollingFileAppender
file value=info.log /
appendToFile value=false /
encoding value=utf-8 /
countDirection value=1 /
maximumFileSize value=1MB /
maxSizeRollBackups value=3 /
staticLogFileName value=false /
rollingStyle value=Size /
layout type=log4net.Layout.PatternLayout
conversionPattern value=%utcdate{-MM-dd HH:mm:ss.ff}Z [%thread]
%-5level %logger - %message%newline /
/layout
/appender
results in the following error message when the application is started the
second time:
log4net:ERROR RollingFileAppender: INTERNAL ERROR. Append is False but
OutputFile [V:\...\bin\Debug\info.log.0] already exists.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-117) Migrate web content generation of Maven 2.0
[ https://issues.apache.org/jira/browse/LOG4NET-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-117: --- Fix Version/s: 1.2.11 Assignee: Stefan Bodewig I was going to look into how the current site is built anyway. We need to adapt to the branding rules as well. Migrate web content generation of Maven 2.0 --- Key: LOG4NET-117 URL: https://issues.apache.org/jira/browse/LOG4NET-117 Project: Log4net Issue Type: Task Components: Builds Reporter: Curt Arnold Assignee: Stefan Bodewig Fix For: 1.2.11 The other LS projects have been migrating to Maven 2.0 for documentation generation and deployment, packaging and, for the Java projects, build and dependency management. Migrating log4net would complete the migration and would allow consistency between the web content of the various projects. The initial commit overlays the existing source code struction with fragments of the Maven Standard Directory Layout,. The following directories are added: src/assembly - release packaging info, includes assembly.bin borrowed from another project. src/changes - project change list. Includes sample changes.xml. log4cxx has an XSLT transform that can generate changes.xml from a downloaded JIRA issue list. Used to generate change-report.html. src/site - documentation source files, site.xml contains navigation and layout details for all generated pages src/site/apt - web content in Maven's APT (almost plain text) format src/site/resources - static content copied over without processing src/site/xdoc - XDoc content, I copied the existing xdocs content here, but deleted a few no longer needed pages The existing C# code in src should be relocated to src/main/cs and the build and project files appropriately changed. For extra credit, the following relocations would bring the layout closer to a typical Maven layout: change log4net.build to generate DLL's in target (maybe target\bin) instead of bin svn rm docs svn mv examples src/examples svn mv extensions src/extensions svn mv tests/src src/test/cs svn mv tests/nant.build src/test/nant.build (modified to build test DLL's in target) svn rm xdocs pom.xml - Maven project descriptor, contains info used to generate much of the web content After installing Maven 2.0.7 (which requires a JDK 1.4 or later). Running mvn site will generate the web content in target/site/index.html. mvn site-deploy should deploy the content to the logging/site/trunk/docs SVN for staging before going live on logging.apache.org. The implementation of site-deploy uses Maven to generate the web content, invoke Nant to checkout the existing content, uses Maven's SCP deployment to copy the generated content over the existing content, and then invokes Nant to set svn:mime-type and finally commit the changes. The deployment stalled on the commit when run from Maven, but if I ctrl+c'd the process and then manually svn commit, the changes were processed. I set up a Windows build environment but ran into problems with both NUnit and NDoc that I wasn't able to get around. Setting up the SSHD to receive the uploaded web content before deployment was also less than ideal. It may be simpler to add mono, ndoc and nant to the VM used to build the other LS projects for web creation. I have left stubs that should have published the API docs if I had been successful getting them from NDoc. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
