struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Brock <bro...@gmail.com>
Subject Re: MVEL?
Date Mon, 13 Oct 2008 02:04:49 GMT

... I should note that in 2.0b1 the generic type observance is not completely
implemented for set expressions, since we have not augmented the API to
accept a ParserContext object to turn this on (which is required by the
compiler).  It is possible to mimic set expressions with the regular
compiler, but there's no point in benchmarking a hack at this point.  2.0b2
will have the API issue resolved with overloaded compileSetExpression()
methods that accept a ParserContext parameter. Anyways...

// interpreted
MVEL.setProperty(contextObject, "foo.property", value);

--snip-snip--

// compiled
Serializable s = MVEL.compileSetExpression("foo.property");

MVEL.executeSetExpression(s, contextObject, value);












Brian Pontarelli wrote:
> 
> Send me the code to set values which will require object construction  
> and generic inspection and handling as well.
> 
> Thanks,
> -bp
> 
> 
> On Oct 12, 2008, at 6:35 PM, Chris Brock wrote:
> 
>>
>>
>> Assuming you're using a context-root, you'd write it like this:
>>
>> long start = System.currentTimeMillis();
>> for (int i = 0; i < iterations; i++ {
>> MVEL.eval("foo.bar", entityObj);  // equivalent of:
>> entityObj.getFoo().getBar();
>> }
>> System.out.println("interpreted time: " +
>> (System.currentTimeMillis()-start));
>>
>> You can also compare MVEL'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("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 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 dependencies on
>>>> HttpServletRequest and
>>>> outward dependencies to your framework.  I tried to check-out
>>>> everything,
>>>> but SVN kept dying while checking out (I think Google's SVN server  
>>>> was
>>>> acting up).
>>>>
>>>> One of the problems of trying to do a simple performance test with
>>>> your
>>>> stuff is that (like you say) it's not generic, and a bit of a pain
>>>> 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 if it would mean sub-millisecond times,
>>>>> although the work probably isn't worth the effort with such small
>>>>> numbers.
>>>>>
>>>>> Just create three classes:
>>>>>
>>>>> An action
>>>>> A user object
>>>>> An address object
>>>>>
>>>>> The action has a user and the user has a generic Map of addresses
>>>>> keyed off a String. This should work:
>>>>>
>>>>> public class Action
>>>>>  public User user;
>>>>> }
>>>>>
>>>>> public class User {
>>>>>  public int age;
>>>>>  public Map<String, Address> addresses;
>>>>> }
>>>>>
>>>>> public class Address {
>>>>>  public String zipcode;
>>>>> }
>>>>>
>>>>> Then, just get and set some values without any pre-compile or  
>>>>> caching
>>>>> and let me know what the times are. My guess is that you will be
>>>>> slightly slower or the same. To get truly accurate, we might have  
>>>>> to
>>>>> go sub-millisecond or create some more dramatic tests.
>>>>>
>>>>> Also, I doubt that StringTokenizer is impacting my performance any.
>>>>> In
>>>>> fact the numbers clearly state otherwise. Besides, with things
>>>>> happening sub-millisecond or just above that, I just don't see any
>>>>> benefit in spending a lot of time making it faster.
>>>>>
>>>>> -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 sliding-window
>>>>>> parser.
>>>>>>
>>>>>>
>>>>>> Brian Pontarelli wrote:
>>>>>>>
>>>>>>> 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 that JUEL is that slow though. And if
it
>>>>>>> really
>>>>>>> is, it should be extremely simple to make it just as fast as
 
>>>>>>> MVEL.
>>>>>>> But
>>>>>>> I couldn't say for certain because I don't know the code.
>>>>>>>
>>>>>>> I ran some simple tests on getting and setting properties for
the
>>>>>>> JCatapult expression evaluator and here's what I got:
>>>>>>>
>>>>>>> Retrieving from a JavaBean property ("user.age")   1ms
>>>>>>> Retrieving from a public member field ("user.age")   < 1ms
>>>>>>> Retrieving from a nested JavaBean property within a collection
>>>>>>> ("user.addresses['home'].zipcode")   1ms
>>>>>>> Retrieving from a nested public member field within a collection
>>>>>>> ("user.addresses['home'].zipcode")   1ms
>>>>>>>
>>>>>>> Setting a JavaBean property with type conversion ("user.age")
   
