Well, you guys let me know what it is that you want I guess.
Though I'm sure many will not care about the perf increase at all
there are some tapestry users with very large public facing
applications where things like this are a huge bump in response times
- which goes in to all kinds of formulas
I am an open source developer myself and I *love* when the users submit
patches that work or at least create intelligent Jira's :-)
But that's not the point here. Even though there is an OGNL-11 bug report,
this is not a bug. This is a new "feature" of Tapestry 4.1. No matter was
else was said i
Exclude the version that comes with 4.1.2 and fall back to 2.6.7. But, I
think it's the responsibility of us, the users, to iron out the bugs in the
expressionCompiler. I mean it's the least we can do. The benefits far
outweigh the current issues from my perspective and Jesse's more than
willing to
Kevin Menard wrote:
On 8/15/07 10:50 AM, in article [EMAIL PROTECTED], "Andrus
Adamchik" <[EMAIL PROTECTED]> wrote:
Thinking about it some more
This is not the end of the world for our application. We can either skip the
upgrade or indeed force an interface on the objects involved, or avo
This has nothing to do with Tapestry For loops - ognl doesn't deal
with anything tapestry specific when compiling statements
The interface / common object base isn't as bad as it sounds really...
It will correctly traverse up the class tree and cast the statement to
whatever base class/interf
Jesse,
I'd like to start my post by thanking you managing the 4.1 version of
tapestry and for all the recent improvements to ognl.
I imagine that this For loop change was one of the major speed
enhancements in the new ognl version(s). Though, I'm concerned that
this enhancement gives up too muc
On 8/15/07 10:50 AM, in article [EMAIL PROTECTED], "Andrus
Adamchik" <[EMAIL PROTECTED]> wrote:
>
> Thinking about it some more
>
> This is not the end of the world for our application. We can either skip the
> upgrade or indeed force an interface on the objects involved, or avoid
> multi-s
Thinking about it some more
This is not the end of the world for our application. We can either skip the
upgrade or indeed force an interface on the objects involved, or avoid
multi-step property traversal by moving it to Java class.
But at a higher level it seems like the expression comp
Hi Jesse,
Thanks for clarification. I guess we won't be doing the upgrade :-)
Andrus
Jessek wrote:
>
> Without a common interface I don't think these objects will ever be
> compilable in to any kind of native code - so you may never be able to
> upgrade to 4.1 if that is your blocking point.
Without a common interface I don't think these objects will ever be
compilable in to any kind of native code - so you may never be able to
upgrade to 4.1 if that is your blocking point. If it were something
catchable early its possible the statement could fall back to normal
ognl reflection but i
Thanks for the suggestion. I tried the latest ognl build, but the problem is
still there (and in addition I get a bunch of OGNL stack traces in other
places).
Ok, I guess I can't use 4.1.x just yet :-/
Andrus
On 8/14/07, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
>
> I found essentially the
On 8/14/07, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
>
> I found essentially the same problem in a @For loop over a list of objects
> that do not implement any common interface, but (by design) have matching
> method names. Tapestry would try to cast to the class of the first object
> in
> the lo
Hi Jesse,
I found essentially the same problem in a @For loop over a list of objects
that do not implement any common interface, but (by design) have matching
method names. Tapestry would try to cast to the class of the first object in
the loop, instead of using a declared class of the loop varia
Thanks, I've re-opened the bug and will take a look.
On 7/10/07, Damien Uern <[EMAIL PROTECTED]> wrote:
Hello,
I recently upgraded to OGNL 2.7, Tapestry 4.1.2 and am experiencing the
same issue described here http://jira.opensymphony.com/browse/OGNL-11.
The original poster didn't seem to prov
14 matches
Mail list logo
