[jira] Created: (LOG4NET-46) Support appenders that can output multiple events efficiently
Support appenders that can output multiple events efficiently - Key: LOG4NET-46 URL: http://issues.apache.org/jira/browse/LOG4NET-46 Project: Log4net Type: New Feature Components: Appenders Versions: 1.2.9 Reporter: Nicko Cadell Assigned to: Nicko Cadell Some appenders can efficiently output batches of events. Currently there is no way to pass a batch of events to an appender. Add an interface IBulkAppender that exposes a DoAppend method that takes an array of events. This interface can be supported by appenders that can process in bulk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
cvs commit: logging-log4net/xdocs/src/release example-apps.xml
nicko 2005/08/29 08:13:28 Modified:xdocs/src/release example-apps.xml Log: MS javascript line .net language is actualy called JScript.NET Revision ChangesPath 1.8 +5 -5 logging-log4net/xdocs/src/release/example-apps.xml Index: example-apps.xml === RCS file: /home/cvs/logging-log4net/xdocs/src/release/example-apps.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- example-apps.xml 26 Aug 2005 12:11:04 - 1.7 +++ example-apps.xml 29 Aug 2005 15:13:28 - 1.8 @@ -132,7 +132,7 @@ /li li b.NET 1.1/b: - a class=localOnly href=../../examples/net/1.1/Tutorials/ConsoleApp/jsJavaScript/a + a class=localOnly href=../../examples/net/1.1/Tutorials/ConsoleApp/jsJScript.NET/a /li li b.NET Compact Framework 1.0/b: @@ -141,7 +141,7 @@ /li li bSSCLI 1.0/b: - a class=localOnly href=../../examples/sscli/1.0/Tutorials/ConsoleApp/jsJavaScript/a + a class=localOnly href=../../examples/sscli/1.0/Tutorials/ConsoleApp/jsJScript.NET/a /li /ul p @@ -247,7 +247,7 @@ /li li b.NET 1.1/b: - a class=localOnly href=../../examples/net/1.1/Repository/SimpleModule/jsJavaScript/a + a class=localOnly href=../../examples/net/1.1/Repository/SimpleModule/jsJScript.NET/a /li li bSSCLI 1.0/b: @@ -282,7 +282,7 @@ /li li b.NET 1.1/b: - a class=localOnly href=../../examples/net/1.1/Repository/SharedModule/jsJavaScript/a + a class=localOnly href=../../examples/net/1.1/Repository/SharedModule/jsJScript.NET/a /li li bSSCLI 1.0/b: @@ -317,7 +317,7 @@ /li li b.NET 1.1/b: - a class=localOnly href=../../examples/net/1.1/Repository/SimpleApp/jsJavaScript/a + a class=localOnly href=../../examples/net/1.1/Repository/SimpleApp/jsJScript.NET/a /li li bSSCLI 1.0/b:
cvs commit: logging-log4net/examples/net/1.0/Layouts - New directory
nicko 2005/08/29 08:22:34 logging-log4net/examples/net/1.0/Layouts - New directory
cvs commit: logging-log4net/examples/net/1.0/Layouts/SampleLayoutsApp - New directory
nicko 2005/08/29 08:22:52 logging-log4net/examples/net/1.0/Layouts/SampleLayoutsApp - New directory
cvs commit: logging-log4net/examples/net/1.0/Layouts/SampleLayoutsApp/cs - New directory
nicko 2005/08/29 08:23:09 logging-log4net/examples/net/1.0/Layouts/SampleLayoutsApp/cs - New directory
cvs commit: logging-log4net/examples/net/1.0/Layouts/SampleLayoutsApp/cs/src/Layout - New directory
nicko 2005/08/29 08:23:52 logging-log4net/examples/net/1.0/Layouts/SampleLayoutsApp/cs/src/Layout - New directory
cvs commit: logging-log4net/xdocs/src/release example-apps.xml
nicko 2005/08/29 08:25:46
Modified:examples/net/1.0 cs-examples.sln
xdocs/src/release example-apps.xml
Added: examples/net/1.0/Layouts nant.build nant.config
examples/net/1.0/Layouts/SampleLayoutsApp nant.build
nant.config
examples/net/1.0/Layouts/SampleLayoutsApp/cs .cvsignore
nant.build nant.config
examples/net/1.0/Layouts/SampleLayoutsApp/cs/src .cvsignore
App.config AssemblyInfo.cs LoggingExample.cs
SampleLayoutsApp.csproj
examples/net/1.0/Layouts/SampleLayoutsApp/cs/src/Layout
ForwardingLayout.cs LineWrappingLayout.cs
Log:
Fix for LOG4NET-17. Added Layouts sample project with line wrapping layout
Revision ChangesPath
1.2 +12 -0 logging-log4net/examples/net/1.0/cs-examples.sln
Index: cs-examples.sln
===
RCS file: /home/cvs/logging-log4net/examples/net/1.0/cs-examples.sln,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- cs-examples.sln 28 Jan 2004 20:38:35 - 1.1
+++ cs-examples.sln 29 Aug 2005 15:25:45 - 1.2
@@ -21,6 +21,10 @@
EndProject
Project({FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}) = EventIDLogApp,
Extensibility\EventIDLogApp\cs\src\EventIDLogApp.csproj,
{B3DCF964-EAC8-46F2-AA11-151713141536}
EndProject
+Project({FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}) = SampleAppendersApp,
Appenders\SampleAppendersApp\cs\src\SampleAppendersApp.csproj,
{9E715F72-7F70-421B-A2BF-E9CB42F88F5C}
+EndProject
+Project({FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}) = SampleLayoutsApp,
Layouts\SampleLayoutsApp\cs\src\SampleLayoutsApp.csproj,
{CD7A8094-D383-46BC-A75D-9F65F746E24F}
+EndProject
Global
GlobalSection(SolutionConfiguration) = preSolution
ConfigName.0 = Debug
@@ -73,6 +77,14 @@
{B3DCF964-EAC8-46F2-AA11-151713141536}.Debug.Build.0 =
Debug|.NET
{B3DCF964-EAC8-46F2-AA11-151713141536}.Release.ActiveCfg =
Release|.NET
{B3DCF964-EAC8-46F2-AA11-151713141536}.Release.Build.0 =
Release|.NET
+ {9E715F72-7F70-421B-A2BF-E9CB42F88F5C}.Debug.ActiveCfg =
Debug|.NET
+ {9E715F72-7F70-421B-A2BF-E9CB42F88F5C}.Debug.Build.0 =
Debug|.NET
+ {9E715F72-7F70-421B-A2BF-E9CB42F88F5C}.Release.ActiveCfg =
Release|.NET
+ {9E715F72-7F70-421B-A2BF-E9CB42F88F5C}.Release.Build.0 =
Release|.NET
+ {CD7A8094-D383-46BC-A75D-9F65F746E24F}.Debug.ActiveCfg =
Debug|.NET
+ {CD7A8094-D383-46BC-A75D-9F65F746E24F}.Debug.Build.0 =
Debug|.NET
+ {CD7A8094-D383-46BC-A75D-9F65F746E24F}.Release.ActiveCfg =
Release|.NET
+ {CD7A8094-D383-46BC-A75D-9F65F746E24F}.Release.Build.0 =
Release|.NET
EndGlobalSection
GlobalSection(ExtensibilityGlobals) = postSolution
EndGlobalSection
1.1 logging-log4net/examples/net/1.0/Layouts/nant.build
Index: nant.build
===
?xml version=1.0 ?
!--
Copyright 2004-2005 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
--
project name=layout-examples default=compile
xmlnds=http://tempuri.org/nant-vs.xsd;
!-- compile Tutorials examples --
target name=compile description=Builds Layout examples
nant target=compile
buildfiles
include name=*/nant.build /
!-- exclude current build file --
exclude name=exclude.build /
/buildfiles
/nant
/target
/project
1.1 logging-log4net/examples/net/1.0/Layouts/nant.config
Index: nant.config
===
?xml version=1.0 ?
!--
Copyright 2004-2005 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is
[jira] Resolved: (LOG4NET-46) Support appenders that can output multiple events efficiently
[ http://issues.apache.org/jira/browse/LOG4NET-46?page=all ] Nicko Cadell resolved LOG4NET-46: - Fix Version: 1.2.10 Resolution: Fixed Checked in update that adds IBulkAppender interface. Added support to AppenderSkeleton base class and support in Appender subclasses that can take advantage of bulk appending. Updated AppenderAttachedImpl to pass on bulk arrays of events where possible. Support appenders that can output multiple events efficiently - Key: LOG4NET-46 URL: http://issues.apache.org/jira/browse/LOG4NET-46 Project: Log4net Type: New Feature Components: Appenders Versions: 1.2.9 Reporter: Nicko Cadell Assignee: Nicko Cadell Fix For: 1.2.10 Some appenders can efficiently output batches of events. Currently there is no way to pass a batch of events to an appender. Add an interface IBulkAppender that exposes a DoAppend method that takes an array of events. This interface can be supported by appenders that can process in bulk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (LOG4NET-10) Add %v pattern to output assembly version
[ http://issues.apache.org/jira/browse/LOG4NET-10?page=all ] Nicko Cadell updated LOG4NET-10: Description: n an environment where multiple versions of the same assembly is being used simultaneously by different applications, it's very useful to get the version of the assembly that is emiting the logging event. I'll add this right away. If you want the (rather trivial) code, I can post it. Daniel Cazzulino --- Well, the code is not trivial (to implement in a performant way), and our project is a little time-constrained. If I can, I'll try to make it, most probably in the LogManager.GetLogger method (the usage pattern indicates this will probably be a single static call per-class using logging)... I don't know. Daniel Cazzulino was: n an environment where multiple versions of the same assembly is being used simultaneously by different applications, it's very useful to get the version of the assembly that is emiting the logging event. I'll add this right away. If you want the (rather trivial) code, I can post it. Daniel Cazzulino --- Well, the code is not trivial (to implement in a performant way), and our project is a little time-constrained. If I can, I'll try to make it, most probably in the LogManager.GetLogger method (the usage pattern indicates this will probably be a single static call per-class using logging)... I don't know. Daniel Cazzulino Priority: Minor (was: Major) There seems to be low demand for this feature. Changing the priority to Minor. Add %v pattern to output assembly version - Key: LOG4NET-10 URL: http://issues.apache.org/jira/browse/LOG4NET-10 Project: Log4net Type: New Feature Components: Core Versions: 1.2.9 Environment: From sourceforege - 775175 - Daniel Cazzulino (kzu) - dcazzulino Reporter: Nicko Cadell Priority: Minor n an environment where multiple versions of the same assembly is being used simultaneously by different applications, it's very useful to get the version of the assembly that is emiting the logging event. I'll add this right away. If you want the (rather trivial) code, I can post it. Daniel Cazzulino --- Well, the code is not trivial (to implement in a performant way), and our project is a little time-constrained. If I can, I'll try to make it, most probably in the LogManager.GetLogger method (the usage pattern indicates this will probably be a single static call per-class using logging)... I don't know. Daniel Cazzulino -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (LOG4NET-12) Configuration GUI
[ http://issues.apache.org/jira/browse/LOG4NET-12?page=all ] Nicko Cadell updated LOG4NET-12: Description: I'd love to see a lightweight GUI that could be pointed at any application config file and could set up new/modify existing log4net settings. Granted it's all fine and well to edit the Xml by hand, but when you're rushed for time or just unsure of the correct syntax, it'd be real nice to have a little app you could fire up to help you out. Kevin Conroy was: I'd love to see a lightweight GUI that could be pointed at any application config file and could set up new/modify existing log4net settings. Granted it's all fine and well to edit the Xml by hand, but when you're rushed for time or just unsure of the correct syntax, it'd be real nice to have a little app you could fire up to help you out. Kevin Conroy Priority: Minor (was: Major) This issue is outside the current scope for log4net development. Changing the priority to Minor. Configuration GUI - Key: LOG4NET-12 URL: http://issues.apache.org/jira/browse/LOG4NET-12 Project: Log4net Type: New Feature Components: Other Versions: 1.2.9 Environment: From sourceforge - 761454 - Kevin Conroy - kmconroy Reporter: Nicko Cadell Priority: Minor I'd love to see a lightweight GUI that could be pointed at any application config file and could set up new/modify existing log4net settings. Granted it's all fine and well to edit the Xml by hand, but when you're rushed for time or just unsure of the correct syntax, it'd be real nice to have a little app you could fire up to help you out. Kevin Conroy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (LOG4NET-9) Programmatic configuration saving
[ http://issues.apache.org/jira/browse/LOG4NET-9?page=all ] Nicko Cadell updated LOG4NET-9: --- Description: 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 was: 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 Priority: Minor (was: Major) This issue is outside the current scope for log4net development. Changing the priority to Minor. Programmatic configuration saving - Key: LOG4NET-9 URL: http://issues.apache.org/jira/browse/LOG4NET-9 Project: Log4net Type: New Feature Components: Appenders, Core Environment: From sourceforge - 775738 - Daniel Cazzulino (kzu) - dcazzulino Reporter: Nicko Cadell Priority: Minor 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
cvs commit: logging-log4net/examples/net/1.0/Appenders/SampleAppendersApp/cs/src/Appender FastDbAppender.cs
nicko 2005/08/29 15:02:33
Modified:examples/net/1.0/Appenders/SampleAppendersApp/cs/src/Appender
FastDbAppender.cs
Log:
Updated FastDbAppender to support IBulkAppender, use connection pooling, and
allow the connection type and database schema to be overridden by a subclass
Revision ChangesPath
1.3 +133 -16
logging-log4net/examples/net/1.0/Appenders/SampleAppendersApp/cs/src/Appender/FastDbAppender.cs
Index: FastDbAppender.cs
===
RCS file:
/home/cvs/logging-log4net/examples/net/1.0/Appenders/SampleAppendersApp/cs/src/Appender/FastDbAppender.cs,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FastDbAppender.cs 15 Jun 2005 16:26:40 - 1.2
+++ FastDbAppender.cs 29 Aug 2005 22:02:33 - 1.3
@@ -16,6 +16,7 @@
//
#endregion
+using System.Data;
using System.Data.SqlClient;
using log4net.Appender;
using log4net.Core;
@@ -26,16 +27,29 @@
/// Simple database appender
/// /summary
/// remarks
+ /// para
/// This database appender is very simple and does not support a
configurable
/// data schema. The schema supported is hardcoded into the appender.
/// Also by not extending the AppenderSkeleton base class this appender
/// avoids the serializable locking that it enforces.
+ /// /para
+ /// para
+ /// This appender can be subclassed to change the database connection
+ /// type, or the database schema supported.
+ /// /para
+ /// para
+ /// To change the database connection type the see
cref=GetConnection/
+ /// method must be overridden.
+ /// /para
+ /// para
+ /// To change the database schema supported by the appender the see
cref=InitializeCommand/
+ /// and see cref=SetCommandValues/ methods must be overridden.
+ /// /para
/// /remarks
- public sealed class FastDbAppender : IAppender, IOptionHandler
+ public class FastDbAppender : IAppender, IBulkAppender, IOptionHandler
{
private string m_name;
private string m_connectionString;
- private SqlConnection m_dbConnection;
public string Name
{
@@ -49,32 +63,135 @@
set { m_connectionString = value; }
}
- public void ActivateOptions()
+ public virtual void ActivateOptions()
{
- m_dbConnection = new SqlConnection(m_connectionString);
- m_dbConnection.Open();
}
- public void Close()
+ public virtual void Close()
{
- if (m_dbConnection != null)
+ }
+
+ public virtual void DoAppend(LoggingEvent loggingEvent)
+ {
+ using(IDbConnection connection = GetConnection())
{
- m_dbConnection.Close();
+ // Open the connection for each event, this
takes advantage
+ // of the builtin connection pooling
+ connection.Open();
+
+ using(IDbCommand command =
connection.CreateCommand())
+ {
+ InitializeCommand(command);
+
+ SetCommandValues(command, loggingEvent);
+ command.ExecuteNonQuery();
+ }
}
}
- public void DoAppend(LoggingEvent loggingEvent)
+ public virtual void DoAppend(LoggingEvent[] loggingEvents)
{
- SqlCommand command = m_dbConnection.CreateCommand();
+ using(IDbConnection connection = GetConnection())
+ {
+ // Open the connection for each event, this
takes advantage
+ // of the builtin connection pooling
+ connection.Open();
+
+ using(IDbCommand command =
connection.CreateCommand())
+ {
+ InitializeCommand(command);
+
+ foreach(LoggingEvent loggingEvent in
loggingEvents)
+ {
+ SetCommandValues(command,
loggingEvent);
+ command.ExecuteNonQuery();
+ }
+
cvs commit: logging-log4net/src/Util CyclicBuffer.cs
nicko 2005/08/29 15:27:53
Modified:src/Appender BufferingAppenderSkeleton.cs
src/Util CyclicBuffer.cs
Log:
Fix for LOG4NET-11. Added a Flush(true) method that will flush the lossy
buffer
Revision ChangesPath
1.12 +85 -49logging-log4net/src/Appender/BufferingAppenderSkeleton.cs
Index: BufferingAppenderSkeleton.cs
===
RCS file:
/home/cvs/logging-log4net/src/Appender/BufferingAppenderSkeleton.cs,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- BufferingAppenderSkeleton.cs 29 Aug 2005 19:45:30 - 1.11
+++ BufferingAppenderSkeleton.cs 29 Aug 2005 22:27:53 - 1.12
@@ -274,20 +274,76 @@
/// /remarks
public virtual void Flush()
{
+ Flush(false);
+ }
+
+ /// summary
+ /// Flush the currently buffered events
+ /// /summary
+ /// param name=flushLossyBufferset to ctrue/c to flush
the buffer of lossy events/param
+ /// remarks
+ /// para
+ /// Flushes events that have been buffered. If paramref
name=flushLossyBuffer / is
+ /// cfalse/c then events will only be flushed if this
buffer is non-lossy mode.
+ /// /para
+ /// para
+ /// If the appender is buffering in see cref=Lossy/ mode
then the contents
+ /// of the buffer will only be flushed if paramref
name=flushLossyBuffer / is ctrue/c.
+ /// In this case the contents of the buffer will be tested
against the
+ /// see cref=LossyEvaluator/ and if triggering will be
output. All other buffered
+ /// events will be discarded.
+ /// /para
+ /// para
+ /// If paramref name=flushLossyBuffer / is ctrue/c then
the buffer will always
+ /// be emptied by calling this method.
+ /// /para
+ /// /remarks
+ public virtual void Flush(bool flushLossyBuffer)
+ {
// This method will be called outside of the
AppenderSkeleton DoAppend() method
// therefore it needs to be protected by its own lock.
This will block any
// Appends while the buffer is flushed.
lock(this)
{
- // Do nothing if the buffer does not exist, or
we are not configured
- // to buffer events, or if the buffer is full
of lossy events (the
- // evaluator should flush the buffer each time
a significant event arrives).
- // NOTE that there is an issue here with the
m_lossyEvaluator which
- // may trigger for some of the events in the
lossy buffer, which we should
- // really be checking for.
- if (m_cb != null m_bufferSize 1
!m_lossy)
+ if (m_cb != null m_cb.Length 0)
{
- SendFromBuffer(null, m_cb);
+ if (m_lossy)
+ {
+ // If we are allowed to eagerly
flush from the lossy buffer
+ if (flushLossyBuffer)
+ {
+ if (m_lossyEvaluator !=
null)
+ {
+ // Test the
contents of the buffer against the lossy evaluator
+ LoggingEvent[]
bufferedEvents = m_cb.PopAll();
+ ArrayList
filteredEvents = new ArrayList(bufferedEvents.Length);
+
+
foreach(LoggingEvent loggingEvent in bufferedEvents)
+ {
+ if
(m_lossyEvaluator.IsTriggeringEvent(loggingEvent))
+ {
+
filteredEvents.Add(loggingEvent);
+ }
+ }
+
+ //
[jira] Resolved: (LOG4NET-11) Add Flush command to API
[ http://issues.apache.org/jira/browse/LOG4NET-11?page=all ] Nicko Cadell resolved LOG4NET-11: - Fix Version: 1.2.10 Resolution: Fixed Assign To: Nicko Cadell Added Flush(true) method to BufferingAppenderSkeleton. This method forces the current buffer to be flushed to the output even if the appender is in lossy mode. To find the appender use the LogManager.GetRepository().GetAppenders() method, then for each BufferingAppenderSkeleton call Flush(true). Add Flush command to API Key: LOG4NET-11 URL: http://issues.apache.org/jira/browse/LOG4NET-11 Project: Log4net Type: New Feature Components: Core Versions: 1.2.9 Environment: From sourceforege - 764025 - Kevin Conroy - kmconroy Reporter: Nicko Cadell Assignee: Nicko Cadell Fix For: 1.2.10 While using Buffering is a wonderful way to help improve performance, I would like the ability to programatically tell the current ILog object to flush any buffers that exist on the appenders that I've been logging to so that I can get any messages that I've sent rather than waiting for the buffer to fill up. Thus, one might be able to do the following: log.Flush(); and then any messages sent to that ILog object would be processed. Kevin Conroy - kmconroy I vote for this one too! dcazzulino -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (LOG4NET-47) Add AsyncForwardingAppender
Add AsyncForwardingAppender --- Key: LOG4NET-47 URL: http://issues.apache.org/jira/browse/LOG4NET-47 Project: Log4net Type: New Feature Components: Appenders Versions: 1.2.9 Reporter: Nicko Cadell An AsyncForwardingAppender would be an appender that forwards to attached appender asynchrounously, i.e. using a seperate thread. There is a simple sample appender that does this in the SampleAppendersApp: examples\net\1.0\Appenders\SampleAppendersApp\cs\src\Appender\AsyncAppender.cs This appender uses a worker thread from the ThreadPool to forward the event. It may be necessary to do this differently as we may compete for thread pool resources and cause a deadlock. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (LOG4NET-16) Asynchronous email-sending with SMTPAppender
[ http://issues.apache.org/jira/browse/LOG4NET-16?page=all ] Nicko Cadell resolved LOG4NET-16: - Resolution: Duplicate Resolving issue as a duplicate of LOG4NET-47 Asynchronous email-sending with SMTPAppender Key: LOG4NET-16 URL: http://issues.apache.org/jira/browse/LOG4NET-16 Project: Log4net Type: Improvement Components: Appenders Environment: From sourceforge - 689368 Reporter: Nicko Cadell I would like to suggest that the SMTPAppender have a, perhaps optional, asynchronous methodology for sending email, so there would not be a pause in the application's main logical thread of execution when the digest of logging messages is ready to be sent. Perhaps a property could denote whether another thread sent the email asynchronously or not. Perhaps using the asynchronous approach could be configurable via the configuration file. I think the wait that occurs when the send operation is in the main thread is not desireable and can be quite considerable. If sending on another thread where supported, I believe it should be the default behaviour. regards, carl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (LOG4NET-13) Allow SMTPAppender to have replacable parameters in Subject
[ http://issues.apache.org/jira/browse/LOG4NET-13?page=all ] Nicko Cadell resolved LOG4NET-13: - Fix Version: 1.2.10 Resolution: Fixed There is an example appender in the SampleAppendersApp which sends a single event via SMTP email and allows replacable patterns in the email subject line. See: examples\net\1.0\Appenders\SampleAppendersApp\cs\src\Appender\SimpleSmtpAppender.cs Allow SMTPAppender to have replacable parameters in Subject --- Key: LOG4NET-13 URL: http://issues.apache.org/jira/browse/LOG4NET-13 Project: Log4net Type: Improvement Components: Appenders Versions: 1.2.9 Environment: From sourceforge - 749620 - Jeremy Wiebe - jeropa Reporter: Nicko Cadell Fix For: 1.2.10 It would be helpful to be able to have parameters that are replaced on a per-log event basis on the Subject line for the SMTPAppender. Example: I have multiple web servers running a .NET web service and all use log4net. When an error occurs, they use the SMTPAppender to notify me. It would be very useful to include the host name of the sender in the subject line so that I could easily determine which web server had an error instead of having to look into the email. In thinking more about this it could either be the Subject line or the From line that has replacable parameters. Perhaps even make it so that these properties can use the layout tag. Jeremy Wiebe - jeropa -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (LOG4NET-3) Support per event patterns in FileAppender File name
[ http://issues.apache.org/jira/browse/LOG4NET-3?page=all ] Nicko Cadell resolved LOG4NET-3: Fix Version: 1.2.10 Resolution: Fixed Assign To: Nicko Cadell The log4net.Util.PatternString type allows patterns to be specified in the FileAppender File property at configuration time. This can be used to allow multiple copies of the same application to log to separate log files. There is also an example appender in the SampleAppendersApp that allows event specific patterns to be used in the file name. The appender constructs the file name for each event using a PatternLayout, the file is opened and closed for each event. For more details see examples\net\1.0\Appenders\SampleAppendersApp\cs\src\Appender\PatternFileAppender.cs Support per event patterns in FileAppender File name Key: LOG4NET-3 URL: http://issues.apache.org/jira/browse/LOG4NET-3 Project: Log4net Type: Improvement Components: Appenders Versions: 1.2.9 Environment: From sourceforge: 812999 Reporter: Nicko Cadell Assignee: Nicko Cadell Fix For: 1.2.10 If I could specify file name patter for (Rolling)FileAppender that would be filled by the appender prior to openning the file, I could let many individuals run the same applikation (on terminal server) and still log to file (not RemotingAppender or ADONetAppernder) I guess, pattern like quot;rootLog%U.logquot; would do, if appender replaced %U with Thread.CurrentThread.CurrentPrincipal.Identity.Name ... Or %T with thread id and so on... Anonymous -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (LOG4NET-2) Configurator should report errors
[ http://issues.apache.org/jira/browse/LOG4NET-2?page=all ] Nicko Cadell updated LOG4NET-2: --- Fix Version: v.Next Description: I understand that you do not want to throw exceptions from within the logging methods, as a failure in log4net would make the hosting app fail. However, I think it is necessary that DOMConfigurator throws exceptions. If a failure occurs at that point, for example due to a malformed configuration file, I believe the hosting app would in most cases like to know. Even if it doesn't, it could easily just swallow any exceptions. In my case, I have a Windows Service app that will just quit logging if there is an error in the configuration file. That makes the logging mechanism rather more fragile than I would like. Tor Hovland - torhovl --- I completely agree. I suggest that you take an additional step and provide an additional mechanism, perhaps a ValidateLoggers() method which operates like a standard logging call, but is capable of throwing exceptions or providing another form of feedback which would allow the caller to diagnose bad configurations. The configuration file can be well-formed, but logging can still fail for any number of reasons. Most applications that provide a logging mechanism employ a 'start-up banner' log entry at an INFO level. This would be a great time to detect any problems with the logging system itself. I currently have a project deployed at a customer site and despite a well formed config file... no logging is taking place. I don't know why, and there does not seem to be a simple way to diagnose the problem. Ben Newman - benjamin91 was: I understand that you do not want to throw exceptions from within the logging methods, as a failure in log4net would make the hosting app fail. However, I think it is necessary that DOMConfigurator throws exceptions. If a failure occurs at that point, for example due to a malformed configuration file, I believe the hosting app would in most cases like to know. Even if it doesn't, it could easily just swallow any exceptions. In my case, I have a Windows Service app that will just quit logging if there is an error in the configuration file. That makes the logging mechanism rather more fragile than I would like. Tor Hovland - torhovl --- I completely agree. I suggest that you take an additional step and provide an additional mechanism, perhaps a ValidateLoggers() method which operates like a standard logging call, but is capable of throwing exceptions or providing another form of feedback which would allow the caller to diagnose bad configurations. The configuration file can be well-formed, but logging can still fail for any number of reasons. Most applications that provide a logging mechanism employ a 'start-up banner' log entry at an INFO level. This would be a great time to detect any problems with the logging system itself. I currently have a project deployed at a customer site and despite a well formed config file... no logging is taking place. I don't know why, and there does not seem to be a simple way to diagnose the problem. Ben Newman - benjamin91 Configurator should report errors - Key: LOG4NET-2 URL: http://issues.apache.org/jira/browse/LOG4NET-2 Project: Log4net Type: Improvement Components: Core Versions: 1.2.9 Environment: From sourceforege - Tor Hovland - torhovl Reporter: Nicko Cadell Fix For: v.Next I understand that you do not want to throw exceptions from within the logging methods, as a failure in log4net would make the hosting app fail. However, I think it is necessary that DOMConfigurator throws exceptions. If a failure occurs at that point, for example due to a malformed configuration file, I believe the hosting app would in most cases like to know. Even if it doesn't, it could easily just swallow any exceptions. In my case, I have a Windows Service app that will just quit logging if there is an error in the configuration file. That makes the logging mechanism rather more fragile than I would like. Tor Hovland - torhovl --- I completely agree. I suggest that you take an additional step and provide an additional mechanism, perhaps a ValidateLoggers() method which operates like a standard logging call, but is capable of throwing exceptions or providing another form of feedback which would allow the caller to diagnose bad configurations. The configuration file can be well-formed, but logging can still fail for any number of reasons. Most applications that provide a logging mechanism employ a 'start-up banner' log entry at an INFO level. This would be a great time to detect any problems with the logging system itself. I currently have a project deployed at a customer site and despite a well formed config file... no logging is taking place. I don't know why, and there does not seem to be a simple way to
[jira] Updated: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
[ http://issues.apache.org/jira/browse/LOG4NET-27?page=all ] Nicko Cadell updated LOG4NET-27: Fix Version: v.Next Description: A maximum of backup files exist when rolling files on file size, but not for rolling on date/time. This can be implemented with the same config key : MaxSizeRollBackups was: A maximum of backup files exist when rolling files on file size, but not for rolling on date/time. This can be implemented with the same config key : MaxSizeRollBackups Environment: Rolling files on date/time boundaries doesn't support a maximum number of backup files. --- Key: LOG4NET-27 URL: http://issues.apache.org/jira/browse/LOG4NET-27 Project: Log4net Type: New Feature Components: Appenders Reporter: Florian Ramillien Priority: Minor Fix For: v.Next Attachments: RollingFileAppender.cs.patch, RollingFileAppender.patch A maximum of backup files exist when rolling files on file size, but not for rolling on date/time. This can be implemented with the same config key : MaxSizeRollBackups -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
