anchor.diff:  
   All URI action command classes have to implement interface `org.roklib.urifragmentrouting.UriActionCommand`. This interface is derived from `java.lang.Runnable`, and it does not define any methods of its own. So, the one method we have to implement for action commands is  `run()`.
   
  -As we have seen in the beginning, when we build a URI action mapper tree, we provide the class objects of our URI action command classes as the commands for the particular action mappers. It is important to note that we cannot set concrete instances of our action command classes (which may have been instantiated with `new`) here. The reason for this is that a URI action mapper tree needs to remain thread-safe. If we were able to set concrete action command instances in this tree, these instances would be shared between different threads which would make the `UriActionMapperTree` inherently unsafe for usage in a multi-threaded scenario. Therefore, each URI fragment interpretation process has to run on its own private set of data. When a URI fragment is interpreted, a new action command object will be created at the end of this process by the action mapper tree if the URI fragment could be successfully resolved. This command object is then executed and afterwards passed back to the caller of the action mapper tree's `interpretFragment()` method. All this happens with data objects which are local to the current thread and which will not be shared with other threads.
  -
  -Since the action command objects are automatically instantiated by the URI action mapper tree, each action command class must have a public default constructor. If this condition is not met, an exception is thrown by the action mapper tree when it attempts to instantiate the action command.
  +As we have seen in the beginning, when we build a URI action mapper tree, we provide the action command factory objects for our URI action command classes to the particular action mappers. It is important to note that we cannot set concrete instances of our action command classes (which may have been instantiated with `new`) here. We must use the factory approach instead. The reason for this is that a URI action mapper tree needs to remain thread-safe. If we were able to set concrete action command instances in this tree, these instances would be shared between different threads which would make the `UriActionMapperTree` inherently unsafe for usage in a multi-threaded scenario. Therefore, each URI fragment interpretation process has to run on its own private set of data. When a URI fragment is interpreted, a new action command object will be created with a command factory at the end of this process by the action mapper tree if the URI fragment could be successfully resolved. This command object is then executed and afterwards passed back to the caller of the action mapper tree's `interpretFragment()` method. All this happens with data objects which are local to the current thread and which will not be shared with other threads.
   
   When an action command object is executed, the command will need some sort of context in most of the cases. This might be access to some application or session data, such as service references or user data. Additionally, an action command object needs to know the URI parameter values extracted from the current URI fragment. This type of context can be injected into an action command object by the action mapper tree. The next sections describe how this can be achieved.
   
  
positive.code: UriActionMapperTree mapperTree = UriActionMapperTree.create().buildMapperTree()
                  .mapSubtree("products").withSingleValuedParameter("id").forType(Integer.class).noDefault()
                      .onSubtree()
                      .map("details").onAction(ShowProductDetailsActionCommand.class).finishMapper()
                  .finishMapper()
                  .build();
  ----
  
  For this action mapper tree, we define one dispatching action mapper `products` and one simple action mapper `details`. For the first action mapper, we define a single-valued, Integer-typed parameter with parameter name `id`. Since `Integer` is a standard data type, we can use a builder for constructing the URI parameter with a fluent API.
  
  Note that we do not specify a URI action command class for the `products`-mapper. That's because we do not support visiting the `products` URI fragment on its own. A value for the `id` parameter is required in the URI fragment followed by the `details` path segment.
  
  Single-valued URI parameters for standard data types are built with the builder returned by the `withSingleValuedParameter()` method. We pass this method the parameter identifier we want to use for this parameter. Next we have to specify the parameter's data type with `forType()`. We pass this method the class object for the desired data type. Currently, the following data types are supported by this builder: `String`, `Integer`, `Long`, `Float`, `Double`, `Boolean`, `java.util.Date`, and `java.time.LocalDate`. If you pass a class object which is not supported, an `IllegalArgumentException` is thrown.
  
  
negative.code: [source,java]
  ----
  UriActionMapperTree mapperTree = UriActionMapperTree.create().buildMapperTree()
              .mapSubtree("user").onActionFactory(GoToUserAreaActionCommand::new)
                  .onSubtree()
                  .map("profile").onActionFactory(GoToUserProfileActionCommand::new).finishMapper()
              .finishMapper()
              .mapSubtree("admin").onActionFactory(GoToAdminAreaActionCommand::new)
                  .onSubtree()
                  .map("users").onActionFactory(GoToUserAdministrationActionCommand::new).finishMapper()
                  .map("groups").onActionFactory(GoToGroupAdministrationActionCommand::new).finishMapper()
              .finishMapper()
              .map("settings").onActionFactory(GoToSettingsActionCommand::new).finishMapper()
          .build();
  ----
  
  The `user` and `admin` path segments now need to have their type changed from a simple action mapper into a dispatching action mapper which allows adding sub-mappers. This is reflected by the builder methods we have to use now: `mapSubtree()` initiates the construction of a sub-mapper hierarchy. We can still assign an action command factory to this mapper. This factory will be used when the dispatching action mapper is directly accessed with a URI fragment, e. g. `#!user`.
  
  After the dispatching mapper has been fully configured, we can go to the next hierarchy level and configure the dispatching mapper's sub-mappers. We initiate the construction of this sub-tree with method `onSubtree()`. From this point on, we can continue with constructing the mapper tree on the next level as we did on the root level. As we can see, we are here dealing with a recursive structure. We can now use the same builders as we did on the root level. We can thus nest the action mappers as deeply as we like.
  
  