You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Rob Lugt (JIRA)" <ji...@apache.org> on 2006/10/12 15:39:17 UTC
[jira] Created: (AMQ-974) .Net client needs centralised trace
facility
.Net client needs centralised trace facility
--------------------------------------------
Key: AMQ-974
URL: https://issues.apache.org/activemq/browse/AMQ-974
Project: ActiveMQ
Issue Type: New Feature
Components: NMS (C# client)
Affects Versions: 4.0.2
Environment: Windows
Reporter: Rob Lugt
There are several classes within activemq-dotnet which need to write log/trace information. This data is currently written to an ad-hoc mixture of the Console and System.Diagnostics.Trace.
Neither of these detinations are suitable because System.Diagnostics.Trace is not fully supported in the .Net compact framework and the Console is unsuitable for severl reasons - not least of which is that output is discarded in a Windows (i.e. non-console) application.
There are two possible solutions to this problem
1) adopt log4net as the strategic logging/tracing platform
2) write our own Tracing interface which can be controlled at run-time to make use of any logging mechanism.
Log4net is an attractive proposition because it is powerful, full-featured, reliable and is also an Apache incubator project. However, there is a strong desire to keep activemq-dotnet as clear as possible from any external dependencies. So far this has been successfull and as there is an alternative solution perhaps we should not create a dependency now.
Creating a custom Tracing interface is attractive because it is stand-alone and allows the client application to plug-in whichever trace mechanism it requires. There don't seem to be many down sides to this solution, so I'll post a sample impementation shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (AMQ-974) .Net client needs centralised trace
facility
Posted by "Rob Lugt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-974?page=all ]
Rob Lugt reopened AMQ-974:
--------------------------
small modification required to Connection.cs
protected void OnException(ITransport sender, Exception exception)
{
Tracer.ErrorFormat("Transport Exception: {0}", exception.ToString());
}
> .Net client needs centralised trace facility
> --------------------------------------------
>
> Key: AMQ-974
> URL: https://issues.apache.org/activemq/browse/AMQ-974
> Project: ActiveMQ
> Issue Type: New Feature
> Components: NMS (C# client)
> Affects Versions: 4.0.2
> Environment: Windows
> Reporter: Rob Lugt
> Assigned To: james strachan
> Fix For: 4.1
>
> Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs
>
>
> There are several classes within activemq-dotnet which need to write log/trace information. This data is currently written to an ad-hoc mixture of the Console and System.Diagnostics.Trace.
> Neither of these detinations are suitable because System.Diagnostics.Trace is not fully supported in the .Net compact framework and the Console is unsuitable for severl reasons - not least of which is that output is discarded in a Windows (i.e. non-console) application.
> There are two possible solutions to this problem
> 1) adopt log4net as the strategic logging/tracing platform
> 2) write our own Tracing interface which can be controlled at run-time to make use of any logging mechanism.
> Log4net is an attractive proposition because it is powerful, full-featured, reliable and is also an Apache incubator project. However, there is a strong desire to keep activemq-dotnet as clear as possible from any external dependencies. So far this has been successfull and as there is an alternative solution perhaps we should not create a dependency now.
> Creating a custom Tracing interface is attractive because it is stand-alone and allows the client application to plug-in whichever trace mechanism it requires. There don't seem to be many down sides to this solution, so I'll post a sample impementation shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-974) .Net client needs centralised trace
facility
Posted by "james strachan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-974?page=all ]
james strachan resolved AMQ-974.
--------------------------------
Resolution: Fixed
Patch applied, thanks again!
> .Net client needs centralised trace facility
> --------------------------------------------
>
> Key: AMQ-974
> URL: https://issues.apache.org/activemq/browse/AMQ-974
> Project: ActiveMQ
> Issue Type: New Feature
> Components: NMS (C# client)
> Affects Versions: 4.0.2
> Environment: Windows
> Reporter: Rob Lugt
> Assigned To: james strachan
> Fix For: 4.1
>
> Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs
>
>
> There are several classes within activemq-dotnet which need to write log/trace information. This data is currently written to an ad-hoc mixture of the Console and System.Diagnostics.Trace.
> Neither of these detinations are suitable because System.Diagnostics.Trace is not fully supported in the .Net compact framework and the Console is unsuitable for severl reasons - not least of which is that output is discarded in a Windows (i.e. non-console) application.
> There are two possible solutions to this problem
> 1) adopt log4net as the strategic logging/tracing platform
> 2) write our own Tracing interface which can be controlled at run-time to make use of any logging mechanism.
> Log4net is an attractive proposition because it is powerful, full-featured, reliable and is also an Apache incubator project. However, there is a strong desire to keep activemq-dotnet as clear as possible from any external dependencies. So far this has been successfull and as there is an alternative solution perhaps we should not create a dependency now.
> Creating a custom Tracing interface is attractive because it is stand-alone and allows the client application to plug-in whichever trace mechanism it requires. There don't seem to be many down sides to this solution, so I'll post a sample impementation shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-974) .Net client needs centralised trace
facility
Posted by "james strachan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-974?page=all ]
james strachan reassigned AMQ-974:
----------------------------------
Assignee: james strachan
> .Net client needs centralised trace facility
> --------------------------------------------
>
> Key: AMQ-974
> URL: https://issues.apache.org/activemq/browse/AMQ-974
> Project: ActiveMQ
> Issue Type: New Feature
> Components: NMS (C# client)
> Affects Versions: 4.0.2
> Environment: Windows
> Reporter: Rob Lugt
> Assigned To: james strachan
> Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs
>
>
> There are several classes within activemq-dotnet which need to write log/trace information. This data is currently written to an ad-hoc mixture of the Console and System.Diagnostics.Trace.
> Neither of these detinations are suitable because System.Diagnostics.Trace is not fully supported in the .Net compact framework and the Console is unsuitable for severl reasons - not least of which is that output is discarded in a Windows (i.e. non-console) application.
> There are two possible solutions to this problem
> 1) adopt log4net as the strategic logging/tracing platform
> 2) write our own Tracing interface which can be controlled at run-time to make use of any logging mechanism.
> Log4net is an attractive proposition because it is powerful, full-featured, reliable and is also an Apache incubator project. However, there is a strong desire to keep activemq-dotnet as clear as possible from any external dependencies. So far this has been successfull and as there is an alternative solution perhaps we should not create a dependency now.
> Creating a custom Tracing interface is attractive because it is stand-alone and allows the client application to plug-in whichever trace mechanism it requires. There don't seem to be many down sides to this solution, so I'll post a sample impementation shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-974) .Net client needs centralised trace
facility
Posted by "Rob Lugt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-974?page=all ]
Rob Lugt updated AMQ-974:
-------------------------
Attachment: Tracer.cs
> .Net client needs centralised trace facility
> --------------------------------------------
>
> Key: AMQ-974
> URL: https://issues.apache.org/activemq/browse/AMQ-974
> Project: ActiveMQ
> Issue Type: New Feature
> Components: NMS (C# client)
> Affects Versions: 4.0.2
> Environment: Windows
> Reporter: Rob Lugt
> Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs
>
>
> There are several classes within activemq-dotnet which need to write log/trace information. This data is currently written to an ad-hoc mixture of the Console and System.Diagnostics.Trace.
> Neither of these detinations are suitable because System.Diagnostics.Trace is not fully supported in the .Net compact framework and the Console is unsuitable for severl reasons - not least of which is that output is discarded in a Windows (i.e. non-console) application.
> There are two possible solutions to this problem
> 1) adopt log4net as the strategic logging/tracing platform
> 2) write our own Tracing interface which can be controlled at run-time to make use of any logging mechanism.
> Log4net is an attractive proposition because it is powerful, full-featured, reliable and is also an Apache incubator project. However, there is a strong desire to keep activemq-dotnet as clear as possible from any external dependencies. So far this has been successfull and as there is an alternative solution perhaps we should not create a dependency now.
> Creating a custom Tracing interface is attractive because it is stand-alone and allows the client application to plug-in whichever trace mechanism it requires. There don't seem to be many down sides to this solution, so I'll post a sample impementation shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-974) .Net client needs centralised trace
facility
Posted by "Rob Lugt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-974?page=all ]
Rob Lugt updated AMQ-974:
-------------------------
Attachment: ITrace.cs
> .Net client needs centralised trace facility
> --------------------------------------------
>
> Key: AMQ-974
> URL: https://issues.apache.org/activemq/browse/AMQ-974
> Project: ActiveMQ
> Issue Type: New Feature
> Components: NMS (C# client)
> Affects Versions: 4.0.2
> Environment: Windows
> Reporter: Rob Lugt
> Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs
>
>
> There are several classes within activemq-dotnet which need to write log/trace information. This data is currently written to an ad-hoc mixture of the Console and System.Diagnostics.Trace.
> Neither of these detinations are suitable because System.Diagnostics.Trace is not fully supported in the .Net compact framework and the Console is unsuitable for severl reasons - not least of which is that output is discarded in a Windows (i.e. non-console) application.
> There are two possible solutions to this problem
> 1) adopt log4net as the strategic logging/tracing platform
> 2) write our own Tracing interface which can be controlled at run-time to make use of any logging mechanism.
> Log4net is an attractive proposition because it is powerful, full-featured, reliable and is also an Apache incubator project. However, there is a strong desire to keep activemq-dotnet as clear as possible from any external dependencies. So far this has been successfull and as there is an alternative solution perhaps we should not create a dependency now.
> Creating a custom Tracing interface is attractive because it is stand-alone and allows the client application to plug-in whichever trace mechanism it requires. There don't seem to be many down sides to this solution, so I'll post a sample impementation shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-974) .Net client needs centralised trace
facility
Posted by "Rob Lugt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-974?page=comments#action_37214 ]
Rob Lugt commented on AMQ-974:
------------------------------
I found an error in OnException in Connection.cs. This should be:-
protected void OnException(ITransport sender, Exception exception)
{
Tracer.ErrorFormat("Transport Exception: {0}", exception.ToString());
}
> .Net client needs centralised trace facility
> --------------------------------------------
>
> Key: AMQ-974
> URL: https://issues.apache.org/activemq/browse/AMQ-974
> Project: ActiveMQ
> Issue Type: New Feature
> Components: NMS (C# client)
> Affects Versions: 4.0.2
> Environment: Windows
> Reporter: Rob Lugt
> Assigned To: james strachan
> Fix For: 4.1
>
> Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs
>
>
> There are several classes within activemq-dotnet which need to write log/trace information. This data is currently written to an ad-hoc mixture of the Console and System.Diagnostics.Trace.
> Neither of these detinations are suitable because System.Diagnostics.Trace is not fully supported in the .Net compact framework and the Console is unsuitable for severl reasons - not least of which is that output is discarded in a Windows (i.e. non-console) application.
> There are two possible solutions to this problem
> 1) adopt log4net as the strategic logging/tracing platform
> 2) write our own Tracing interface which can be controlled at run-time to make use of any logging mechanism.
> Log4net is an attractive proposition because it is powerful, full-featured, reliable and is also an Apache incubator project. However, there is a strong desire to keep activemq-dotnet as clear as possible from any external dependencies. So far this has been successfull and as there is an alternative solution perhaps we should not create a dependency now.
> Creating a custom Tracing interface is attractive because it is stand-alone and allows the client application to plug-in whichever trace mechanism it requires. There don't seem to be many down sides to this solution, so I'll post a sample impementation shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-974) .Net client needs centralised trace
facility
Posted by "james strachan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-974?page=all ]
james strachan resolved AMQ-974.
--------------------------------
Fix Version/s: 4.1
Resolution: Fixed
Patch applied - many thanks!
> .Net client needs centralised trace facility
> --------------------------------------------
>
> Key: AMQ-974
> URL: https://issues.apache.org/activemq/browse/AMQ-974
> Project: ActiveMQ
> Issue Type: New Feature
> Components: NMS (C# client)
> Affects Versions: 4.0.2
> Environment: Windows
> Reporter: Rob Lugt
> Assigned To: james strachan
> Fix For: 4.1
>
> Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs
>
>
> There are several classes within activemq-dotnet which need to write log/trace information. This data is currently written to an ad-hoc mixture of the Console and System.Diagnostics.Trace.
> Neither of these detinations are suitable because System.Diagnostics.Trace is not fully supported in the .Net compact framework and the Console is unsuitable for severl reasons - not least of which is that output is discarded in a Windows (i.e. non-console) application.
> There are two possible solutions to this problem
> 1) adopt log4net as the strategic logging/tracing platform
> 2) write our own Tracing interface which can be controlled at run-time to make use of any logging mechanism.
> Log4net is an attractive proposition because it is powerful, full-featured, reliable and is also an Apache incubator project. However, there is a strong desire to keep activemq-dotnet as clear as possible from any external dependencies. So far this has been successfull and as there is an alternative solution perhaps we should not create a dependency now.
> Creating a custom Tracing interface is attractive because it is stand-alone and allows the client application to plug-in whichever trace mechanism it requires. There don't seem to be many down sides to this solution, so I'll post a sample impementation shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-974) .Net client needs centralised trace
facility
Posted by "Rob Lugt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-974?page=all ]
Rob Lugt updated AMQ-974:
-------------------------
Attachment: amq974-patch.txt
Patch to replace Console.WriteLine and System.Diagnostics.Trace with call to common Tracer class (attached as separate file)
> .Net client needs centralised trace facility
> --------------------------------------------
>
> Key: AMQ-974
> URL: https://issues.apache.org/activemq/browse/AMQ-974
> Project: ActiveMQ
> Issue Type: New Feature
> Components: NMS (C# client)
> Affects Versions: 4.0.2
> Environment: Windows
> Reporter: Rob Lugt
> Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs
>
>
> There are several classes within activemq-dotnet which need to write log/trace information. This data is currently written to an ad-hoc mixture of the Console and System.Diagnostics.Trace.
> Neither of these detinations are suitable because System.Diagnostics.Trace is not fully supported in the .Net compact framework and the Console is unsuitable for severl reasons - not least of which is that output is discarded in a Windows (i.e. non-console) application.
> There are two possible solutions to this problem
> 1) adopt log4net as the strategic logging/tracing platform
> 2) write our own Tracing interface which can be controlled at run-time to make use of any logging mechanism.
> Log4net is an attractive proposition because it is powerful, full-featured, reliable and is also an Apache incubator project. However, there is a strong desire to keep activemq-dotnet as clear as possible from any external dependencies. So far this has been successfull and as there is an alternative solution perhaps we should not create a dependency now.
> Creating a custom Tracing interface is attractive because it is stand-alone and allows the client application to plug-in whichever trace mechanism it requires. There don't seem to be many down sides to this solution, so I'll post a sample impementation shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira