You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Werner Punz <we...@gmail.com> on 2008/05/13 07:45:57 UTC
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
Re: myfaces groovy support
Posted by Werner Punz <we...@gmail.com>.
Hia everyone, just a small status update
I got most artefacts up and running
the only ones missing for now
are the components and renderers.
After that I will clean up and document everything.
So I assume the first results will be visible by next week.
(I am bound by day to day duties somewhat)
Sorry for not showcasing anything yet,
but I want to have a fully working cleaned up version
yet before sending the code out in the wild.
There has been a lot of experimenting going on
and some stuff internally is still a little bit messy.
Again if you want to have the code before,
just send me a private mail and I am happy to send it to you
(or open a download link)
Werner
Kito D. Mann schrieb:
> 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@ger.gmane.org] On Behalf Of Werner Punz
>> Sent: Tuesday, May 13, 2008 1:46 AM
>> To: dev@myfaces.apache.org
>> 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
>
>
RE: myfaces groovy support
Posted by "Kito D. Mann" <km...@virtua.com>.
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@ger.gmane.org] On Behalf Of Werner Punz
> Sent: Tuesday, May 13, 2008 1:46 AM
> To: dev@myfaces.apache.org
> 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
Re: myfaces groovy support
Posted by Werner Punz <we...@gmail.com>.
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 <we...@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
>>
>>
>
>
>
Re: myfaces groovy support
Posted by Manfred Geiler <ma...@gmail.com>.
Cool thing, Werner. Congrats!
--Manfred
On Tue, May 13, 2008 at 7:45 AM, Werner Punz <we...@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
>
>
--
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German
Professional Support for Apache MyFaces
Re: myfaces groovy support
Posted by Werner Punz <we...@gmail.com>.
Andrew Robinson schrieb:
> Out of curiosity, will this be able to be extensible to support Jython
> as well? (some ppl like me prefer the jython syntax over groovy's)
>
Well it depends, if jython can generate java Classes through its Eval
functionality in the scripting adapter, then in the long run if someone
does it, yes.
Otherwise it might be hard.
The thing is I intercept a classloader which has to return a class
implementing the bean or jsf artefact the rest is infrastructure which
can be adapted easily to other scripting languages.
The classloader is necessary due to the fact that the scripts themselves
have to be loaded from somewhere, I am not sure if I can remove the
classloader at all, I don´t think so without any significant changes to
the core codebase.
Werner
Btw. Status: following artefacts are already kickstarting:
Beans,
PhaseListener,
ViewHandler
Re: myfaces groovy support
Posted by Andrew Robinson <an...@gmail.com>.
Out of curiosity, will this be able to be extensible to support Jython
as well? (some ppl like me prefer the jython syntax over groovy's)
On Mon, May 12, 2008 at 11:45 PM, Werner Punz <we...@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
>
>