Re: myfaces groovy support

> Very cool, Werner!
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Kito D. Mann - Author, JavaServer Faces in Action
> http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
> phone: +1 203-653-2989
> fax: +1 203-653-2988
>
>
>> -----Original Message-----
>> From: news [mailto:news@...] On Behalf Of Werner Punz
>> Sent: Tuesday, May 13, 2008 1:46 AM
>> To: dev@...
>> 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
>
>