LoggingEvent.cs contains this code:
public string RenderedMessage
{
get
{
if (m_data.Message == null)
{
if (m_message == null)
{
m_data.Message = "";
}
else if (m_message is string)
{
m_data.Message = (m_message as string);
}
else if (m_repository != null)
}
The renderer is used to convert the m_message object into a string only
if it is not already a string.
We could remove the early test for string, this could then be done by
the default renderer allowing it to be customised by the user. However
the performance gain of doing the early test benefits
I doubt many users need to customize how string messages are rendered.
Regarding this line:
else if (m_repository != null)
When will a repository be null? The second line in log4net's internal
log always seems to be:
log4net: DefaultRepositorySelector: defaultRepositoryType
[log4net.Reposito
I don't know why I didn't think of this sooner...if you have groups of
related converters that you'd like to register the amount of additional
xml nodes makes for some ugly xml:
A cleaner alternative is to group related converters into a layout:
public class AspNetPattern
> I doubt many users need to customize how string messages are
> rendered.
It is not a feature that is often requested. But it exists and we
support it.
Adding a custom renderer to the log4net configuration has another
disadvantage in that it leads to a tighter coupling between the
applicati
The documentation on the website for the renderer node doesn't mention
if it was possible to specify a renderer for an interface. In
RendererMap.cs there is a SearchTypeAndInterfaces method that looks
like it searches through an object's (type's ???) interfaces if the
type of the object doesn't hav
> The documentation on the website for the renderer node
> doesn't mention if it was possible to specify a renderer for
> an interface. In RendererMap.cs there is a
> SearchTypeAndInterfaces method that looks like it searches
> through an object's (type's ???) interfaces if the type of
> the
Building a layout that subclasses PatternLayout and adds support for
additional patterns does simplify the config file. This is most useful
when the additional patterns form a useful grouping of functionality, as
in the case of your ASP.NET patterns.
As you have to ship a dll containing the custom
Gee thanks Ron!
Its working absolutely fine now...
All i needed to do was add the XMLConfigureAndWatch method call...
All the other stuff was preety much in place.
Thanks,
Piyush
On 9/9/05, Ron Grabowski <[EMAIL PROTECTED]> wrote:
> I think more people could help you if you post questions like
