+1 for Gerhard idea. On Tue, May 20, 2008 at 8:17 PM, Gerhard Petracek < [EMAIL PROTECTED]> wrote:
> hello werner, > > currently we have several nice extensions. > > + we discussed that 'commons' should stay stable. > > -> my suggestion (instead of the commons project): > let's setup just one further subproject. > > name of the subproject: > e.g.: myfaces-extensions > > which contains something like (in chronological order): > - myfaces-extensions-aspectel > - myfaces-extensions-seven > - myfaces-extensions-scripting > > regards, > gerhard > > > > 2008/5/20 Werner Punz <[EMAIL PROTECTED]>: > > Ok now to the question. >> Now that I am out of the experimentation phase >> I want to merge my stuff into myfaces >> lem is where exactly. >> Suggestions? >> Is the commons project already in place? >> >> >> Werner >> >> >> Werner Punz schrieb: >> >> Hello everyone >>> >>> this is a crude first pre alpha release of the myfaces groovy support >>> you can get it from >>> >>> http://people.apache.org/~werpu/myfaces-groovy.zip<http://people.apache.org/%7Ewerpu/myfaces-groovy.zip> >>> >>> you can make a build with mvn clean install >>> and then drop the war into a servlet runner >>> once expanded and running >>> you can start to hack >>> >>> the groovy files under WEB-INF/groovy/ >>> >>> and you should see the changes without restarting the webapp >>> you even should be able to add properties, methods or remove them on the >>> fly without any server restart >>> >>> (never mind the startup errors this is intended, since >>> myfaces kicks in twice, and the first time it complains about not finding >>> the classes) >>> >>> Have in mind, this is pre alpha stuff i am not entirely where I want to >>> be but it works. >>> >>> Please keep in mind following things: >>> >>> artefacts only start to reload once their sources >>> have been altered after startup, no change, no reload! >>> >>> Renderers work on page refresh >>> Components refresh at creation time >>> (Sorry this is a jsf imposed limitation for now) >>> >>> Beans basically everything coming through the el should reload >>> at reference time (the properties are kept intact so never mind any >>> dependencies) >>> >>> non jsfs Groovy - Groovy references should reload at creation time (this >>> is a feature which is untested yet, so it might not work yet, I had it >>> running though) >>> >>> Long running objects like the view handler etc.. should reload >>> on call time, if changed, which means at least once per refresh, if >>> changed >>> if you have properties which have to survive those changes >>> please expose them, I try to keep the properties intact after reloading >>> but with private or protected properties I do not have a chance. >>> But since most long running artefacts in jsf are stateless this is a non >>> issue. >>> >>> For component development use facelets, I cannot kickstart >>> the jsp artefacts. >>> >>> You can mix and blend java groovy and compiled groovy during development, >>> but for compilation use the groovy stub compilation feature. >>> During production I would recommend to remove the groovy kickstarter >>> and compile everything! >>> >>> >>> Ok here are some technical details. >>> >>> I managed to pull this off without changing a single line of core >>> myfaces code. >>> What I did was to add my own factories which on the correct placed >>> applied some "aop", which means it either was reloading objects on the >>> fly with new code and applying their old properties or adding proxies >>> which basically did the same, depending on the artefact. >>> >>> On the groovy side of things I did the same in a more transparent way to >>> be able to reload referenced objects. >>> I originally wanted to apply this method to all artefacts, but as soon as >>> I shifted the altered classes to the javarealm I lost all the groovy meta >>> info needed for this mechanism. So I kept it on the groovy side of things. >>> >>> What I did on the startup side was to reinitialize myfaces with my own >>> classloader which resolves the groovy files if present. >>> And as well as the sun guys did for the RI I had to add my own >>> servletfilter which checked for replaced classloaders and reapplied the >>> groovy classloader on the fly (tomcat for instance replaces the classloader >>> once it hits a custom one at certain stages) >>> >>> Ok have in mind that this code is pre alpha stage, but nevertheless you >>> can see the potential of it once you try it out. >>> But please do not use it in a production system. >>> (And no it does not work in portlets yet) >>> >>> And please no complaints about dirty code yet it is not done yet ;-) >>> >>> >>> >>> Werner >>> >>> >>> >> > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
