Back to this one again! I have two components. One inherits from Grid; the other, GridRows. My GridRows subclass has a setupRender and beginRender.
If either one has arguments (MarkupWriter w, Event e), I get a java.lang.AbstractMethodError with the stack trace listed at the bottom of this message (although line numbers are different in classes followed by $, as you can imagine). But interestingly, my subclass beginRender is never called, under any circumstances even though it causes the exception with the prior arguments! If I give setupRender just a MarkupWriter as an argument, it is properly called. Could the lack of a call into my subclass' beginRender be due to the fact that GridRows' beginRender returns a boolean? This all started, BTW, after my 5.0.13 upgrade :) I sure do need my subclass' beginRender invoked. Other ideas? Stacktrace: * org.apache.tapestry5.internal.structure.ComponentPageElementImpl$11$1.run(ComponentPageElementImpl.java:334) * org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:899) * org.apache.tapestry5.internal.structure.ComponentPageElementImpl.access$200(ComponentPageElementImpl.java:50) * org.apache.tapestry5.internal.structure.ComponentPageElementImpl$11.render(ComponentPageElementImpl.java:338) * org.apache.tapestry5.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:68) * org.apache.tapestry5.internal.services.PageRenderQueueImpl.render(PageRenderQueueImpl.java:108) * org.apache.tapestry5.services.TapestryModule$15.renderMarkup(TapestryModule.java:1128) * org.apache.tapestry5.services.TapestryModule$24.renderMarkup(TapestryModule.java:1472) * org.apache.tapestry5.services.TapestryModule$23.renderMarkup(TapestryModule.java:1453) * org.apache.tapestry5.services.TapestryModule$22.renderMarkup(TapestryModule.java:1435) * org.apache.tapestry5.services.TapestryModule$21.renderMarkup(TapestryModule.java:1415) * org.apache.tapestry5.internal.services.PageMarkupRendererImpl.renderPageMarkup(PageMarkupRendererImpl.java:64) * org.apache.tapestry5.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:57) * org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:59) * org.apache.tapestry5.services.TapestryModule$29.handle(TapestryModule.java:1653) * org.apache.tapestry5.internal.services.PageRenderDispatcher.process(PageRenderDispatcher.java:97) * org.apache.tapestry5.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:73) * org.apache.tapestry5.services.TapestryModule$13.service(TapestryModule.java:953) * org.apache.tapestry5.internal.services.LocalizationFilter.service(LocalizationFilter.java:42) * org.apache.tapestry5.services.TapestryModule$2.service(TapestryModule.java:586) * org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26) * org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:79) * org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:93) * org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:84) * org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:83) * org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:106) * org.apache.tapestry5.services.TapestryModule$12.service(TapestryModule.java:933) * org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:44) * org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62) * org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:177) * org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) * org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) * org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) * org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) * org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) * org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) * org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) * org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) * org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) * org.mortbay.jetty.Server.handle(Server.java:313) * org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506) * org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830) * org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) * org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) * org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) * org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) * org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) On Mon, Jun 23, 2008 at 8:04 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > So the sub-class setupRender() overrides the base-class setupRender()? > > The method setupRender() is still invoked at the appropriate time. The > difference is that it is not invoked twice, as it was before 5.0.13. > > In coding terms, what happens is that Tapestry provides an > implementation of the method void setupRender(MarkupWriter writer, > Event event) in the base class that invokes the base class' > setupRender() method. > > The sub class also gets an implementation of void > setupRender(MarkupWriter writer, Event event) ... the first thing it > does is invoke the super implementation. > > In 5.0.11 and earlier, the subclass implementation of setupRender(...) > would invoke the subclass' override of setupRender(). Thus, the base > class would invoke it once, then the subclass would invoke it again. > > In 5.0.13 this was changed so that the subclass implementation of > setupRender(...) would *NOT* invoke the setupRender() method; because > setupRender() overrides a base class method; the base class is > responsible for invoking it. This is what that documentation is > referring to when it mentions the "timing" of the method invocation. > > Thus if you want the base classes' implementation to be invoked, the > method override must call super.setupRender(). > > Hope this is a bit clearer. > > Then end result is that overriding render phase methods should now fit > better, conceptually, with how method overrides work in ordinary Java, > which is a good thing. > > > On Fri, Jun 20, 2008 at 5:55 PM, Bill Holloway <[EMAIL PROTECTED]> wrote: >> The JIRA on this states that the "overridden method will be invoked >> only by the parent class, not the subclass." So I have a page that >> inherits from a base page class. Both have setupRender() on them. I >> have no code in the parent class that actually invokes setupRender, >> but I hope it will be invoked. Will it? >> >> -- >> Bill @ PeoplePad >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Bill @ PeoplePad --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]