>>>>>>> 1ms
>>>>>>> Setting a nested JavaBean property, with collections and Object
>>>>>>> creation ("user.addresses['home'].zipcode")   2ms
>>>>>>>
>>>>>>> That's definitely fast enough for my web applications. ;)
>>>>>>>
>>>>>>> JCatapult does support using public member fields of classes
 
>>>>>>> and it
>>>>>>> does shave a little bit of time, but nothing that would make
a  
>>>>>>> huge
>>>>>>> difference. These are all runtime parsing and handling, nothing
 
>>>>>>> is
>>>>>>> compiled or cached.
>>>>>>>
>>>>>>> -bp
>>>>>>>
>>>>>>> On Oct 11, 2008, at 3:09 PM, Chris Brock wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>> that way.  Instead, MVEL has a real-time interpreter which
>>>>>>>> evaluates
>>>>>>>> to a
>>>>>>>> stack during parsing.  Therefore, the general design decisions,
>>>>>>>> particularly
>>>>>>>> around extendability tend to favor singleton-patterns, instead
 
>>>>>>>> of
>>>>>>>> heavyweight configuration sessions which would completely
bog  
>>>>>>>> down
>>>>>>>> the
>>>>>>>> performance.
>>>>>>>>
>>>>>>>> http://artexpressive.blogspot.com/2007/11/juel-vs-mvel.html
>>>>>>>>
>>>>>>>> For an example of how performant MVEL's interpreter is with
no
>>>>>>>> factory
>>>>>>>> caching.
>>>>>>>>
>>>>>>>> In a simple property expression, with no caching (so parsing
>>>>>>>> before
>>>>>>>> executing every time), MVEL was able to parse/reduce the
>>>>>>>> expression
>>>>>>>> "foo.bar" 100,000 times in 94ms.  It took JUEL 2749ms to
do the
>>>>>>>> same.
>>>>>>>>
>>>>>>>> Compiled performance was: 5.8ms to 34.2ms in favor of MVEL
too.
>>>>>>>>
>>>>>>>> So I would err on the side of performance here.  If that
doesn't
>>>>>>>> cut
>>>>>>>> it for
>>>>>>>> web applications, I guess that's fine.  I don't really target
 
>>>>>>>> MVEL
>>>>>>>> towards
>>>>>>>> web applications, really.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>>> request basis, especially if converters are singleton
scoped.
>>>>>>>>> This
>>>>>>>>> information isn't available on the source in most cases.
It is
>>>>>>>>> usually
>>>>>>>>> externalized in the request or the container object.
The API
>>>>>>>>> looks a
>>>>>>>>> pretty lightweight, which is nice, but also restrictive.
From
>>>>>>>>> what I
>>>>>>>>> could see I would have to monkey around with things and
use
>>>>>>>>> something
>>>>>>>>> like a ThreadLocal to pass this information to the converter.
>>>>>>>>>
>>>>>>>>> The source-from-many pattern seems to be somewhat backwards
for
>>>>>>>>> the
>>>>>>>>> web. It is more likely the case that a single converter
will
>>>>>>>>> convert
>>>>>>>>> to many classes from a String or String[]. The JCatapult
type
>>>>>>>>> converter passes in the type being converted to and then
the
>>>>>>>>> String
>>>>>>>>> value(s). Although this is very web centric, it cleans
up the  
>>>>>>>>> API
>>>>>>>>> and
>>>>>>>>> makes things simpler to implement. MVEL is obviously
more
>>>>>>>>> generic,
>>>>>>>>> which means some massaging is necessary to tune it for
the web.
>>>>>>>>>
>>>>>>>>> It also seems to be lacking a good set of exceptions
thrown out
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> API. At least from the docs, since I couldn't find JavaDoc
and
>>>>>>>>> the
>>>>>>>>> distribution only has source (ouch). This doesn't mean
that
>>>>>>>>> Struts
>>>>>>>>> can't provide good runtime exceptions and then just catch
 
