[Myfaces Wiki] Update of "Extensions/Scripting/UsageGuide" by WernerPunz

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The "Extensions/Scripting/UsageGuide" page has been changed by WernerPunz.
http://wiki.apache.org/myfaces/Extensions/Scripting/UsageGuide?action=diff&rev1=5&rev2=6

--------------------------------------------------

  For now we cannot recommend to use '''Ext-Scripting''' in a production environment for live patches, although it theoretically would be possible and spent a lot of blood sweat and tears into making the system tolerable under multithread conditions for now we simply only can recommend to use '''Ext-Scripting''' for development and development only szenarios if you need to hot patch code (deployment without any changes however should be fine). So if you want to hot patch a running installations, we assume it should work fine, but you are on your own.
  
  == Behavior and Usage ==
- Using '''Ext-Scripting''' once properly setup is straight forward. Usually it comes down to editing, reloading on the browser editing, reloading the page, .... However if you edit within a running configurations keep an eye on the output all compile errors and refreshes go automatically into the log, so tracking down errors is easier by trying to keep an watchful eye on the log / console output.
+ Using '''Ext-Scripting''' once properly setup is straight forward. Usually it comes down to editing, reloading on the browser editing, reloading the page, .... However if you edit within a running configurations keep an eye on the console/log output. All compile errors and messages go automatically into the log.
  
  == Debugging ==
- '''Ext-Scripting''' automatically compiles with the debug flags on, Debugging onto a running configuration should be no problem. If the debugger can be pointed towards the sources, debugging should work without any sideffects, since the debugger can pick up the debug info from the newly compiled class files. (Note - the classfiles are not altered in any way so in any case you just deal with normal Java classes)
+ '''Ext-Scripting''' automatically compiles with the debug flags on. Debugging against a running configuration should be no problem. If the debugger can be pointed towards the sources, debugging should work without any sideffects, due to the fact that the debugger can pick up the debug info from the newly compiled class files. (Note - the classfiles are not altered in any way so in any case you just deal with normal Java classes)
  
  == Supported artifacts ==
  Ext-Scripting supports following JSF 1.2 artifact reloading:
@@ -53, +53 @@

   * BehaviorRenderer
   * Not yet supported event handlers for system events.
  
- (Has to be implemented)
+ Following diagram shows the structure and what is supported in the various modules of '''Ext-Scripting.'''
  
+  . ''' {{http://people.apache.org/%7Ewerpu/images/ext%2Dscripting%2Dstructure%2Dfine.jpg||height="742px",width="845px"}} '''
+ 
- == Problems and Considerations ==
+ == Problems and Behavior ==
  Everyone who uses hot plugging systems in Java has to live with the limitations the Java VM imposes to a certain extent. The VM imposes a statically typed programming model and allows hot code replace under certain limitations which do not compromise the structural integrity of a running system.
  
  We cannot lift those restrictions, other ones do not as well, but they try to bypass the limitations under the hood by adding simulation code to dynamic typing or adding proxies underneath the system which allow for more freedom in hot code plugging.
@@ -76, +78 @@

  
   * First of all, the JSF Extension Points now have reloading proxies instead of their default implementation. So any cast against a default implementation of an extension point which does not cast against the generic base classes or interfaces is bound to   fail
  
-  * Seconly although '''Ext-Scripting''' goes great lengths to avoid it, there are certain situations where a classcast exceptions
-  on a class of the same name might occur (it should not but there are system configurations where it still can happen) In this case if the error cannot resolve itself a server restart unfortunately is mandatory. Those corner situations are the 5 - 10% corner cases, where the system cannot be perfect.
+  * Seconly although '''Ext-Scripting''' goes great lengths to avoid it, there are certain situations where a classcast exceptions on a class of the same name might occur (it should not but there are system configurations where it still can happen) In this case if the error cannot resolve itself a server restart unfortunately is mandatory. Those corner situations are the 5 - 10% corner cases, where the system cannot be perfect.
  
   * In certain situations bean or generally artifact reloading can happen of artifacts which have not been touched, this is caused by the dependency scanner, which tries to keep the system in a reliable state dependencywise. So for instance if you just touch a request scoped bean, some application scoped or session scoped beans which import the bean or cast them on codelevel might be refreshed as well due to their intra code dependencies.  The same for instance happens with a renderer which might cast a component if the components code is touched!