myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manfred Geiler" <>
Subject Re: myfaces groovy support
Date Tue, 13 May 2008 06:54:57 GMT
Cool thing, Werner. Congrats!

On Tue, May 13, 2008 at 7:45 AM, Werner Punz <> wrote:
> Hello everyone
>  I just wanted to give notification that I took a small break from my
> components project which is still on track and that I am working on myfaces
> groovy support.
>  I got the first artefacts already reloading, and a first code will
>  be made available by the end of the week, early next week.
>  (For the Sun guys reading, thanks a lot you gave me the final push to do
> it, although I did many things differently than you did)
>  Ok what will be done:
>  First of all I replaced all the factories with my own ones
>  to enable the entire system, I also had to write my own context listener
>  to handle the classloader issues.
>  (We really need a change in the spec here to enable scripting properly -
> Ed?)
>  Secondly once the factories were in place I added proxy generation code
> wherever needed to enable reloading proxies.
>  Third, a classloader which forks into the groovy system to load the groovy
> code.
>  The groovy code also has its own reloading weaving code added to enable
> reloading of groovy files on the groovy side of things (the woven aop
> reloading code is lost on the java side however if you just deliver classes
> instead of objects, my first approach was a try to enable everything on the
> java side)
>  So what do we get
>  Reloading for most artefacts (probably on method level if things work out
> the way I intend them to be (For certain artefacts
>  there are contracts you have to program in on the groovy side to enable
> this - aka expose the private properties some artefacts have otherwise
>  a on method reloading will not be possible).
>  Maybe and this is a big maybe, if I can get it up and running (I want to
>  replace code on the fly) reloading of methods on groovy classes loaded by
> groovy over the new classloader.
>  Again this is a big if, I have not prototyped this fully yet, but it should
> be possible.
>  The idea is, once you load an in groovy object over the classloader
>  it should be possible to change its methods on the fly via the meta
> programming capabilities of groovy.
>  Ok first code around friday or early next week. After that I will start
> further discussions.
>  And again, thanks to Ryan and Ed for finally pushing me towards it
> (indirectly by doing it).
>  I also have to admit I have had a look at some parts of the code to check
> how you guys solved some problems I have been facing - especially the
> dreaded classloader issues and weaving issues.
>  (I did most of the stuff differently though due to the different approach I
> am doing, of a mixed groovy/java infrastructure to enable some things not
> reachable from the java side that easily, also I did not want to change the
> core code, I wanted to have it more as an extension).
>  If you want to have a look at the code upfront
>  before next week, send me a private mail, I just do not want to post
>  it yet because it still is not done enough for a public post.
>  Especially the init code I am still very unhappy with.
>  Werner

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

Professional Support for Apache MyFaces

View raw message