myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Myfaces Wiki] Update of "Extensions/Scripting/UsageGuide" by WernerPunz
Date Thu, 31 Dec 2009 16:08:49 GMT
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=2&rev2=3

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

- = '''MyFaces''' '''Ext-Scripting''' User Guide =
+ = MyFaces Ext-Scripting User Guide =
  
  == Foreword ==
  After having set up myfaces extension scripting, you basically can start editing, and we
are done with the users guide.
@@ -16, +16 @@

  As is, every scripting language which can compile against the JVM can be supported, currently
there is no support for the scripting language API of Java 6. The reason simply is that the
API is too limiting for now in what '''Ext-Scripting''' tries to achieve.
  
  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.
+ 
+ 
+ == Supported artifacts ==
+ 
+ Ext-Scripting supports following JSF 1.2 artifact reloading:
+ 
+  * ApplicationFactory reloading on method call level
+  * FacesContextFactory reloading on method call level
+  * LifecycleFactory reloading on method call level
+  * RenderkitFactory reloading on method call level
+ 
+  * ElResolver
+  * Converter
+  * Validator
+  * Component  reloading on component tree creation level
+  * ViewHandler 
+  * Lifecycle
+  * Renderer
+  * PhaseListener
+  * ManagedBeans reloading for all managed beans even session and application scoped ones
on request level 
+ 
+ All those artefacts are supported on Java and Groovy Level
+ 
+ Ext-Scripting allows following JSF2 artefacts for reloading:
+ 
+  * All major JSF 2 annotations can be used in a dynamic way
+  * ResourceHandler
+   
+ Not yet supported event handlers for system events.
+ (Has to be implemented)
+ 
  
  == Problems and Considerations ==
  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.
@@ -39, +70 @@

  For the average user of '''Ext-Scripting''' all of this does not have to be of concern,
yet it explains some sidebehavior implementors might encounter while programming deeper in
JSF.
  
   * First of all, all 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
+ 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 this, 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)
+ 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 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 artefact reloading can happen of artefacts 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!
+  * 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!
  
-  * Depending on the artefact the reloading behavior might be slightly different. Components
for instance need a freshly build component tree otherwise an error in the restore state phase
might occur (does not have to be but can), only a freshly built component tree can ensure
the integrity of the data and code in this area. Bean refreshes however can happen without
any of those sideffects, but again beans might get refreshed which never had been touched
to ensure the integrity of the entire system!
+  * Depending on the artifact the reloading behavior might be slightly different. Components
for instance need a freshly build component tree otherwise an error in the restore state phase
might occur (does not have to be but can), only a freshly built component tree can ensure
the integrity of the data and code in this area. Bean refreshes however can happen without
any of those sideffects, but again beans might get refreshed which never had been touched
to ensure the integrity of the entire system!
  Under normal circumstances nothing of this has to be of concern for the average user of
the system but, integrity of the system comes first and trying to avoid server restarts is
the second most important goal.
  
   

Mime
View raw message