Given the number of new failures I’ve run into since I completed the first round of getting all of the existing unit tests to pass using the new ExpressionCompiler I’m pretty terrified at the thought of anyone trying to use it, but progress must come somehow and I’ve run out of things I can find to break it with - so you can grab the continuously updated version from http://howardlewisship.com/repository/ognl/ognl/ for now. (opensymphony has a new maven2 repo in the works, it’ll move there once it’s setup )
What does this mean for the good majority of people? Absolutely nothing! (though absolute neitz sounds better)
That is to say, unless you are integrating it into a framework of some sort it is highly unlikely you’ll find any benefit from using it as you won’t get the fancy new compilation features unless you use some of the new API calls. Of course I’ve done the first round and have it officially integrated into the mainline Tapestry 4.1.2-SNAPSHOT releases so you can get some benefit from it if you happen to be using that framework.
I have found some “unfortunateness” with some of the javassist api. Namely a lack of support for generics as of the latest 3.4.ga version I’ve been working against. It looks like I may actually need to sit down and give asm a little test run to see if it fits my needs as was suggested previously by Eugene && Bob. This makes me none too happy, though I hope to be able to take this new knowledge and use it to rip javassist out of Tapestry so that we can support generics properly there. (even though I’ve added a sort of impure/bastardized version of support for this already)
OGNL Future
Ok, so maybe I’m starting to enjoy some of this work a little more than I was at first now that things are stabilizing a little. As such I plan on implementing a few more features Drew had previously mentioned wanting to see happen (as well as a few of my own / whatever others need):
- Separation of 1.4/1.5 API so that the introduction of “Type” in generic form as well as the impact that has on the enhancements codebase can be clearly separated as much as possible. (I’ll probably be taking another look at TestNG for inspiration on doing this properly)
- Replace javassist with asm.
- Refactor/replace OgnlRuntime with a more IoC friendly version that can be controlled in such a way that multiple instances can live together in the same VM without issues related to static constructs..
- Introduce a couple new grammar rules for things that look neat, like Howards work on Tapestry 5 and the introduction of the “0…N” loop . (that’s right, a grammar change - I’m looking at you mvel …..)
- …..? Not sure what else is missing.
Latest Entries
- updated foxylicious extension for Firefox 3
- how to fix butt ugly ubuntu hardy heron fonts
- Where are our java leader’s opinions on closures?
- Tapestry 4.1.5 Released && various Tacos project releases (like Seam / jQuery support)
- painting by numbers, or how html cowards hide behind CSS
- Rails component envy
- OGNL 2.7.2 Released
- news flash - Swing is a terrible API to emulate in web development
- hip hop is neat
- good closures, bad closures
Mar 13th, 2007 at 10:08 am
You should be looking at our CVS head more often. You’d realize that we’re a bazillion steps ahead of you on the implementation of loops, code blocks, function declaration, control flow, etc. And OGNL still lacks ternary-if’s which MVEL has long supported, which is huge for UI stuff.
This stuff is already quite stable and is headed for our 1.2 release.
Mar 13th, 2007 at 10:53 am
I must confess that I’ve never seen any of your source code other than a performance test class that you pointed out in a forum somewhere.
As for ternary ifs, maybe you should learn more about the ognl feature set first before you make incorrect assumptions - they have been there for as long as I’ve been using OGNL.
Either way it will be interesting to see what you guys come out with in 1.2, I still wouldn’t be able to look at it more than as a very cursory sort of browse unless it had 1.4 support and a comparable grammar to OGNL , but either way competition is (maybe? probably? ) good for these things so …umm…Good?
Mar 14th, 2007 at 8:58 am
Well, that’s interesting that OGNL has ternaries. I used it for the longest time, and could have sworn it blew up when I tried them.
As for 1.4 support. That’s done. JBoss is maintaining that build, and the JAR can be found in the Drools SVN tree right now. When we reach RC, we’ll start distributing the 1.4 compatible JAR on the main site.
As for OGNL-compatible grammar… I’m not sure I ever want to “emulate” OGNL. MVEL’s grammar is closer to Java and Groovy’s grammar which I think is far cleaner than having wacky @ qualifiers for static fields, etc.
Mar 14th, 2007 at 8:51 pm
The ognl grammar similarity is purely for pragmatic reasons and not design. I can’t do a wholesale replacement of anything unless it’s compatible with OGNL grammar just because we have too many users that would burn me at the stake. (and rightfully so)
Mar 25th, 2007 at 12:30 pm
Hi Jesse, this sounds awesome. Question, you mention unless integrating into a framework, unlikely to see performance benefits. Currently I’m using Tapestry 4.0.2, would I see speed improvements if I used this newer ognl? Thanks!
Mar 25th, 2007 at 7:20 pm
Josh:
No, unfortunately you wouldn’t. (Well maybe, but they’d be ever so slight and probably not worth it) There are very specific new API calls that would have to be used instead of the default set.
Of course it shouldn’t be very hard for someone to create a drop-in jar that can be added to a project which will override the necessary hivemind services to get it done - it just isn’t going to be me. At least not anytime soon.
Apr 10th, 2007 at 8:37 am
Hi! I’m very happy to know that Ognl will be continued. The 2.6.9 version doesn’t have any changes since last year.
Now I’m using your last Ognl version and I’ve noticed some issues.
Where is “boolean equals” parameters in the OgnlOps.compareWithConversion() ?
Now I’ve to implement the compareTo in order to compare beans. Really, I think that it’s more strict.
And I have make some changes in Ognl that may be useful. Could you add a third int “reason” parameter to ClassResolver interface? like this:
public Class classForName(String className, Map context, int reason) throws ClassNotFoundException;
Then, you have to change every call to OgnlRuntime.classForName() sending the reason to access class. For example, the ognl.enhance.ContextClassLoader class will be:
return context.getClassResolver().classForName(name, context, ClassResolver.REASON_FINDCLASSLOADER);
With this parameter, I can check the reason to load a class, and enable it or fails. For example, I can disable all new class creation but I can enable all class load and static field/method access.
Thanks for your improvements in Ognl. I really think that Ognl will be discontinued!
May 6th, 2007 at 9:53 am
Is the OGNL 2.7-SNAPSHOT source code available anywhere? I see there’s no tag in the POM. There are the sources jars in the Maven2 repository, but they lack the build system and tests.