myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kito D. Mann" <>
Subject RE: myfaces groovy support
Date Wed, 14 May 2008 18:29:07 GMT
Very cool, Werner!

Kito D. Mann - Author, JavaServer Faces in Action - JSF/Java EE consulting, training, and mentoring - JavaServer Faces FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988

> -----Original Message-----
> From: news [] On Behalf Of Werner Punz
> Sent: Tuesday, May 13, 2008 1:46 AM
> To:
> Subject: myfaces groovy support
> 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

View raw message