activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "james strachan (JIRA)" <j...@apache.org>
Subject [jira] Moved: (AMQNET-23) .Net client needs centralised trace facility
Date Tue, 27 Feb 2007 10:39:06 GMT

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

james strachan moved AMQ-974 to AMQNET-23:
------------------------------------------

        Fix Version/s:     (was: 4.1.0)
          Component/s:     (was: NMS (C# client))
    Affects Version/s:     (was: 4.0.2)
                  Key: AMQNET-23  (was: AMQ-974)
              Project: ActiveMQ .Net  (was: ActiveMQ)

> .Net client needs centralised trace facility
> --------------------------------------------
>
>                 Key: AMQNET-23
>                 URL: https://issues.apache.org/activemq/browse/AMQNET-23
>             Project: ActiveMQ .Net
>          Issue Type: New Feature
>         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.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message