--- Musachy Barroso <[EMAIL PROTECTED]> wrote:
> We could enable the cache when devMode is false.
+1, at least as default behavior.
d.
Be a PS3 game guru.
Get your game face on with the latest PS3 news and p
Yeah, I still need to confirm nothing is broken in core, except the tooltips
which I know are not working. By the way Dojo 0.4.2 was released, how was
the upgrade made last time? Drop the dojo files and add the new ones?
musachy
On 3/24/07, Ted Husted <[EMAIL PROTECTED]> wrote:
As I believe th
As I believe the Ajax/Dojo plugin is ready, if we could mop-up the
portlet plugin ticket, we could apply the caching patch to the HEAD,
and get started on the 2.1.x series.
Having AJAX as a plugin rather than a theme will also benefit many people :)
-Ted.
On 3/24/07, Tom Schneider <[EMAIL PROTE
We could enable the cache when devMode is false.
musachy
On 3/24/07, Tom Schneider <[EMAIL PROTECTED]> wrote:
Well, there is a small risk of things being cached and a developer
relying on the behavior of not caching the templates. However, I think
those cases will be rare and it would benefit
Well, there is a small risk of things being cached and a developer
relying on the behavior of not caching the templates. However, I think
those cases will be rare and it would benefit many people.
Tom
Musachy Barroso wrote:
Any reason why this shouldn't be applied on the 2.0 branch instead of
Any reason why this shouldn't be applied on the 2.0 branch instead of 2.1?
musachy
On 3/24/07, Tom Schneider <[EMAIL PROTECTED]> wrote:
I wrote a struts2 caching implementation of the freemarker templates:
https://issues.apache.org/struts/browse/WW-1661
Freemarker wouldn't know how to cache t
I wrote a struts2 caching implementation of the freemarker templates:
https://issues.apache.org/struts/browse/WW-1661
Freemarker wouldn't know how to cache the templates as well as struts2
does since we know how the templates are being used and whether or not
it is safe to cache them.
Tom
C
>From the performance tuning page:
Copy the /template directory from the Struts 2 jar in your WEB_APP root.
Freemarker fails to properly cache templates when they are retrieved from the
classpath. Copying them to the WEB_APP root allows Freemarker to cache them
correctly. Freemarker looks at th
To avoid such long threads in future, probably it makes sense to add some
performance
benchmark page in struts examples distribution.
Would it be possible to contribute the test page you've already
started? We have a ticket open.
* https://issues.apache.org/struts/browse/WW-1560
I'm also atta
When I see OGNL classes in exceptions stack trace, I believe it is not as fast
as 2+2.
But I have never thought to replace tags with <%= %> scriplets.
performance is enough for me, for now.
WebWork form tags could be really slow. After I have moved templates out of
webwork.jar to WEB-INF/temp
Not sure what the profiler data looks like but if the profiler is indeed
stating that OGNL code is taking the most processor time and it is
indeed 5-10 times slower, than the performance tuning page doesn't look
like it will address these issues. However, it could simply be the
profiler data is
Has anyone rerun these type of benchmarks in light of the performance
tuning page?
* http://struts.apache.org/2.x/docs/performance-tuning.html
-Ted.
On 12/11/06, dice <[EMAIL PROTECTED]> wrote:
By my own benchmarking I am finding Struts 2 somewhere between 5-10 times
slower than Struts 1 in J
Tonight I was looking at abstracting away OGNL from xwork. (I was
pretty far before I gave up for the night, about a half dozen OGNL
references in xwork that I'll have to look at a little closer) So I
took a look at what it would take to integrate MVEL. First, the lack of
javadoc is a little
From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H.
DeWolf
Sent: Monday, December 18, 2006 6:32 PM
To: Struts Developers List
Subject: Re: OGNL performance detrimental to Struts 2
I double dare you :)
Don Brown wrote:
> Well, I dare you then: http://issues.apache.org/struts/
by hook or crook we have to solve the performance issue..
-Original Message-
From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H.
DeWolf
Sent: Monday, December 18, 2006 6:32 PM
To: Struts Developers List
Subject: Re: OGNL performance detrimental to Struts 2
I double dare
-
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-
Did you try using the simple theme with Struts 2.0.1 in the benchmarks?
-Ted.
On 12/11/06, dice <[EMAIL PROTECTED]> wrote:
By my own benchmarking I am finding Struts 2 somewhere between 5-10 times
slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the
bottleneck.
I double dare you :)
Don Brown wrote:
Well, I dare you then: http://issues.apache.org/struts/browse/WW-1566
:)
Don
Chris Brock wrote:
Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days.
Don Brown-2 wrote:
I'd like it to be possible for a Struts developer to swap in a n
Well, I dare you then: http://issues.apache.org/struts/browse/WW-1566
:)
Don
Chris Brock wrote:
Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days.
Don Brown-2 wrote:
I'd like it to be possible for a Struts developer to swap in a new EL,
perhaps MVEL, if they didn't li
t;>>>>
>>>>>>>
>>>>>>>> >>>>>>>
>>>>>>>>
>>>>>>> name="nestedBean.attribute2"/>
>>>>>>>
>>>>>>>
&g
I'd like it to be possible for a Struts developer to swap in a new EL,
perhaps MVEL, if they didn't like OGNL for some reason. If you can
create a patch to make that happen, I would consider it my early
Christmas present :)
Don
Chris Brock wrote:
Why do you think it would be so terribly dif
Me too.
On 12/18/06, Don Brown <[EMAIL PROTECTED]> wrote:
If you can find a way to completely replace OGNL by MVEL, I'd be very
interested to see it. :)
Don
Chris Brock wrote:
> I think the problem is that the Tapestry solution is simply a property
> accessor package, which doesn't really meet
;>>>
>>>>>> >>>>>
>>>>> name="nestedBean.attribute5"/>
>>>>>
>>>>>> >>>>>
>>>&g
If you can find a way to completely replace OGNL by MVEL, I'd be very
interested to see it. :)
Don
Chris Brock wrote:
I think the problem is that the Tapestry solution is simply a property
accessor package, which doesn't really meet the needs of the established
WebWork community which relies o
assist.
> I think it's performance and flexibility speak for itself:
> http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language
>
--
View this message in context:
http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.
>> >
>>> > Ted Husted-3 wrote:
>>> >
>>> >> On 12/13/06, Ian Roughley <[EMAIL PROTECTED]> wrote:
>>> >>
>>> >>> Do you have the performance numbers that
>
>> >> *
>> >>
>>
http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html
>> >>
>> >> (be sure to read to the *end* of the commnets).
>> >>
>> >> We might want to come up with
ripes-simple-performance.html
>> >>
>> >> (be sure to read to the *end* of the commnets).
>> >>
>> >> We might want to come up with a set of test pages that thorougly
>> >> exercise the core tags, so that we can run our own direct comparison
I wrote a simple Struts 2 TemplateEngine that renders tags in pure
Java, as opposed to the Freemarker that is used currently. I'm seeing
performance improvements between 3 and 4 times faster than the old
tags. This engine is based on the design I layed out previously [1].
It is better suited to
Speaking of tickets, there's one already open
* http://issues.apache.org/struts/browse/WW-
-Ted.
On 12/14/06, Don Brown <[EMAIL PROTECTED]> wrote:
Very interesting... I wonder how much of the performance hit was due to
Freemarker and how much OGNL. Could you package this application in a
war
Very interesting... I wonder how much of the performance hit was due to
Freemarker and how much OGNL. Could you package this application in a
war and attach it to a JIRA ticket? I'd love to have it for future
comparisons.
Don
dice wrote:
They are my stats Ted. The stats are posted below al
gt; -Ted.
>
>
--
View this message in context:
http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7865392
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
direct comparisons
>> > of S1, S2, et al.
>> >
>> > Of course, the peformance is the still same as WebWork 2, which is
>> > driving some serious applications. We also know exactly where lies the
>> > bottleneck. We need to fix or replace OGNL.
>&g
us applications. We also know exactly where lies the
> bottleneck. We need to fix or replace OGNL.
>
> -Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this mess
IL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7856772
Sent from the Struts - Dev mailing list archive at Nabble.com.
--
t; don't
>> > have time to rewrite OGNL myself.)
>> >
>> > In the mean time, we wrote a custom version of OgnlValueStack.
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2
On 12/13/06, Ian Roughley <[EMAIL PROTECTED]> wrote:
Do you have the performance numbers that you can share? I'd really be
interested in them.
There are some interesting numbers here
*
http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html
(be sure to read to the *e
Do you have the performance numbers that you can share? I'd really be
interested in them.
Also, since you've considering JSF and performance is the deciding
faactor, do you have the performance information between s1, s2 and JSF?
/Ian
dice wrote:
The custom OGNLValueStack made little dif
place it with JSP-EL? (I
> don't
> have time to rewrite OGNL myself.)
>
> In the mean time, we wrote a custom version of OgnlValueStack.
>
--
View this message in context:
http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7847866
Sent from
>
--
View this message in context:
http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7847866
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTEC
>
>
--
View this message in context:
http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7847251
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 12/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 12/11/06, dice <[EMAIL PROTECTED]> wrote:
> By my own benchmarking I am finding Struts 2 somewhere between 5-10 times
> slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the
> bottleneck.
There's a similar thread on the
On 12/11/06, dice <[EMAIL PROTECTED]> wrote:
By my own benchmarking I am finding Struts 2 somewhere between 5-10 times
slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the
bottleneck.
There's a similar thread on the webwork dev list:
http://forums.opensymphony.com/threa
Howard, who writes Tapestry, notes the same thing in his framework:
http://tapestryjava.blogspot.com/2006/11/improve-tapestry-performance-with.html
He chose a different way of retrieving simple properties. It supposedly
has jumped his performance a lot. I recommend Struts 2 Committees look
for
We noticed the same thing. Maybe we should replace it with JSP-EL? (I don't
have time to rewrite OGNL myself.)
In the mean time, we wrote a custom version of OgnlValueStack (pasted below)
which optimizes and uses reflection for normal Java expressions; it's an
order of magnitude faster. I think i
been
planned. If so, what timeframe?
--
View this message in context:
http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7825136
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To
46 matches
Mail list logo