>>>>>>>>> those,
>>>>>>>>> but
>>>>>>>>> it leaves things much more open for developers writing
new
>>>>>>>>> converters.
>>>>>>>>> I'd rather see the API define these exceptions clearly
and for
>>>>>>>>> them
>>>>>>>>> to
>>>>>>>>> be checked.
>>>>>>>>>
>>>>>>>>> I think that using generic languages like OGNL or MVEL
are  
>>>>>>>>> decent
>>>>>>>>> solutions, but a web centric solution would be best.
I'm also  
>>>>>>>>> in
>>>>>>>>> favor
>>>>>>>>> or dropping most if not all of the extra features and
only
>>>>>>>>> providing
>>>>>>>>> property/field getting and setting. I think adding in
another
>>>>>>>>> language
>>>>>>>>> just clouds the waters. FreeMarker and JSP both have
languages
>>>>>>>>> that
>>>>>>>>> cover most of the common cases.
>>>>>>>>>
>>>>>>>>> Feel free to take a look at the JCatapult MVC expression
>>>>>>>>> evaluator
>>>>>>>>> for
>>>>>>>>> what I feel should be supported.
>>>>>>>>>
>>>>>>>>> -bp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Oct 11, 2008, at 12:52 PM, Chris Brock wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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 thing I would toss
in as criteria
>>>>>>>>>>> is a
>>>>>>>>>>> good type conversion interface. In JCatapult,
I actually took
>>>>>>>>>>> things a
>>>>>>>>>>> step further. I found that complex types usually
needed more
>>>>>>>>>>> information than just the data to perform the
type  
>>>>>>>>>>> conversion.
>>>>>>>>>>> For
>>>>>>>>>>> example, conversion of dates generally requires
the date
>>>>>>>>>>> format.
>>>>>>>>>>> Likewise, conversion to money generally requires
the currency
>>>>>>>>>>> code.
>>>>>>>>>>> In
>>>>>>>>>>> many MVCs this information is statically configured
for the
>>>>>>>>>>> entire
>>>>>>>>>>> application, configured per action in XML or
properties files
>>>>>>>>>>> or
>>>>>>>>>>> fixed
>>>>>>>>>>> and not configurable at all.
>>>>>>>>>>>
>>>>>>>>>>> For maximum flexibility, I built a system where
tags could
>>>>>>>>>>> provide
>>>>>>>>>>> this additional data via extra attributes (it
can also be
>>>>>>>>>>> configured
>>>>>>>>>>> application wide as well). My tags look like
this:
>>>>>>>>>>>
>>>>>>>>>>> [@jc.text name="user.lifeSavings" currencyCode="USD"/]
>>>>>>>>>>> [@jc.text name="user.birthDay" dateTimeFormat="MM/dd/yyyy"/]
>>>>>>>>>>>
>>>>>>>>>>> This information then gets passed to the type
converters as
>>>>>>>>>>> part of
>>>>>>>>>>> the API.
>>>>>>>>>>>
>>>>>>>>>>> This then reveals another shortcoming of OGNL
and the wrapper
>>>>>>>>>>> in
>>>>>>>>>>> Struts, what if a required attribute is missing?
This is a
>>>>>>>>>>> different
>>>>>>>>>>> case then if the type 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 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
>>>>>>>>>>>> bound
>>>>>>>>>>>> variable, that's say a Map) because of erasure.
 There is no
