You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@myfaces.apache.org by Apache Wiki <wi...@apache.org> on 2009/12/31 15:44:28 UTC

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

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

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

New page:
='''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.

Well theoretically anyway, there are some things every user of extension scripting has to take into consideration.

First of all '''Ext-Scripting''' in its current incarnation tries to help the programmers every day life, that means it tries to reduce the number of needed server restarts to the lowest possible minimum which is achievable within the boundaries of Java and JSF.

You wont get a zero restart configuration, Extension-Scripting tries not to be perfect in this regard, but what you can achieve is a significant reduction on restarts.

Secondly, we do not try to support every scripting language under the earth, the basic goal is first to get the basics right and then in subsequent releases to add additional scripting languages support.

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.

== 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.

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.

As said before we cannot lift those restrictions either and maybe Java 7 with the JSR 292 will ease them, but fortunately JSF already has certain extension points which allow to some degree to intercept and reload parts of an application if used wisely.

So what internally happens is basically that '''Ext-Scripting''' interferes at two points in a running application, first it interferes on artefact level by introducing reloading proxies, which dump their running artefacts at certain safe points of the application lifecycle and on classloader level by providing different throw away classloaders for different scripting languages.

In between several daemon threads and interception points take care of the compile, dependency detection etc... but that should not be of a huge concern to the programmer using the system.

That way the average programmer always will work on unaltered pure class files, which can be debugged, but also will get his code refreshed at usually the next refresh he does in the system. Which means no interference with artificial constructs on class level which could bring a debugger out of context, but still maximum possible reloadability even on classcast an import level as long as it concerns JSF artefacts like Renderers, Components, Converters and Managed Beans!

{{http://people.apache.org/%7Ewerpu/images/ext%5Fscripting%5Foverview.jpg}}