For those interested in the MVEL integration, I uploaded what I have so far to:
http://svn.opensymphony.com/svn/xwork/branches/xwork-mvel/
There is plenty of stuff to be done, bot some nice things like the
magic population of lists, employee[1].name = "el zorro" are working.
and a MVEL
tag.
But we're talking about web-based stuff here. MVEL is used for a
broad
range of stuff, like actual scripting in Smooks and JBoss Drools.
It's used
for straight-up data binding in jBPM and JBoss ESB. It's used for
some
custom UI stuff in Mule Galaxy, etc.
To you P.S.: MVEL wo
been
employed through the use of external code generation, and tying compiled
expressions directly to the instance of a JSP tag.
But we're talking about web-based stuff here. MVEL is used for a broad
range of stuff, like actual scripting in Smooks and JBoss Drools. It's used
for s
I'll send you my unit test that does it on my box directly.
-bp
On Oct 12, 2008, at 8:34 PM, Chris Brock wrote:
"However, under one test condition, MVEL never returned and caused a
load of 50 on my box. It was quite distressing, but it looked like
MVEL got into a bunch of infinit
w much better than I.
On Oct 12, 2008, at 8:38 PM, Chris Brock wrote:
" I'd also be interested to hear a
good discussion about caching compiled MVEL expressions and whether or
not thread contention for the cache is an issue at all"
There is no contention in the cache. MVE
First public beta of MVEL 2.0, I mean :)
Chris Brock wrote:
>
> "However, under one test condition, MVEL never returned and caused a
> load of 50 on my box. It was quite distressing, but it looked like
> MVEL got into a bunch of infinite loops or something. I let it run
" I'd also be interested to hear a
good discussion about caching compiled MVEL expressions and whether or
not thread contention for the cache is an issue at all"
There is no contention in the cache. MVEL returns self-contained,
stateless, evaluation trees (or bytecode via t
"However, under one test condition, MVEL never returned and caused a
load of 50 on my box. It was quite distressing, but it looked like
MVEL got into a bunch of infinite loops or something. I let it run at
a load of 50 for a while and then I had to kill it, but none of the
thread
s OGNL and MVEL are about
equal then. In fact, I've never wanted to replace OGNL for performance
reasons. It was for primarily other reasons.
Say you have a page which contains 20 expressions. And your pages are
getting hit 15 times a second (a reality in some high traffic sites).
That&#x
;s compiled performance like so:
>>
>> Serializable s = MVEL.compileExpression("foo.bar");
>> long start = System.currentTimeMillis();
>> for (int i = 0; i < iterations; i++) {
>> MVEL.executeExpression(s, entityObj);
>> }
>> System.out.println(&quo
erializable s = MVEL.compileExpression("foo.bar");
long start = System.currentTimeMillis();
for (int i = 0; i < iterations; i++) {
MVEL.executeExpression(s, entityObj);
}
System.out.println("compiled time: " + (System.currentTimeMillis()-
start));
Brian Pontarelli wrote:
Se
(s, entityObj);
}
System.out.println("compiled time: " + (System.currentTimeMillis()-start));
Brian Pontarelli wrote:
>
>
> Send me code for MVEL and I'll run both. It will be much easier for
> you to write good MVEL code than me.
>
> -bp
>
>
> On Oct 12, 2008, at 6:18
enchmarks (from MVEL 1.2--which is old):
Test Name: Deep Property
Expression : foo.bar.name
Iterations : 5
Interpreted Results :
(OGNL) : 1955.20ms avg. (mem delta: -790kb)
[1936,1949,1943,1994,1954]
(MVEL) : 114.80ms avg. (me
in
in the
butt to test in isolation.
Brian Pontarelli wrote:
We could do that if you like. Those are pretty simple numbers with
very straight-forward cases. So, please run those against MVEL and
let
me know what you get. StringTokenizer is obviously quite fast, and I
could easily remove it
Send me code for MVEL and I'll run both. It will be much easier for
you to write good MVEL code than me.
-bp
On Oct 12, 2008, at 6:18 PM, Chris Brock wrote:
I actually tried to do this really quickly earlier. I didn't have
time to
figure it out, as your EL stuff has depen
le numbers with
> very straight-forward cases. So, please run those against MVEL and let
> me know what you get. StringTokenizer is obviously quite fast, and I
> could easily remove it if it would mean sub-millisecond times,
> although the work probably isn't worth the effo
fast enough for any web application.
-bp
On Oct 12, 2008, at 11:46 AM, Chris Brock wrote:
Well, I'd like to see an actual comparison. I somehow doubt your
parser,
which I note is using StringTokenizer will perform as well as MVEL's
parser,
which is a much more computationally efficient sl
We could do that if you like. Those are pretty simple numbers with
very straight-forward cases. So, please run those against MVEL and let
me know what you get. StringTokenizer is obviously quite fast, and I
could easily remove it if it would mean sub-millisecond times,
although the work
imilar or better performance using a
> linear runtime evaluation if the language is simple enough and tuned
> for the web. And as you and I say, MVEL and most other languages
> aren't targeted to the web and have many extra features.
>
> I can't really believe that J
Right, but you can receive similar or better performance using a
linear runtime evaluation if the language is simple enough and tuned
for the web. And as you and I say, MVEL and most other languages
aren't targeted to the web and have many extra features.
I can't really believe
Here is the documentation for type converters in MVEL:
http://docs.codehaus.org/display/MVEL/Type+Converters
Brian Pontarelli wrote:
>
> Taking a brief look at the MVEL type conversion API it could be
> somewhat difficult to get this information into the converter on a per
> r
The singleton pattern is used in MVEL, with knowledge of the tradeoff. MVEL
has a strong emphasis on maintaining interpreted-mode performance.
MVEL contains two runtime systems: an interpreter, and a compiler/runtime.
Unlike other ELs, MVEL does not simply bootstrap the compiler, and execute
Taking a brief look at the MVEL type conversion API it could be
somewhat difficult to get this information into the converter on a per
request basis, especially if converters are singleton scoped. This
information isn't available on the source in most cases. It is usually
externaliz
MVEL has a pluggable type-conversion API, just like OGNL. Since it's
source-from-many in it's design, you can easily design converters that
perform as much introspection as necessary to determine formatting, etc.
Brian Pontarelli wrote:
>
> Yeah. That's good. The last
conversion fails. So, I created two distinct
checked exceptions to handle these two cases. This makes the type
conversion system more powerful and easy to interact with. Plus, it
reveals good exceptions for coding problems.
-bp
On Oct 10, 2008, at 3:00 AM, Chris Brock wrote:
MVEL wi
MVEL will handle type coercion for method parameters, properties, and even on
egress of those values if the generic type information can be deduced on
ingress. In situtations where the generic type is dependent on the root of
the object graph though, MVEL cannot infer generic type data (ie. a
quot;value1,value2,value3"}
rather than
{"value1", "value2", "value3"}
This was a while ago, so all of this might be fixed.
-bp
On Oct 9, 2008, at 7:32 PM, Chris Brock wrote:
MVEL 2.0 has full support for generics (and static typing):
http://mvel.code
MVEL 2.0 has full support for generics (and static typing):
http://mvel.codehaus.org/Strong+Typing+Mode
Brian Pontarelli wrote:
>
>
> On Oct 7, 2008, at 3:08 PM, Dave Newton wrote:
>
>> Just to muddy the EL/templating waters:
>>
>> http://mvel.codehaus.org/Perf
I've actually been working on the mvel integration since last week to
see if it is doable and to check if the performance win is indeed as
significant as we all hope. So far, (most of) the valuestack and
ognlutil have been successfully replaced, but I've only focused on XW
at this time.
On Oct 7, 2008, at 3:08 PM, Dave Newton wrote:
Just to muddy the EL/templating waters:
http://mvel.codehaus.org/Performance+of+MVEL
(v. OGNL)
Not sure about MVEL or OGNL at this point, but everything was lacking
in support for generics, collections and arrays. I wrote my own for
the
Touché¹.
_
¹ Threeché even.
--
From: "Martin Cooper" <[EMAIL PROTECTED]>
Sent: Tuesday, October 07, 2008 5:15 PM
To: "Struts Developers List" ;
<[EMAIL PROTECTED]>
Subject: Re: MVEL?
I'm n
I'm not sure that this muddies things much - MVEL has come up before:
http://struts.markmail.org/search/?q=MVEL
--
Martin Cooper
On Tue, Oct 7, 2008 at 2:08 PM, Dave Newton <[EMAIL PROTECTED]> wrote:
> Just to muddy the EL/templating waters:
>
> http://mvel.codehaus.org
Just to muddy the EL/templating waters:
http://mvel.codehaus.org/Performance+of+MVEL
(v. OGNL)
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
33 matches
Mail list logo
