[jira] [Commented] (CLK-306) Replacing OGNL with MVEL

["Gilberto C Andrade (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLK-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635400#comment-13635400 ] 

Gilberto C Andrade commented on CLK-306:
----------------------------------------

I thought MVEL would be more performatic!
But:
[CODE]
gilberto.andrade@A37710:~/bin/click-trunk$ uname -a
Linux A37710.ADMINISTRACAO 3.7.10-1.1-desktop #1 SMP PREEMPT Thu Feb 28 15:06:29 UTC 2013 (82d3f21) x86_64 x86_64 x86_64 GNU/Linux
gilberto.andrade@A37710:~/bin/click-trunk$ javac -version
javac 1.7.0_17
gilberto.andrade@A37710:~/bin/click-trunk$ javac -version


gilberto.andrade@A37710:~/bin/click-trunk$ cat framework/classes/TEST-org.apache.click.service.PropertyServicePerformanceTest.txt
Testsuite: org.apache.click.service.PropertyServicePerformanceTest
Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 20,103 sec
------------- Standard Error -----------------
OGNLPropertyService cumulative  read test in 59599 ms 
OGNLPropertyService cumulative write test in 27741 ms 
MVELPropertyService cumulative  read test in 97231 ms 
MVELPropertyService cumulative write test in 27145 ms 
------------- ---------------- ---------------

Testcase: test_OGNLService took 10,017 sec
Testcase: test_MVELService took 10,079 sec

[/CODE]

Bob, would you mind to make your test again?

regards
                
> 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: Malcolm Edgar
>             Fix For: 2.4.0-RC1
>
>         Attachments: ASF.LICENSE.NOT.GRANTED--expression-language-performance.rar, ASF.LICENSE.NOT.GRANTED--expression-language-performance.zip, mvel.zip, patch.diff
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira

Click, Dependency Injection, and Annotations

["Dennis M. J. Yerger" <de...@hotmail.com>]

I don't know if anyone has dealt with this yet, but dependency injection is a popular concept these days. Spring is the best example of such a framework. Some of Click's online examples are even based on Spring. However, Java EE has a new standard called Contexts and Dependency Injection (CDI). This specification has less dependence on XML than a typical Spring configuration. That means you can add your classes to your project and CDI will automatically detect them at startup. Detected classes can be filtered with qualifier annotations. 

Page interceptors can be automatically registered with Click by using standard CDI annotations such as ApplicationScoped. Consider the following example:

@RequestScoped
public class TestInterceptor implements PageInterceptor {...}

I propose adding an extension to Click to support CDI technology. I have already written working code to test this support, but I am not sure how to submit it. Any help is appreciated.

On a separate but related subject, Click makes little use of annotations in its configuration. The Bindable annotation makes request parameters easy to work with, but there are other possible uses for annotations. They can also be used for mapping a path to a page class. Consider the following example based on my test code:

@PagePaths("test.htm")
public class TestPage extends Page {
}

This is a very simple example. As you can see, the name of the annotation is PagePaths, implying that multiple paths can be mapped to the same class. Page headers are another place where annotations would be useful. Click should have a facility for detecting such annotations and including them in the overall configuration.