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 much in terms of flexibility. A For loop is one of the most fundamental things in programming. Try to imagine if a new version of Java was release and one of the requirements would be that you'd need to implement a common interface for each object you needed to iterate over. I think most people would be scratching their head. Ultimately, the the decision on how to handle this will be up to you. I'm looking at this from a 5,000ft view and don't have all the details. Thanks again for your work. Cheers, Eric On 8/15/07, Jesse Kuhnert <[EMAIL PROTECTED]> 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. If it were something > catchable early its possible the statement could fall back to normal > ognl reflection but in this case the statements are getting compiled > against one object type successfully and failing later in the native > code when a new class type is used. > > In Summary: Find a way to have a common interface for these object > properties or don't plan on upgrading anytime soon... > > On 8/15/07, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > > > 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 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 variable. This > > > stalled our upgrade to 4.1.2. > > > I traced it down to HiveMindExpressionCompiler.generateGetter(..), but I > > > am > > > still not sure whether this is a Tapestry or OGNL bug (or rather where the > > > solution should be implemented). BTW where OGNL posts its releases now? I > > > couldn't find anything beyond 2.6.7. > > > I wonder if you had a chance to look into this issue? > > > > > > > Just by reading this, I'm 95% sure it's a OGNL issue. Jesse publishes new > > OGNL snapshots on his repository ( > > http://opencomponentry.com/repository/m2-snapshot-repo/ognl/ognl/2.7.1-SNAPSHOT/). > > Try excluding the OGNL 2.7 that comes with 4.1.2 and use one of the newer > > 2.7.1 snapshots (2.7.1-20070723.185910-9 for example solved lots of issue > > for us). Though I'm still tracking down yet another, similar > > ClassCastException one even in the latest. > > > > Kalle > > > > > > > > -- > > View this message in context: > > http://www.nabble.com/Class-cast-exception-in-ASTChain%2C-Bug-OGNL-11-tf4054151.html#a12162563 > > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Jesse Kuhnert > Tapestry/Dojo team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
