You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2007/08/14 22:12:32 UTC
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 <da...@synect.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Changing locale within OnActivate event
Posted by Jesse Kuhnert <jk...@gmail.com>.
If you build a "shadow service" or similar sort of infrastructure
related thing you can always intercept the call before pages are
resolved / loaded / etc if you know ahead of time that you are going
to want to change the locale in some way. (ie if it's architecture /
infrastructure related and not one off pieces of functionality )
On 8/17/07, Doug Hauge <do...@lithium.com> wrote:
> I was afraid that would be the answer (I couldn't see any other way
> after looking at the code). I was wanting to avoid having to add
> duplicate redirection logic to each page, but I'll give it a try and see
> how it works. Thanks for the response.
>
> Doug
>
> > -----Original Message-----
> > From: Jesse Kuhnert [mailto:jkuhnert@gmail.com]
> > Sent: Tuesday, August 14, 2007 7:22 PM
> > To: Tapestry users
> > Subject: Re: T5: Changing locale within OnActivate event
> >
> > If it's anything like T4 you'll have to either do a redirect back to
> > the same page or whatever mechanism is in place to "make a page
> > active" somehow and have it do that to the same page.
> >
> > All the i18n stuff probably happens in the very beginning while
> > setting up the page/components/resources so it has to start over if
> > you want to change locales. I'm sure you know more than I do about
> > redirects/page activations in T5 though.
> >
> > On 8/14/07, Doug Hauge <do...@lithium.com> wrote:
> > > In several of our pages, the default locale we want to use for
> > messages
> > > depends on its activation context. We tried updating the locale
> using
> > > 'ThreadLocale' from within the activate event handler, but it seems
> > that
> > > this is too late, for the page has already been loaded and all
> > messages
> > > in the template resolved using whatever locale was in effect at the
> > time
> > > of loading. Is there some way we can force the messages to be
> > reloaded
> > > after setting the thread locale in the activate event handler, or is
> > > there some point before the page is loaded at which we can access
> the
> > > page class and the activation context in order to set the locale?
> > >
> > > Thanks,
> > > Doug
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: T5: Changing locale within OnActivate event
Posted by Doug Hauge <do...@lithium.com>.
I was afraid that would be the answer (I couldn't see any other way
after looking at the code). I was wanting to avoid having to add
duplicate redirection logic to each page, but I'll give it a try and see
how it works. Thanks for the response.
Doug
> -----Original Message-----
> From: Jesse Kuhnert [mailto:jkuhnert@gmail.com]
> Sent: Tuesday, August 14, 2007 7:22 PM
> To: Tapestry users
> Subject: Re: T5: Changing locale within OnActivate event
>
> If it's anything like T4 you'll have to either do a redirect back to
> the same page or whatever mechanism is in place to "make a page
> active" somehow and have it do that to the same page.
>
> All the i18n stuff probably happens in the very beginning while
> setting up the page/components/resources so it has to start over if
> you want to change locales. I'm sure you know more than I do about
> redirects/page activations in T5 though.
>
> On 8/14/07, Doug Hauge <do...@lithium.com> wrote:
> > In several of our pages, the default locale we want to use for
> messages
> > depends on its activation context. We tried updating the locale
using
> > 'ThreadLocale' from within the activate event handler, but it seems
> that
> > this is too late, for the page has already been loaded and all
> messages
> > in the template resolved using whatever locale was in effect at the
> time
> > of loading. Is there some way we can force the messages to be
> reloaded
> > after setting the thread locale in the activate event handler, or is
> > there some point before the page is loaded at which we can access
the
> > page class and the activation context in order to set the locale?
> >
> > Thanks,
> > Doug
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Changing locale within OnActivate event
Posted by Jesse Kuhnert <jk...@gmail.com>.
If it's anything like T4 you'll have to either do a redirect back to
the same page or whatever mechanism is in place to "make a page
active" somehow and have it do that to the same page.
All the i18n stuff probably happens in the very beginning while
setting up the page/components/resources so it has to start over if
you want to change locales. I'm sure you know more than I do about
redirects/page activations in T5 though.
On 8/14/07, Doug Hauge <do...@lithium.com> wrote:
> In several of our pages, the default locale we want to use for messages
> depends on its activation context. We tried updating the locale using
> 'ThreadLocale' from within the activate event handler, but it seems that
> this is too late, for the page has already been loaded and all messages
> in the template resolved using whatever locale was in effect at the time
> of loading. Is there some way we can force the messages to be reloaded
> after setting the thread locale in the activate event handler, or is
> there some point before the page is loaded at which we can access the
> page class and the activation context in order to set the locale?
>
> Thanks,
> Doug
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
T5: Changing locale within OnActivate event
Posted by Doug Hauge <do...@lithium.com>.
In several of our pages, the default locale we want to use for messages
depends on its activation context. We tried updating the locale using
'ThreadLocale' from within the activate event handler, but it seems that
this is too late, for the page has already been loaded and all messages
in the template resolved using whatever locale was in effect at the time
of loading. Is there some way we can force the messages to be reloaded
after setting the thread locale in the activate event handler, or is
there some point before the page is loaded at which we can access the
page class and the activation context in order to set the locale?
Thanks,
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Class cast exception in ASTChain, Bug OGNL-11
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <an...@objectstyle.org> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Class cast exception in ASTChain, Bug OGNL-11
Posted by Andrus Adamchik <an...@objectstyle.org>.
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Class cast exception in ASTChain, Bug OGNL-11
Posted by Kalle Korhonen <ka...@gmail.com>.
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 <da...@synect.com> wrote:
>
> Kevin Menard wrote:
> > On 8/15/07 10:50 AM, in article 12163545.post@talk.nabble.com, "Andrus
> > Adamchik" <an...@objectstyle.org> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Class cast exception in ASTChain, Bug OGNL-11
Posted by Damien Uern <da...@synect.com>.
Kevin Menard wrote:
> On 8/15/07 10:50 AM, in article 12163545.post@talk.nabble.com, "Andrus
> Adamchik" <an...@objectstyle.org> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Class cast exception in ASTChain, Bug OGNL-11
Posted by Kevin Menard <km...@servprise.com>.
On 8/15/07 10:50 AM, in article 12163545.post@talk.nabble.com, "Andrus
Adamchik" <an...@objectstyle.org> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Class cast exception in ASTChain, Bug OGNL-11
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <an...@objectstyle.org> 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 <an...@objectstyle.org> 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: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Class cast exception in ASTChain, Bug OGNL-11
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <an...@objectstyle.org> 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 <an...@objectstyle.org> 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Class cast exception in ASTChain, Bug OGNL-11
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <er...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Class cast exception in ASTChain, Bug OGNL-11
Posted by Eric Schneider <er...@gmail.com>.
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 <jk...@gmail.com> 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 <an...@objectstyle.org> 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 <an...@objectstyle.org> 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Class cast exception in ASTChain, Bug OGNL-11
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <an...@objectstyle.org> 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 <an...@objectstyle.org> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Class cast exception in ASTChain, Bug OGNL-11
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <an...@objectstyle.org> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Class cast exception in ASTChain, Bug OGNL-11
Posted by Kalle Korhonen <ka...@gmail.com>.
On 8/14/07, Andrus Adamchik <an...@objectstyle.org> 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 <da...@synect.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>