|
»
»
« Return to Thread: [SUNDAY] Struts 2 and EL
Re: [SUNDAY] Struts 2 and EL
by Brian Pontarelli
::
Rate this Message:
I sorta figured it would be pretty slow. You might also run into some
issues with the APIs depending on how you want to handle type
conversion stuff.
The JCatapult EL is mostly decoupled from the rest of the framework
except that I use the JCatapult ObjectFactory to create instances of
the type converters. However, that would be simple to replace.
Eventually I'd like to figure out where my slow-down is compared to
MVEL and see if I can get it to perform the same. I think my caching
needs a bit of love and also it might be helpful to compile the
statements into Java classes at some point.
-bp
On Jul 6, 2009, at 11:28 AM, Musachy Barroso wrote:
> yes, I was testing different engines yesterday, and groovy is around
> 30 times slower than OGNL, and Rhino around 17 times. JEXL seemed to
> be the faster one, around 7x slower.
>
> That being said, it doesn't change anything because what I am
> suggesting is decoupling the actual implementation, OGNL could still
> be used thru jsr 223, as an option and default implementation.
>
> we would need the value stack just to lookup values, for setting
> values we could use the new binder implementation, to which I just
> added bytecode generation for setters/getters.
>
> is your EL decoupled fro jcatapult?
>
> musachy
>
> On Mon, Jul 6, 2009 at 10:13 AM, Brian
> Pontarelli<brian@...> wrote:
>> I would say the reason you don't want to dive into 233 would be
>> primarily
>> because of performance. You'd either need to have a compiled
>> statement cache
>> or pre-compile. Most of the scripting frameworks that comply with
>> 233 are
>> full blow languages (Groovy, JavaScript, etc) and have pretty slow
>> parsers
>> compared to EL parsers out there. You could give them a try and
>> see, but I
>> would guess you would see a large drop in performance using them. I
>> personally think MVEL is one of the better ways to go once they
>> finish some
>> of the new features they have in mind for the next version (i.e.
>> annotations
>> and such).
>>
>> Or just write your own. I wrote one for JCatapult and it took about
>> a day.
>> It isn't as fast as MVEL, but it works fine for what I need and it
>> doesn't
>> mean it can't be improved on. The primary reason I did that
>> exercise was to
>> fully support 1.5 and generics as well as provide a better type
>> conversion
>> API with annotation support. The way I wrote it you can specify
>> additional
>> attributes using the taglibs or via an annotation that tell the API
>> how to
>> convert Strings to things like Money, dates, and JODA classes.
>>
>> -bp
>>
>>
>> On Jul 5, 2009, at 4:13 PM, Musachy Barroso wrote:
>>
>>> After fighting OGNL and MVEL for a while I've got to the conclusion
>>> that they aren't the best horses to bet my money on, some of the
>>> reasons are not even technical so I won't go into them. So I have
>>> been
>>> playing with a new idea, why should we couple struts to an EL,
>>> when we
>>> can use JSR 223 (Scripting for the Java platform, some docs here:
>>> http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/)
>>> ,
>>> and just make Struts EL agnostic? I know security would be a
>>> concern,
>>> but at least we got standard ways to limit what these scripts can do
>>> or not. it would be very cool if I could just set
>>>
>>> <constant name="struts.scriptEngine" value="groovy" />
>>>
>>> and then just use all of groovy's cool stuff in the tags. So if
>>> people
>>> can just pick their favorite engine, instead of being stuck with our
>>> supported implementation. What do you think?
>>>
>>> musachy
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
issues with the APIs depending on how you want to handle type
conversion stuff.
The JCatapult EL is mostly decoupled from the rest of the framework
except that I use the JCatapult ObjectFactory to create instances of
the type converters. However, that would be simple to replace.
Eventually I'd like to figure out where my slow-down is compared to
MVEL and see if I can get it to perform the same. I think my caching
needs a bit of love and also it might be helpful to compile the
statements into Java classes at some point.
-bp
On Jul 6, 2009, at 11:28 AM, Musachy Barroso wrote:
> yes, I was testing different engines yesterday, and groovy is around
> 30 times slower than OGNL, and Rhino around 17 times. JEXL seemed to
> be the faster one, around 7x slower.
>
> That being said, it doesn't change anything because what I am
> suggesting is decoupling the actual implementation, OGNL could still
> be used thru jsr 223, as an option and default implementation.
>
> we would need the value stack just to lookup values, for setting
> values we could use the new binder implementation, to which I just
> added bytecode generation for setters/getters.
>
> is your EL decoupled fro jcatapult?
>
> musachy
>
> On Mon, Jul 6, 2009 at 10:13 AM, Brian
> Pontarelli<brian@...> wrote:
>> I would say the reason you don't want to dive into 233 would be
>> primarily
>> because of performance. You'd either need to have a compiled
>> statement cache
>> or pre-compile. Most of the scripting frameworks that comply with
>> 233 are
>> full blow languages (Groovy, JavaScript, etc) and have pretty slow
>> parsers
>> compared to EL parsers out there. You could give them a try and
>> see, but I
>> would guess you would see a large drop in performance using them. I
>> personally think MVEL is one of the better ways to go once they
>> finish some
>> of the new features they have in mind for the next version (i.e.
>> annotations
>> and such).
>>
>> Or just write your own. I wrote one for JCatapult and it took about
>> a day.
>> It isn't as fast as MVEL, but it works fine for what I need and it
>> doesn't
>> mean it can't be improved on. The primary reason I did that
>> exercise was to
>> fully support 1.5 and generics as well as provide a better type
>> conversion
>> API with annotation support. The way I wrote it you can specify
>> additional
>> attributes using the taglibs or via an annotation that tell the API
>> how to
>> convert Strings to things like Money, dates, and JODA classes.
>>
>> -bp
>>
>>
>> On Jul 5, 2009, at 4:13 PM, Musachy Barroso wrote:
>>
>>> After fighting OGNL and MVEL for a while I've got to the conclusion
>>> that they aren't the best horses to bet my money on, some of the
>>> reasons are not even technical so I won't go into them. So I have
>>> been
>>> playing with a new idea, why should we couple struts to an EL,
>>> when we
>>> can use JSR 223 (Scripting for the Java platform, some docs here:
>>> http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/)
>>> ,
>>> and just make Struts EL agnostic? I know security would be a
>>> concern,
>>> but at least we got standard ways to limit what these scripts can do
>>> or not. it would be very cool if I could just set
>>>
>>> <constant name="struts.scriptEngine" value="groovy" />
>>>
>>> and then just use all of groovy's cool stuff in the tags. So if
>>> people
>>> can just pick their favorite engine, instead of being stuck with our
>>> supported implementation. What do you think?
>>>
>>> musachy
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
« Return to Thread: [SUNDAY] Struts 2 and EL
| Free embeddable forum powered by Nabble | Forum Help |
