Comments on: tentative ognl 2.7-SNAPSHOT release out to blow up a project near you.. http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/ blah blah blah, blah blah.. Thu, 04 Mar 2010 19:37:10 -0500 hourly 1 http://wordpress.org/?v=3.0.1 By: Max Bowsher http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/comment-page-1/#comment-2409 Max Bowsher Sun, 06 May 2007 16:53:10 +0000 http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/#comment-2409 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. 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.

]]> By: Alberto Vilches http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/comment-page-1/#comment-1873 Alberto Vilches Tue, 10 Apr 2007 15:37:23 +0000 http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/#comment-1873 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! 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!

]]> By: jkuhnert http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/comment-page-1/#comment-1612 jkuhnert Mon, 26 Mar 2007 02:20:12 +0000 http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/#comment-1612 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. 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.

]]> By: JoshJoy http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/comment-page-1/#comment-1611 JoshJoy Sun, 25 Mar 2007 19:30:04 +0000 http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/#comment-1611 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! 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!

]]> By: jkuhnert http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/comment-page-1/#comment-1603 jkuhnert Thu, 15 Mar 2007 03:51:13 +0000 http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/#comment-1603 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) 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)

]]> By: Mike Brock http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/comment-page-1/#comment-1602 Mike Brock Wed, 14 Mar 2007 15:58:18 +0000 http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/#comment-1602 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. 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.

]]> By: jkuhnert http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/comment-page-1/#comment-1601 jkuhnert Tue, 13 Mar 2007 17:53:31 +0000 http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/#comment-1601 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? ;) 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? ;)

]]> By: Mike Brock http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/comment-page-1/#comment-1600 Mike Brock Tue, 13 Mar 2007 17:08:44 +0000 http://blog.opencomponentry.com/2007/03/05/tentative-ognl-27-snapshot-release-out-to-blow-up-a-project-near-you/#comment-1600 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. 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.

]]>