You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by "Nicko Cadell (JIRA)" <ji...@apache.org> on 2005/03/01 00:21:50 UTC

[jira] Created: (LOG4NET-14) Allow custom default renderer

Allow custom default renderer
-----------------------------

         Key: LOG4NET-14
         URL: http://issues.apache.org/jira/browse/LOG4NET-14
     Project: Log4net
        Type: Improvement
  Components: Core  
    Versions: 1.2.9    
 Environment: From sourceforge - 732806 - krishna thotakura - tkkishore
    Reporter: Nicko Cadell


 I request for the following features/changes.

1. The ability to configure a DefaultRenderer.
I could not find a way to do this other than by modifying
RendererMap. The flexibility in having custom loggable
objects and custom renderes is lost. It also does not
allow me to take advantage of the single rooted
hierarchy of .NET. (i.e. i want to format all
objects - string log objects, int log objects, etc. in a
uniform way)

I had to make the following change in the RendererMap
class.

//private static IObjectRenderer s_defaultRenderer = new
DefaultRenderer();
private static IObjectRenderer s_defaultRenderer = new
MyDefaultRenderer();


2. The property &quot;RenderedMessage&quot; in
the &quot;LoggingEvent&quot; class should not contain any
rendering capabilities of its own. I would rely on my
custom renderer and my custom default renderer to do
all the rendering. This makes a clean dilineation of
responsibilities. I had to do comment out the lines
shown below

public string RenderedMessage
{
get
{
if (m_data.Message == null)
{
// if (m_message == null)
// {
// m_data.Message = &quot;&quot;;
// }
// else if (m_message is string)
// {
// m_data.Message = (m_message as string);
// }
// else
// {
m_data.Message
= m_repository.RendererMap.FindAndRender
(m_message);
// }
}
return m_data.Message;
}
}


Log4J is an excellent design product otherwise. I have
always admired its flexibility. We have successfully
used it in our java projects and are very pleased with its
performance, and capabilities.


I greatly appreciate your time in considering the above
suggestions. Please let me know what you think about
the above recommendations.

-Krishna.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


[jira] Resolved: (LOG4NET-14) Allow custom default renderer

Posted by "Nicko Cadell (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/LOG4NET-14?page=history ]
     
Nicko Cadell resolved LOG4NET-14:
---------------------------------

    Resolution: Won't Fix

it is not nessasary to allow the DefaultRenderer to be replaced as all the object rendering can be intercepted by adding a custom renderer for Object.

> Allow custom default renderer
> -----------------------------
>
>          Key: LOG4NET-14
>          URL: http://issues.apache.org/jira/browse/LOG4NET-14
>      Project: Log4net
>         Type: Improvement
>   Components: Core
>     Versions: 1.2.9
>  Environment: From sourceforge - 732806 - krishna thotakura - tkkishore
>     Reporter: Nicko Cadell

>
>  I request for the following features/changes.
> 1. The ability to configure a DefaultRenderer.
> I could not find a way to do this other than by modifying
> RendererMap. The flexibility in having custom loggable
> objects and custom renderes is lost. It also does not
> allow me to take advantage of the single rooted
> hierarchy of .NET. (i.e. i want to format all
> objects - string log objects, int log objects, etc. in a
> uniform way)
> I had to make the following change in the RendererMap
> class.
> //private static IObjectRenderer s_defaultRenderer = new
> DefaultRenderer();
> private static IObjectRenderer s_defaultRenderer = new
> MyDefaultRenderer();
> 2. The property &quot;RenderedMessage&quot; in
> the &quot;LoggingEvent&quot; class should not contain any
> rendering capabilities of its own. I would rely on my
> custom renderer and my custom default renderer to do
> all the rendering. This makes a clean dilineation of
> responsibilities. I had to do comment out the lines
> shown below
> public string RenderedMessage
> {
> get
> {
> if (m_data.Message == null)
> {
> // if (m_message == null)
> // {
> // m_data.Message = &quot;&quot;;
> // }
> // else if (m_message is string)
> // {
> // m_data.Message = (m_message as string);
> // }
> // else
> // {
> m_data.Message
> = m_repository.RendererMap.FindAndRender
> (m_message);
> // }
> }
> return m_data.Message;
> }
> }
> Log4J is an excellent design product otherwise. I have
> always admired its flexibility. We have successfully
> used it in our java projects and are very pleased with its
> performance, and capabilities.
> I greatly appreciate your time in considering the above
> suggestions. Please let me know what you think about
> the above recommendations.
> -Krishna.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


[jira] Commented: (LOG4NET-14) Allow custom default renderer

Posted by "Nicko Cadell (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/LOG4NET-14?page=comments#action_59909 ]
     
Nicko Cadell commented on LOG4NET-14:
-------------------------------------

As the RendererMap will search up the object's type hierarchy for a matching renderer it is possible to intercept all rendering by adding a custom renderer for Object. The .NET type hierarchy is single rooted, therefore this will match for all objects passed to the renderer.

The LoggingEvent shortcuts some of the rendering for performance reasons.

> Allow custom default renderer
> -----------------------------
>
>          Key: LOG4NET-14
>          URL: http://issues.apache.org/jira/browse/LOG4NET-14
>      Project: Log4net
>         Type: Improvement
>   Components: Core
>     Versions: 1.2.9
>  Environment: From sourceforge - 732806 - krishna thotakura - tkkishore
>     Reporter: Nicko Cadell

>
>  I request for the following features/changes.
> 1. The ability to configure a DefaultRenderer.
> I could not find a way to do this other than by modifying
> RendererMap. The flexibility in having custom loggable
> objects and custom renderes is lost. It also does not
> allow me to take advantage of the single rooted
> hierarchy of .NET. (i.e. i want to format all
> objects - string log objects, int log objects, etc. in a
> uniform way)
> I had to make the following change in the RendererMap
> class.
> //private static IObjectRenderer s_defaultRenderer = new
> DefaultRenderer();
> private static IObjectRenderer s_defaultRenderer = new
> MyDefaultRenderer();
> 2. The property &quot;RenderedMessage&quot; in
> the &quot;LoggingEvent&quot; class should not contain any
> rendering capabilities of its own. I would rely on my
> custom renderer and my custom default renderer to do
> all the rendering. This makes a clean dilineation of
> responsibilities. I had to do comment out the lines
> shown below
> public string RenderedMessage
> {
> get
> {
> if (m_data.Message == null)
> {
> // if (m_message == null)
> // {
> // m_data.Message = &quot;&quot;;
> // }
> // else if (m_message is string)
> // {
> // m_data.Message = (m_message as string);
> // }
> // else
> // {
> m_data.Message
> = m_repository.RendererMap.FindAndRender
> (m_message);
> // }
> }
> return m_data.Message;
> }
> }
> Log4J is an excellent design product otherwise. I have
> always admired its flexibility. We have successfully
> used it in our java projects and are very pleased with its
> performance, and capabilities.
> I greatly appreciate your time in considering the above
> suggestions. Please let me know what you think about
> the above recommendations.
> -Krishna.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira