anchor.diff:  } 
   ----
   
  -There is more code than Groovy code because +GroovyScriptEngine+ setting up was omitted (not specific of RelProxy) and now some configuration options are shown in spite of they 
  +There is more code than Groovy code because `GroovyScriptEngine` setting up was omitted (not specific of RelProxy) and now some configuration options are shown in spite of they 
   may be optional.
   
   Let's explain the previous code:
  
positive.code: ((JProxyScriptEngine)engine).stop(); // Necessary if scanPeriod > 0 was defined
  ----
  
  Shows that returned +ScriptEngine+ implements +JProxyScriptEngine+, this interface defines the same methods you are going to find in +JProxy+, for instance
  the +stop()+ method is necessary whether you define a +scanPeriod+ and you want to dispose the +ScriptEngine+ (otherwise the +ScriptEngine+ is looking for
  source changes forever). 
  
  As said before two +ScriptEngine+ objects created using the same factory, just share the same configuration but they are different instances, for instance,
  the +stop()+ method just affect to the concrete instance used to call.
  
  You can directly call the +JProxyScriptEngineFactory.getScriptEngine()+ method without registering on a +ScriptEngineManager+, in this case avoid calling 
  +ServiceContext.getBindings(javax.script.ScriptContext.GLOBAL_SCOPE)+ use because the default global scope +Bindings+ object is not defined. In fact the method
  +ScriptEngineManager.getEngineByName(String)+ calls +JProxyScriptEngineFactory.getScriptEngine()+ and may return null if the +JProxyScriptEngineFactory.getScriptEngine()+ 
  method throws an exception for instance when some configuration data is wrong, because there is no log info of this exception you have no way to know what is happening, in 
  this case directly call +JProxyScriptEngineFactory.getScriptEngine()+ to know what is happening.
  
  If you need two or more different configurations, create one +JProxyScriptEngineFactory+ per configuration, use them standalone or create several +ScriptEngineManager+ instances.
  
  The scripting code can be the content of a +main+ method with this signature:
  
  [source,java]
  ----
  public static Object main(javax.script.ScriptEngine engine,javax.script.ScriptContext context)
  ----
  
  Or optionally you can define a complete Java class containing the previous +main+ method and name +_jproxyMainClass_+, for instance:
  
  [source,java]
  ----
  
negative.code: of RelProxy but other type of Java applications, for instance desktop, could be used.
  
  RelProxy can be used in development only and/or in production, in the case of production, source code going to be reloaded is included into the war file (recommended of course
  under `WEB-INF/`), you can modify the Java source file directly in production and automatically changes are detected, recompiled in memory and reloaded when needed, no .class
  change is needed, by this way you get the similar experience when you change the source code in production of a PHP, Ruby, JSP etc files without the need of restarting
  the application. If you do not want use RelProxy in production just disable it, the performance penalty is zero.
  
  RelProxy also can be used in development only acccesing directly to your source files in `/src` folder (multiple source folders are allowed) with no need of uploading source code to
  production.
  
  RelProxy is an alternative to context reloading, if your application is small and you feel comfortable with context reloading you do not need the class reloading features of RelProxy
  