Actually, I found that I can do what I need to do in beforeRenderTemplate. Bill
On Thu, Aug 14, 2008 at 6:42 PM, Bill Holloway <[EMAIL PROTECTED]> wrote: > 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 > -- Bill @ PeoplePad --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]