> ie,
> 1. Add a dependency from MyPlugin to log4j plugin
> 2. Register my plugin as a buddy for log4j plugin
> 3. Add my plugin to the logger map
>
> What is the significance of this strategy? Even if you use only the
> first step, ie, "add a dependency from MyPlugin to log4j plugin",
> still you can work with the log4j logger without any issues.

> Can you please explain the reason for such an implementation.

The reasons for this design are described here: http://
wiki.eclipse.org/Xtext_Project_Plan/Features/
Logging#Developer_Information, but let me briefly reiterate.
We wanted to have a transparent logging facility that works both in the
Xtext UI and in the Xtext backend. Additionally, we wanted to be able
to redirect all messages in levels WARN, ERROR and FATAL to the Eclipse
error log.

To achieve this, we did the following:
1) we created our own copy of Log4j that has "BuddyPolicy: registered"
set so it can see the classpath of all other bundles that register
themselves to our Log4J bundle. This is needed so that we can configure
Log4J using a properties file *inside our very own bundles*.
2) we created a Log4J appender
(org.eclipse.xtext.logging.EclipseLogAppender) that can write to the
Eclipse error log. This appender of course is only needed when you're
running inside Eclipse in UI mode.
3) Introduced a way to map class names to bundles (using the logger
map). This is needed since you cannot determine from which bundle a
logger call has been received. So we need to translate class names to
bundle names in our appender. This is actually only eye candy.