--- 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
Probably a little early to say for sure, but I don't think anyone needs to
worry about ognl performance anymore. I'm sure the right people will update
everyone when the time is right.
husted wrote:
>
> Did you try using the simple theme with Struts 2.0.1 in the benchmarks?
>
> -Ted.
>
> On 1
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
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 like OGNL for some reason. If you can
> create a patch to make that happen, I would consider it
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
Why do you think it would be so terribly difficult? What does MVEL not
support that is currently supported by OGNL that would not be fixable by a
few tweaks to MVEL's syntax?
Generally, MVEL's API architecture follows the same pattern as OGNL,
supports type coercion, conversion, projections, et
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
I'm not sure what you mean by "property accessor". The Tapestry community is
just as tied down/used to using ognl expressions as much as any other.
Tapestry-prop is a side project Howard created for very specific consulting
engagements where the performance overhead of ognl was unacceptable for so
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 on "expressions" in addition to properties to
accomplish tasks.
That being said, my project (MVEL) stands willing to step
OGNL isn't a subproject of Struts, and so there's not anything we do
about changing OGNL from here. AFAIK, everyone in the Struts and
WebWork projects have been treating OGNL as black box.
The place to start would be by posting to the OGNL developers forum.
* http://forums.opensymphony.com/forum
I'm still not getting all of the hand wringing that is going on in this
thread about ognl. There is what I think a perfectly reasonable solution
that will help finish up those last remaining bits that ognl needs to really
be production ready.
Despite whatever we want to call it you could theoret
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
They are my stats Ted. The stats are posted below along with my sample JSP
code. I only tried the textfield tag but looking at the ftl and vm files for
the other tags I can't see how the results would be any different.
Perhaps an interim solution could be to remove the use of OGNL from core
func
Yes, it does certainly "feel" easier to just go straight to bytecode. (well,
not exactly...I mean you're still basically just passing a String with java
code in it to javassist) At least it wouldn't involve as much hashing lookup
kind of operations to complete.
I'd still be open to doing whateve
I wouldn't jump straight to a bytecode solution, there's no reason it should
be that much faster than a well-designed plain Java solution.
Bob
On 12/13/06, Jessek <[EMAIL PROTECTED]> wrote:
Last time I'll interrupt your normal dev cycle I promise.
Since it seems we are both equally screwed i
Last time I'll interrupt your normal dev cycle I promise.
Since it seems we are both equally screwed in the short term by any non ognl
solution it might be beneficial to consider just fixing it. I'm very
familiar with javassist bytecode manipulation and vaguely familiar with the
internal working
You may want to take a peek at the svn source tree in t5. It has a slightly
better version of these semantics. (though I doubt you'll find any advanced
sort of expr support like ognl might provde)
That being said, 1ms or so is all it takes to render a lot of tapestry
pages, so I wouldn't discount
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
I'm not sure I'd worry about it. Howard's post said it only made 1ms
difference.
Bob
On 12/12/06, dice <[EMAIL PROTECTED]> wrote:
The custom OGNLValueStack made little difference. AFAIK, the majority of
the
OGNL calls are dealing with the tag parameters in the tag templates which
are not simp
The custom OGNLValueStack made little difference. AFAIK, the majority of the
OGNL calls are dealing with the tag parameters in the tag templates which
are not simple java properties. It's a pity. I was looking forward to using
Struts 2 on our next major project but much like JSF it is too risky fr
Would you guys be "morally offended" if I lifted this code? (or potentially
did, need to see how amenable the two are first, but it shouldn't be too
hard)
I mean, I know licensing is blah blah and all , but you know...Maybe it's
not "right".
Bob Lee wrote:
>
>
> In the mean time, we wrote a
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
45 matches
Mail list logo
