click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@gmail.com>
Subject Re: [jira] [Commented] (CLK-306) Replacing OGNL with MVEL
Date Tue, 14 Feb 2012 09:43:03 GMT
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 <sabob1@gmail.com> 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) <
> jira@apache.org> 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
>>
>>
>>
>

Mime
View raw message