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 17:53:46 GMT
Ok the stuff is committed,
lets sum things up, I am more or less feature complete now for 1.0 on 
the JSF side, I am still waiting for the Spring parts Bernhard has 
promised before declaring alpha 1.
I do not want to get any new features in during the alpha phase.
So guys I am not declaring offical alpha now (I would call the current 
stage of things Alpha JSF only), but you can give the stuff a testrun if 
you want, as I said before I will add the pending documentation and 
videos the next days, so stay tuned.


Werner Punz schrieb:
> 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 - 
> opensource.
> Werner
> 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