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:[EMAIL PROTECTED] On Behalf Of Werner Punz > Sent: Tuesday, May 13, 2008 1:46 AM > To: [email protected] > 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
