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 compilation algorithm is sacrificing correctness for performance. An implicit requirement on the @For to have homogeneous objects in the loop is confusing and non-obvious. A failover strategy hidden from the users would be great. How hard it would be to say decorate an expression compiled within a For loop in a try/catch that would switch to a generic algorithm on the first ClassCastException? Andrus Andrus Adamchik wrote: > > 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. 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] >> >> >> > > -- View this message in context: http://www.nabble.com/Class-cast-exception-in-ASTChain%2C-Bug-OGNL-11-tf4054151.html#a12163545 Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
