myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Petracek" <>
Subject Re: myfaces groovy support first pre alpha showcase
Date Tue, 20 May 2008 17:17:51 GMT
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


2008/5/20 Werner Punz <>:

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


Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

View raw message