I think there are a couple of options here: 1. Rollback the changes to use OGNL, 2. Replace OGNL with MVEL, and stop supporting access to private variables (could break a fair bit of code) 3. Have a pluggable PropertyService with OGNL and MVEL implementations (what should be the default?)
Of these options I would prefer #3. regards Malcolm Edgar On Tue, Feb 14, 2012 at 4:41 PM, Bob Schellink <[email protected]> wrote: > The point of the test is to ensure that private variables can be accessed. > MVEL doesn't seem to support access to private variables, hence we will > likely have to rollback to OGNL. > > regards > > Bob > > > On Mon, Feb 13, 2012 at 9:46 PM, Gilberto C Andrade (Commented) (JIRA) < > [email protected]> wrote: > >> >> [ >> https://issues.apache.org/jira/browse/CLK-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207130#comment-13207130] >> >> Gilberto C Andrade commented on CLK-306: >> ---------------------------------------- >> >> Digging a little in the issue, I've found the class[1] that make MVEL >> complain about permission as you can see in the log: >> <quote> >> [junit] at >> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906) >> [junit] Caused by: [Error: could not access property (bool) in: >> java.lang.String] >> [junit] [Near : {... bool ....}] >> [junit] ^ >> [junit] [Line: 1, Column: 1] >> [junit] at >> org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeSetAccessor(ReflectiveAccessorOptimizer.java:312) >> [junit] at >> org.mvel2.optimizers.dynamic.DynamicOptimizer.optimizeSetAccessor(DynamicOptimizer.java:78) >> [junit] at >> org.mvel2.compiler.CompiledAccExpression.setValue(CompiledAccExpression.java:54) >> [junit] at >> org.mvel2.ast.DeepAssignmentNode.getReducedValueAccelerated(DeepAssignmentNode.java:91) >> [junit] at >> org.mvel2.compiler.ExecutableAccessor.getValue(ExecutableAccessor.java:42) >> [junit] at org.mvel2.MVEL.executeExpression(MVEL.java:969) >> >> </quote> >> >> If you change the access modifier of all fields(in the >> RequestBindingPage.java class) from private to public the test will pass. >> >> Thanks and good work, >> >> Gilberto >> >> [1] >> http://svn.apache.org/viewvc/click/trunk/click/framework/test/org/apache/click/pages/RequestBindingPage.java?revision=991908&view=markup >> >> >> > Replacing OGNL with MVEL >> > ------------------------ >> > >> > Key: CLK-306 >> > URL: https://issues.apache.org/jira/browse/CLK-306 >> > Project: Click >> > Issue Type: New Feature >> > Components: core >> > Affects Versions: 1.4 >> > Environment: Target Click 1.5 >> > Reporter: Bob Schellink >> > Assignee: Bob Schellink >> > Fix For: 2.3.1 >> > >> > Attachments: expression-language-performance.rar, >> expression-language-performance.zip >> > >> > >> > I have been following both OGNL and MVEL (another expression language) >> development the last couple of months. If we are going to make changes to >> this here are some things you might find interesting: >> > * OGNL 2.7.1 which is included in tapestry 4.1, now sports byte code >> enhancement. This was added by one of the tapestry authors to make OGNL >> much faster than its reflection mode. However in my testing 2.7.1 threw >> exceptions every now and then. So still buggy. >> > * MVEL (http://mvel.codehaus.org/) seems like a good replacement for >> OGNL. It has good docs and is actively developed. They even fixed a bug I >> logged! Like OGNL, MVEL also runs in two modes, either reflection or byte >> compiled. Unlike OGNL, MVEL's reflection mode is faster than Click's >> reflection mode. >> > I am no expert on this but according to the article below (from MVEL's >> author), byte code enhancement have some problems in that generated classes >> accumulate in java's perm space and will only be removed when their >> classloader is removed. >> > >> http://artexpressive.blogspot.com/2007/07/mvel-by-numbers-real-story.html >> > So MVEL in reflection mode looks like an ideal solution here. The power >> of OGNL with the performance of Click reflection. >> > Table columns can again take advantage of expressions. For example to >> aggregate a total for the row -> new Column("price * tax"); >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA >> administrators: >> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa >> For more information on JIRA, see: http://www.atlassian.com/software/jira >> >> >> >
