myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <>
Subject Re: Extension-Scripting status
Date Thu, 21 Jan 2010 16:57:10 GMT
Ok another status update since some people obviously read my postings 
regarding it (Although I always have the impression no one does from the 
feedback in the list).

The next commit will happen probably tomorrow, I am working on it.
Two new features are enabled, which are the last two from my side 
probably which will hit the codebase pre 1.0.

(The Spring part is still pending but that is not my code...
Bernhard... hurry up!)

Whats new, I added a compiler output catching component, so that you can 
see the compiler errors instantly on your page you are editing.

I added some JSF2 facelet extension code, because the original codebase
did not have an error, but the tag attribute resolution was caching the 
method and once I replaced the component it caused an class exception 
because the method which was cached was triggered on an old version of 
the class while the instance already had a different class.

The solution is to make a Java 7 like InvokeVirtual (which I can 
simulate in my framework with some introspection code) on the new instance.

I would propose a fix in our codebase in the long run so that I can drop 
this extension, but for now lets leave it how it is, since I could use 
an official extension point it was a no brainer.

So far this works only on JSF2, and probably we will have to live with 
it because I am not sure if I have a similar extension point in the 
original facelets codebase. I also must say I am not very eager to fix 
it at all for 1.2.x because it will be legacy soon anyway.

Anyway this now introduces the possibility to write a JSF2 component 
from start to scratch in java or groovy without a single server restart
if you dont have to introduce your own Tag Handler. (I was eating my own 
dogfood, I implemented the compiler output catching component with 
ext-scripting, hence I discovered this problem)

Thats it for now, I will do a few videos showing off the latest codebase 
next week, when I finally have more time again to work on things - 


Werner Punz schrieb:
> Hello everyone
> Just a short status update where we are for the list.
> I am currently working on changing the Groovy classloading from parse to 
>   the same compile mechanism we have in Java. The reason for this is 
> speed gains at server startup, and also we get the extended dependency 
> scanning we already have in java.
> Here is what we currently have
> Additionally to that we also have now a Facelet extension which can be 
> turned on which allows to load xhtml pages on the fly from your source 
> director instead of the xhtml directory (gotta upate the image)
> Additionally to that I added a small Resource Handler for JSF2 which 
> does the same for JSF2 ressources as we do for Facelets.
> An early draft of the documentation also can be found in the wiki under
> So what is left to be done on my side.
> For now I am still working on the Groovy compilation instead of using 
> the parse mechanism, to get a better interception point for the bytecode 
> level dependency scanner, I am almost done with it, a commit with a 
> version doing this will happen mid next week. After that I will improve 
> the bean reloading by trying only to reload the dependencies in case of 
> a bean being tainted(currently all dynamic beans are reloaded). This 
> should not be too hard to pull off.
> After that Bernhard still wants to merge his Spring stuff in pre Alpha, 
> so I will wait for him in this regard (his university courses of course 
> have higher priority than our project here) and will use the time for 
> bugfixing improving the documentation etc...
> At one point after that I want to open the Alpha version vote.
> My plan is to get at least the Alpha version out before the JSFDays,
> so that we have one version people can start to use for testing and 
> trying out when we will present the stuff first time there.
> But as you can see we are very far along and a 1.0 version is nearing 
> rapidly.
> Plans after 1.0
> It is still undecided which features go in, but there are some ideas:
> Additional scripting languages (JRuby, Scala and Jython are high on the 
> list since they provide native compilers)
> Portlet support
> Changing from a request based trigger for the compiler to an 
> asynchronous compilation as discussed here, this will remove
> some internal complexity we have
> Internal structural fixes
> Mojarra support, ok, this is somewhat low priority on my list, I cannot 
> do it for licensing reasons, otherwise I would gain too much insight 
> into the other implementation which some people in here might not really 
> like. The question is anyway with JSR 292 around the table which might 
> simplify a lot of things which I had to go through major hoops, 
> especially in the classloader area, if they will not roll out something 
> similar in the long run purely based on JSR 292. If not the Mojarra 
> people can feel free to pick up my ideas and code, I always will give a 
> helping hand to port things over post 1.0 :-)
> But as I said this is just a handful of ideas floating around and it 
> depends also on my personal time (I have a baby son currently learning 
> walking, so Ext-Scripting is delegated to traveltime and midnight 
> coding) and company time how much I can dedicate time into it, and hence 
> I have to judge by importance and personal time I can dedicate into the 
> project which features will make it in post 1.0.
> As for people wanting to test it, you can basically use the current 
> codebase for checking stuff out, (I hope it works, the current status 
> got a few relatively untested fixes in). The next big commit will be 
> next week, with the Groovy recompilation that one will again get a 
> bigger testing time before commit. So if you can wait a handful of days 
> just wait for the next commit on my side. If not feel free (and I hope 
> it works :-) )
> Werner

View raw message