myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <werner.p...@gmail.com>
Subject Re: myfaces groovy support
Date Tue, 13 May 2008 07:29:38 GMT
Unfortunately I did an accidental post of this
in the RI devs mailinglist
speaking of being chaotic and early morning.

:-(

Werner



Manfred Geiler schrieb:
> Cool thing, Werner. Congrats!
> --Manfred
> 
> On Tue, May 13, 2008 at 7:45 AM, Werner Punz <werner.punz@gmail.com> 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
>>
>>
> 
> 
> 


Mime
View raw message