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
http://people.apache.org/~werpu/images/ext-scripting-structure-fine.jpg
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
http://wiki.apache.org/myfaces/Extensions/Scripting
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
