Re: Class cast exception in ASTChain, Bug OGNL-11
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 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? This is an interesting idea that I think would work well. We ran into problems ourselves. OGNL would dump out a ton of output to the console, but then fallback to an expression that would work. I think it would be good to allow users to turn off expression compilation, i.e. revert to the old way that OGNL worked. Is this possible? It would allow us to continue with 4.1, without having all our expressions break on us. For me it was only 2 parts of the app that needed fixing, but I can imagine loads of people relying on the reflective nature of OGNL when constructing their pages... Damien -- Damien Uern Online Applications Developer Synect Online Solutions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Class cast exception in ASTChain, Bug OGNL-11
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 fix any emerging issues. Everybody wants it, but if no one but him is willing to put down some effort, it'll never be finished. Kalle On 8/16/07, Damien Uern [EMAIL PROTECTED] wrote: 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 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? This is an interesting idea that I think would work well. We ran into problems ourselves. OGNL would dump out a ton of output to the console, but then fallback to an expression that would work. I think it would be good to allow users to turn off expression compilation, i.e. revert to the old way that OGNL worked. Is this possible? It would allow us to continue with 4.1, without having all our expressions break on us. For me it was only 2 parts of the app that needed fixing, but I can imagine loads of people relying on the reflective nature of OGNL when constructing their pages... Damien -- Damien Uern Online Applications Developer Synect Online Solutions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Class cast exception in ASTChain, Bug OGNL-11
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 in this thread, there is clearly a consensus between Tapestry commiters and users about what is causing it. The disagreement is what (if anything) should be done about that. So it will not help if I open another bug report saying my @For loop is broken - it will not get fixed unless we all agree that 4.0 scriptable behavior was a good thing :-) Cheers, Andrus Kalle Korhonen-2 wrote: 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 fix any emerging issues. Everybody wants it, but if no one but him is willing to put down some effort, it'll never be finished. Kalle -- View this message in context: http://www.nabble.com/Class-cast-exception-in-ASTChain%2C-Bug-OGNL-11-tf4054151.html#a12183517 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Class cast exception in ASTChain, Bug OGNL-11
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 that eventually come out to happier users/ less money or similar... maybe If enough people want it I guess some kind of don't ever compile option could be made configurable somehow. On 8/16/07, Andrus Adamchik [EMAIL PROTECTED] wrote: 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 in this thread, there is clearly a consensus between Tapestry commiters and users about what is causing it. The disagreement is what (if anything) should be done about that. So it will not help if I open another bug report saying my @For loop is broken - it will not get fixed unless we all agree that 4.0 scriptable behavior was a good thing :-) Cheers, Andrus Kalle Korhonen-2 wrote: 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 fix any emerging issues. Everybody wants it, but if no one but him is willing to put down some effort, it'll never be finished. Kalle -- View this message in context: http://www.nabble.com/Class-cast-exception-in-ASTChain%2C-Bug-OGNL-11-tf4054151.html#a12183517 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]
Re: Class cast exception in ASTChain, Bug OGNL-11
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]
Re: Class cast exception in ASTChain, Bug OGNL-11
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]
Re: Class cast exception in ASTChain, Bug OGNL-11
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#a12163182 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Class cast exception in ASTChain, Bug OGNL-11
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]
Re: Class cast exception in ASTChain, Bug OGNL-11
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-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? This is an interesting idea that I think would work well. We ran into problems ourselves. OGNL would dump out a ton of output to the console, but then fallback to an expression that would work. For example, our Border component had a lot of ognl:page.something, where getSomething() is not defined in the IPage interface. Despite complaining, everything worked. In order to get rid of the logging, I had to add a class file for the Border, add a new getAppPage() that did little more than cast the getPage() call to an app-specific base page, and then update all my OGNL expressions to use that. It wasn't the end of the world, but a lot of additional overhead to prevent logging of failures if the thing is going to work anyway . . . -- Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Class cast exception in ASTChain, Bug OGNL-11
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]
Re: Class cast exception in ASTChain, Bug OGNL-11
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/interface the method being invoked is ultimately declared in. For instance - in Kevins case (the Border component calling page.something on lots of different pages) could have easily been solved by having either all pages extend one base class or just declaring a common page interface class on them. Without having ~something~ to cast to though compilation is impossible. Of course - if it's just not casting to the right class that's a completely different problem and probably has an easy fix somewhere. Much like this mailing list though, I don't really fix ognl bugs unless there is a jira issue created at http://jira.opensymphony.com/browse/OGNL with the specific class types / ognl versions / etc involved and the other normal bug reporting goodies. I'm genuinely interested in fixing all of these problems either way - but if people don't put enough effort in to logging the jira tickets for them with enough information for me to cobble together an ognl test case then there's nothing I can do but shrug my shoulders when people mention having problems. On 8/15/07, Eric Schneider [EMAIL PROTECTED] wrote: 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 snipped -- 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]
Re: Class cast exception in ASTChain, Bug OGNL-11
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 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?
Thanks
Andrus Adamchik
Jessek wrote:
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 provide much information, so I have
added a comment to that bug describing the issue I am having. I'm not
sure if I need to open a new bug in order for somebody to look at it.
I will reproduce my comment here for convenience, any help/workarounds
would be most appreciated:
I have just updated from Tapestry 4.0 to 4.1.2 with OGNL 2.7 and I am
having this same class cast exception on an ASTChain generated class,
stack trace is here:
Caused by: java.lang.ClassCastException:
com.jigsawpublications.common.tapestry.menu.ActionLinkNode
at $ASTChain_113aed5c33f.get($ASTChain_113aed5c33f.java)
at
org.apache.tapestry.services.impl.ExpressionEvaluatorImpl.read(
ExpressionEvaluatorImpl.java:142)
What we have in the component template looks like this:
li
parameters=ognl:getNodeIter().getAction()
href=# title=ognl:nodeIter.title
/li
The nodeIter property on the component class is declared as follows:
public IMenuNode getNodeIter() { }
So what we have here is a list of objects all implementing this
interface IMenuNode, and getNodeIter() returns the current iteration as
set by the tapestry @For component. The class cast exception was on an
ActionLinkNode which implements that interface. Other classes are
PageLinkNode, RootNode and MenuNode. The *only* one that causes a
problem seems to be the above @Block component, as another block:
li
# page=ognl:nodeIter.page
/li
renders fine without any issue (these other blocks occur earlier in the
page than the ActionLinkBlock). If I change the actionLink block to be
the following (i.e. change the offending ognl expressions):
li
parameters=ognl:'action'
href=# title=ognl:'title'
/li
Then I do not get an exception during the page render. This worked fine
with the previous version of ognl we were using (2.6.7).
Please let me know if you require more information.
Regards,
Damien Uern
--
Damien Uern
Online Applications Developer
Synect Online Solutions
http://www.synect.com
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
--
View this message in context:
http://www.nabble.com/Class-cast-exception-in-ASTChain%2C-Bug-OGNL-11-tf4054151.html#a12151415
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Class cast exception in ASTChain, Bug OGNL-11
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
Jessek wrote:
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 provide much information, so I have
added a comment to that bug describing the issue I am having. I'm not
sure if I need to open a new bug in order for somebody to look at it.
I will reproduce my comment here for convenience, any help/workarounds
would be most appreciated:
I have just updated from Tapestry 4.0 to 4.1.2 with OGNL 2.7 and I am
having this same class cast exception on an ASTChain generated class,
stack trace is here:
Caused by: java.lang.ClassCastException:
com.jigsawpublications.common.tapestry.menu.ActionLinkNode
at $ASTChain_113aed5c33f.get($ASTChain_113aed5c33f.java)
at
org.apache.tapestry.services.impl.ExpressionEvaluatorImpl.read(
ExpressionEvaluatorImpl.java:142)
What we have in the component template looks like this:
li
parameters=ognl:getNodeIter().getAction()
href=# title=ognl:nodeIter.title
/li
The nodeIter property on the component class is declared as follows:
public IMenuNode getNodeIter() { }
So what we have here is a list of objects all implementing this
interface IMenuNode, and getNodeIter() returns the current iteration as
set by the tapestry @For component. The class cast exception was on an
ActionLinkNode which implements that interface. Other classes are
PageLinkNode, RootNode and MenuNode. The *only* one that causes a
problem seems to be the above @Block component, as another block:
li
# page=ognl:nodeIter.page
/li
renders fine without any issue (these other blocks occur earlier in the
page than the ActionLinkBlock). If I change the actionLink block to be
the following (i.e. change the offending ognl expressions):
li
parameters=ognl:'action'
href=# title=ognl:'title'
/li
Then I do not get an exception during the page render. This worked fine
with the previous version of ognl we were using (2.6.7).
Please let me know if you require more information.
Regards,
Damien Uern
--
Damien Uern
Online Applications Developer
Synect Online Solutions
http://www.synect.com
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
--
View this message in context:
http://www.nabble.com/Class-cast-exception-in-ASTChain%2C-Bug-OGNL-11-tf4054151.html#a12151415
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Class cast exception in ASTChain, Bug OGNL-11
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 provide much information, so I have
added a comment to that bug describing the issue I am having. I'm not
sure if I need to open a new bug in order for somebody to look at it.
I will reproduce my comment here for convenience, any help/workarounds
would be most appreciated:
I have just updated from Tapestry 4.0 to 4.1.2 with OGNL 2.7 and I am
having this same class cast exception on an ASTChain generated class,
stack trace is here:
Caused by: java.lang.ClassCastException:
com.jigsawpublications.common.tapestry.menu.ActionLinkNode
at $ASTChain_113aed5c33f.get($ASTChain_113aed5c33f.java)
at
org.apache.tapestry.services.impl.ExpressionEvaluatorImpl.read(
ExpressionEvaluatorImpl.java:142)
What we have in the component template looks like this:
span jwcid=[EMAIL PROTECTED]
li
a jwcid=@DirectLink listener=listener:callParentAction
parameters=ognl:getNodeIter().getAction()
href=# title=ognl:nodeIter.title
span jwcid=@Insert value=ognl:nodeIter.title /
/a
/li
/span
The nodeIter property on the component class is declared as follows:
public IMenuNode getNodeIter() { }
So what we have here is a list of objects all implementing this
interface IMenuNode, and getNodeIter() returns the current iteration as
set by the tapestry @For component. The class cast exception was on an
ActionLinkNode which implements that interface. Other classes are
PageLinkNode, RootNode and MenuNode. The *only* one that causes a
problem seems to be the above @Block component, as another block:
span jwcid=[EMAIL PROTECTED]
li
a jwcid=@PageLink href=# title=ognl:nodeIter.title
page=ognl:nodeIter.page
span jwcid=@Insert value=ognl:nodeIter.title /
/a
/li
/span
renders fine without any issue (these other blocks occur earlier in the
page than the ActionLinkBlock). If I change the actionLink block to be
the following (i.e. change the offending ognl expressions):
span jwcid=[EMAIL PROTECTED]
li
a jwcid=@DirectLink listener=listener:callParentAction
parameters=ognl:'action'
href=# title=ognl:'title'
span jwcid=@Insert value=ognl:'title' /
/a
/li
/span
Then I do not get an exception during the page render. This worked fine
with the previous version of ognl we were using (2.6.7).
Please let me know if you require more information.
Regards,
Damien Uern
--
Damien Uern
Online Applications Developer
Synect Online Solutions
http://www.synect.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
Class cast exception in ASTChain, Bug OGNL-11
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 provide much information, so I have
added a comment to that bug describing the issue I am having. I'm not
sure if I need to open a new bug in order for somebody to look at it.
I will reproduce my comment here for convenience, any help/workarounds
would be most appreciated:
I have just updated from Tapestry 4.0 to 4.1.2 with OGNL 2.7 and I am
having this same class cast exception on an ASTChain generated class,
stack trace is here:
Caused by: java.lang.ClassCastException:
com.jigsawpublications.common.tapestry.menu.ActionLinkNode
at $ASTChain_113aed5c33f.get($ASTChain_113aed5c33f.java)
at
org.apache.tapestry.services.impl.ExpressionEvaluatorImpl.read(ExpressionEvaluatorImpl.java:142)
What we have in the component template looks like this:
span jwcid=[EMAIL PROTECTED]
li
a jwcid=@DirectLink listener=listener:callParentAction
parameters=ognl:getNodeIter().getAction()
href=# title=ognl:nodeIter.title
span jwcid=@Insert value=ognl:nodeIter.title /
/a
/li
/span
The nodeIter property on the component class is declared as follows:
public IMenuNode getNodeIter() { }
So what we have here is a list of objects all implementing this
interface IMenuNode, and getNodeIter() returns the current iteration as
set by the tapestry @For component. The class cast exception was on an
ActionLinkNode which implements that interface. Other classes are
PageLinkNode, RootNode and MenuNode. The *only* one that causes a
problem seems to be the above @Block component, as another block:
span jwcid=[EMAIL PROTECTED]
li
a jwcid=@PageLink href=# title=ognl:nodeIter.title
page=ognl:nodeIter.page
span jwcid=@Insert value=ognl:nodeIter.title /
/a
/li
/span
renders fine without any issue (these other blocks occur earlier in the
page than the ActionLinkBlock). If I change the actionLink block to be
the following (i.e. change the offending ognl expressions):
span jwcid=[EMAIL PROTECTED]
li
a jwcid=@DirectLink listener=listener:callParentAction
parameters=ognl:'action'
href=# title=ognl:'title'
span jwcid=@Insert value=ognl:'title' /
/a
/li
/span
Then I do not get an exception during the page render. This worked fine
with the previous version of ognl we were using (2.6.7).
Please let me know if you require more information.
Regards,
Damien Uern
--
Damien Uern
Online Applications Developer
Synect Online Solutions
http://www.synect.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
