anchor.diff:  
     private Configuration config = ConfigurationProvider.getConfiguration();
   
  -  public void onConfigEvent(ConfigurationChange event){
  -     if(event.getConfiguration()==config){
  -       // do something
  +  public void onConfigEvent(ConfigEvent<?> event){
  +     if(event.getResourceTspe()==Configuration.class){
  +         if(event.getConfiguration()==config){
  +           // do something
  +         }
        }
     }
   
  
positive.code: 
  You can *register* your implementation in 2 ways:
  
  . Manually by calling +ConfigEvent.addListener(new MyConfigChangeListener())+
  . Automatically by registering your listener using the +ServiceLoader+ under
    +META-INF/services/org.apache.tamaya.ConfigEventListener+
  
  === Modelling PropertySource Changes
  
  Beside that a whole configuration changes, also +PropertySource+ instance can change, e.g. by a configuration file
  edited on the fly. This is similarly to +ConfigurationChange+ reflected by the classes +PropertySourceChange,
  PropertySourceChangeBuilder+.
  
  === Modelling Configuration Context Changes
  
  
negative.code: Similar to the +ConfigurationChange+ class you also must use a +ConfigurationContextChangeBuilder+ to create instances
  of +ConfigurationContextChange+.
  
  === The ConfigEventManager Singleton
  
  Main entry point of the events module is the +ConfigEventManager+ singleton class, which provides static accessor
  methods to the extension's functionality:
  
  [source,java]
  -------------------------------------------------------
  public final class ConfigEventManager {
  
      private ConfigEventManager() {}
  
      public static void addListener(ConfigEventListener l);
      public static <T extends ConfigEvent> void addListener(ConfigEventListener l, Class<T> eventType);
      public static void removeListener(ConfigEventListener l);
      public static <T extends ConfigEvent> void removeListener(ConfigEventListener l, Class<T> eventType);
      public static <T extends ConfigEvent>
          Collection<? extends ConfigEventListener> getListeners();
      public static <T extends ConfigEvent>
          Collection<? extends ConfigEventListener> getListeners(Class<T> type);
  
      public static <T> void fireEvent(ConfigEvent<?> event);
      public static <T> void fireEventAsynch(ConfigEvent<?> event);
  
      public static void enableChangeMonitoring(boolean enable);
      public static boolean isChangeMonitoring();
      public long getChangeMonitoringPeriod();
      public void setChangeMonitoringPeriod(long millis);
  
  }
  -------------------------------------------------------
  
  Looking at the methods listed above you see that there is more functionality worth to be mentioned:
  
  * +ConfigCHangeListeners+ can be registered either _globally_ or for a certain _event type_ only.
  * +ConfigEvents+ can be published within the same thread, or asynchronously.
  
  
  ==== Monitoring of configuration changes
  
  The +ConfigEventManager+ also supports active monitoring of the current configuration to trigger corresponding change
  events to listeners registered. This feature is activated by default, but can be deactivated optionally. Nevertheless
  this feature is quite handy, since regularly polling your local +Configuration+ for any kind of changes is much
  more simpler than implementing change management on the +PropertySource+ level. With this feature you can easily
  implement also remote property source, which can deliver different configuration based on any changes done remotedly
  on another node in your system. If such a change happened Tamaya identifies it and triggers corresponding
  +ConfigurationChange" events automatically. Similarly changes in a configuration tree, can actively identified and
  broadcasted to the targeting nodes automatically.
  
  
  === Freezing Configurations and PropertySources
  
  +Configuration+ instances as well as +PropertySources+ are explicitly not required to be serializable. To enable easy
  serialization of these types as well as to fix a current state (e.g. for later comparison with a newly loaded instance)
  Tamaya allows to *freeze* instances of these types. Freezing hereby means
  
  * all key/values are read-out by calling the +getProperties()+ method.
  * a meta data entry is added of the form +[meta]frozenAt=223273777652325677+, whichdefines the UTC timestamp in
    milliseconds when this instance was frozen.
  
  In code this is done easily as follows:
  
  [source,java]
  .Freezing the current Configuration
  --------------------------------------------------
  Configuration frozenConfig = FrozenConfiguration.of(ConfigurationProvider.getConfiguration());
  --------------------------------------------------
  
  ... and similarly for a +PropertySource+:
  
  [source,java]
  .Freezing the current Configuration
  --------------------------------------------------
  PropertySource frozenSource = FrozenPropertySource.of(ConfigurationProvider.getConfiguration());
  --------------------------------------------------
  
  
  === Modelling of an observing PropertySourceProvider.
  
  In Tamaya configuration data is provided by instances of +PropertySource+, which in case of a configuration directory
  may be provided by an implementation of +PropertySourceProvider+, which produces one +PropertySource+ (at least) per
  file detected. The events module provides a base provider implementation that
  
  * observes all changes in a +Path+
  * tries to reevaluate corresponding resources based on the +ConfigurationFormats+ supported.
  * it creates an instance of +ConfigurationContextChange+ reflecting the changed +ConfigurationContext+ and triggers
    this event by calling +ConfigEventManager.fireEvent(contextChange);+.
  
  Additionally this module registers an instance of +ConfigEventListener<ConfigurationContextChange+>+, which listenes to
  these events. If such an event is triggered the listener tries to apply the changes by
  