>>>>>>>>>>>> generic
>>>>>>>>>>>> type
>>>>>>>>>>>> information held on a per-instance basis.
>>>>>>>>>>>>
>>>>>>>>>>>> However, if the parameterized type is a class
member say:
>>>>>>>>>>>>
>>>>>>>>>>>> class Foo {
>>>>>>>>>>>> public Map<String, Integer> map;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> And you use an instance of Foo as a context
or as a bound
>>>>>>>>>>>> variable,
>>>>>>>>>>>> MVEL's
>>>>>>>>>>>> compiler can certainly extract the generic
type information,
>>>>>>>>>>>> and
>>>>>>>>>>>> provide
>>>>>>>>>>>> automatic coercion and verification accordingly.
 MVEL's  
>>>>>>>>>>>> type
>>>>>>>>>>>> verifier will
>>>>>>>>>>>> always extrapolate whatever type data is
available.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Brian Pontarelli wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is not quite the same unless it
can detect generics
>>>>>>>>>>>>> while
>>>>>>>>>>>>> setting
>>>>>>>>>>>>> values and creating values. An example
might be values  
>>>>>>>>>>>>> from a
>>>>>>>>>>>>> form
>>>>>>>>>>>>> going into something like:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 	List<String>
>>>>>>>>>>>>>
>>>>>>>>>>>>> or
>>>>>>>>>>>>>
>>>>>>>>>>>>> 	Map<String, List<Integer>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> or the always fun
>>>>>>>>>>>>>
>>>>>>>>>>>>> 	List<List<Integer>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> that sorta thing. I know that OGNL had
(might not any  
>>>>>>>>>>>>> longer)
>>>>>>>>>>>>> many
>>>>>>>>>>>>> issues with generics in this respect.
I think OGNL also got
>>>>>>>>>>>>> mad
>>>>>>>>>>>>> when
>>>>>>>>>>>>> it encountered something simple like:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 	int[]
>>>>>>>>>>>>>
>>>>>>>>>>>>> or
>>>>>>>>>>>>>
>>>>>>>>>>>>> 	String[]
>>>>>>>>>>>>>
>>>>>>>>>>>>> coming from checkbox lists and multiple
selects. I believe
>>>>>>>>>>>>> that
>>>>>>>>>>>>> it
>>>>>>>>>>>>> would stuff the values into the String[]
like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 	{"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.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/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 JCatapult MVC and it was
really not all that hard. It
>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>> handles
>>>>>>>>>>>>>>> getting and setting, but I figure
that's all that  
>>>>>>>>>>>>>>> should be
>>>>>>>>>>>>>>> allowed
>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>> that point anyways.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -bp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
dev-help@struts.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>> View this message in context:
>>>>>>>>>>>>>> http://www.nabble.com/MVEL--tp19867360p19910418.html
>>>>>>>>>>>>>> Sent from the Struts - Dev mailing
list archive at
>>>>>>>>>>>>>> Nabble.com.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail:
dev- 
>>>>>>>>>>>>>> help@struts.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> -- 
>>>>>>>>>>>> View this message in context:
>>>>>>>>>>>> http://www.nabble.com/MVEL--tp19867360p19914597.html
>>>>>>>>>>>> Sent from the Struts - Dev mailing list archive
at  
>>>>>>>>>>>> Nabble.com.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> View this message in context:
>>>>>>>>>> http://www.nabble.com/MVEL--tp19867360p19935345.html
>>>>>>>>>> Sent from the Struts - Dev mailing list archive at
Nabble.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> -- 
>>>>>>>> View this message in context:
>>>>>>>> http://www.nabble.com/MVEL--tp19867360p19936453.html
>>>>>>>> Sent from the Struts - Dev mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> -- 
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/MVEL--tp19867360p19943987.html
>>>>>> Sent from the Struts - Dev mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>> -- 
>>>> View this message in context:
>>>> http://www.nabble.com/MVEL--tp19867360p19947349.html
>>>> Sent from the Struts - Dev mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>> -- 
>> View this message in context:
>> http://www.nabble.com/MVEL--tp19867360p19947456.html
>> Sent from the Struts - Dev mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 
> 
-- 
View this message in context: http://www.nabble.com/MVEL--tp19867360p19947913.html
Sent from the Struts - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message