[Stripes-users] NPE being thrown when using dynamic attributes in stripes layout-render tags with Freemarker templates
Only when using Freemarker templates instead of JSP pages, I am running into an NPE exception that is raised when I use dynamic attributes on Stripes layout-render tags. The stack trace indicates: Caused by: java.lang.NullPointerException at net.sourceforge.stripes.tag.layout.LayoutRenderTag.setDynamicAttribute(LayoutRenderTag.java:101) The problem is that the context property of the LayoutRenderTag class is not initialized before the call is made to the setDynamicAttribute(String, String, Object) method. I can hack together a fix for this by calling the initialize() method of the LayoutRenderTag class whenever the context is found to be null at the start of the setDynamicAttribute(String, String, Object) method. That works but it makes me nervous. I am not clear on why the setName method of the LayoutRenderTag class is not being called first and I am not confident that the initialization will always work when required. This has only become a problem for me since exploring the implications of migrating to Stripes 1.3.7 and Freemarker 2.3.19 from Stripes 1.3.6 and Freemarker 2.3.17. Regards Geoff Shuetrim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes layout tags causing Unicode U+0000 characters to be added to my output HTML
I should also mention, that the problem does not occur unless I am using Freemarker templates. Using JSP pages, I do not have any problems with the \u characters. Geoff Shuetrim On 3 June 2012 16:59, Geoff Shuetrim wrote: > I have tracked down the source of the U+ characters in the Stripes > code base. They are being inserted into the output generated by the > LayoutWriter class, when changing whether the "Silent" status of the > writer. I am not sure quite what that status affects, but during the > toggling of the silent status, the setSilent(boolean, PageContext) method > includes the following statement: > > pageContext.getOut().write(TOGGLE); > > The value of TOGGLE is 0, which the writer inserts into the UTF-8 document > as \u. > > The documentation indicates that TOGGLE is the control character that, > when encountered in the output stream, toggles the silent state. > > If I comment out that statement, then the problematic \u characters do > not appear in my HTML output and so software, like the Facebook crawler, is > able to understand my page content. I could change the character to > something else that is problematic in HTML 5 pages (The > http://html5.validator.nu/ picks them up as a problem.) but I am not sure > what could be used that might not already occur in a page for other > reasons, signaling a "toggle" when one is not appropriate. > > There do not appear to be any other untoward side effects for my site that > result from eliminating this character insertion but making this kind of > change gives me concerns given that I still do not really understand what > the silent and non-silent states imply. > > Some guidance on what the TOGGLE character is doing for me would be really > helpful at this stage. > > Thanks for any thoughts on this issue. > > Geoff Shuetrim > > Background information: > > I have been doing my testing using the source code for Stripes release > 1.3.7 and Freemarker 2.3.19 and using a Tomcat 6 server. The combination > of Stripes 1.3.7 and Freemarker 2.3.19 seems to also raise another problem > in relation to dynamic attributes on the Stripes layout-render tag but I > will deal with that in a separate email. > > > > On 29 May 2012 12:38, Geoff Shuetrim wrote: > >> I have only recently noticed that when I use Stripes layout tags, I am >> getting unexpected U+ characters added to the pages where the stripes >> layout tags were. In a hex editor, these characters are 00. >> >> You can see (or actually you need an editor like emacs to kind of see) >> these characters if you look at the page source for >> http://www.gaiaguide.info/do/Hierarchy >> >> That page is running on Stripes 1.5.6 but in a test environment I can >> replicate the generation of these characters with the latest versions of >> Stripes and Freemarker. >> >> These characters are causing me problems with page scrapers like that >> used by Facebook, which encounter the characters and then decide that they >> cannot see the page (and so links shared from the site get no useful >> information added to them by Facebook). >> >> You can see this by feeding the example URL to: >> >> http://developers.facebook.com/tools/debug >> >> and to: >> >> http://html5.validator.nu/ >> >> This HTML5 validator picks out the U+ characters clearly. >> >> A working page on the same server is at >> http://www.gaiaguide.info/Test.jsp >> >> Any pointers to the parts of the Stripes source where I can start to look >> for how these are being generated would be much appreciated. >> >> Thanks >> >> Geoff Shuetrim >> >> > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes layout tags causing Unicode U+0000 characters to be added to my output HTML
I have tracked down the source of the U+ characters in the Stripes code base. They are being inserted into the output generated by the LayoutWriter class, when changing whether the "Silent" status of the writer. I am not sure quite what that status affects, but during the toggling of the silent status, the setSilent(boolean, PageContext) method includes the following statement: pageContext.getOut().write(TOGGLE); The value of TOGGLE is 0, which the writer inserts into the UTF-8 document as \u. The documentation indicates that TOGGLE is the control character that, when encountered in the output stream, toggles the silent state. If I comment out that statement, then the problematic \u characters do not appear in my HTML output and so software, like the Facebook crawler, is able to understand my page content. I could change the character to something else that is problematic in HTML 5 pages (The http://html5.validator.nu/ picks them up as a problem.) but I am not sure what could be used that might not already occur in a page for other reasons, signaling a "toggle" when one is not appropriate. There do not appear to be any other untoward side effects for my site that result from eliminating this character insertion but making this kind of change gives me concerns given that I still do not really understand what the silent and non-silent states imply. Some guidance on what the TOGGLE character is doing for me would be really helpful at this stage. Thanks for any thoughts on this issue. Geoff Shuetrim Background information: I have been doing my testing using the source code for Stripes release 1.3.7 and Freemarker 2.3.19 and using a Tomcat 6 server. The combination of Stripes 1.3.7 and Freemarker 2.3.19 seems to also raise another problem in relation to dynamic attributes on the Stripes layout-render tag but I will deal with that in a separate email. On 29 May 2012 12:38, Geoff Shuetrim wrote: > I have only recently noticed that when I use Stripes layout tags, I am > getting unexpected U+ characters added to the pages where the stripes > layout tags were. In a hex editor, these characters are 00. > > You can see (or actually you need an editor like emacs to kind of see) > these characters if you look at the page source for > http://www.gaiaguide.info/do/Hierarchy > > That page is running on Stripes 1.5.6 but in a test environment I can > replicate the generation of these characters with the latest versions of > Stripes and Freemarker. > > These characters are causing me problems with page scrapers like that used > by Facebook, which encounter the characters and then decide that they > cannot see the page (and so links shared from the site get no useful > information added to them by Facebook). > > You can see this by feeding the example URL to: > > http://developers.facebook.com/tools/debug > > and to: > > http://html5.validator.nu/ > > This HTML5 validator picks out the U+ characters clearly. > > A working page on the same server is at http://www.gaiaguide.info/Test.jsp > > Any pointers to the parts of the Stripes source where I can start to look > for how these are being generated would be much appreciated. > > Thanks > > Geoff Shuetrim > > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Stripes layout tags causing Unicode U+0000 characters to be added to my output HTML
I have only recently noticed that when I use Stripes layout tags, I am getting unexpected U+ characters added to the pages where the stripes layout tags were. In a hex editor, these characters are 00. You can see (or actually you need an editor like emacs to kind of see) these characters if you look at the page source for http://www.gaiaguide.info/do/Hierarchy That page is running on Stripes 1.5.6 but in a test environment I can replicate the generation of these characters with the latest versions of Stripes and Freemarker. These characters are causing me problems with page scrapers like that used by Facebook, which encounter the characters and then decide that they cannot see the page (and so links shared from the site get no useful information added to them by Facebook). You can see this by feeding the example URL to: http://developers.facebook.com/tools/debug and to: http://html5.validator.nu/ This HTML5 validator picks out the U+ characters clearly. A working page on the same server is at http://www.gaiaguide.info/Test.jsp Any pointers to the parts of the Stripes source where I can start to look for how these are being generated would be much appreciated. Thanks Geoff Shuetrim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Indexed properties: what is happening under the hood when adding a new item to a list indexed property?
I am working with the latest version of Stripes. I am trying to use indexed properties in a form where users are allowed to add new items to the end of a list property. This is working to the extent that modifications to existing items in the list are being persisted as expected. However, it is failing to work when the user adds values to the fields of the form that are specifying values for a new item that is to be added to the list. Those values are being ignored. In my case, the list property is, itself, a property of a single object that is being edited using the web form. Thus, the form fields have names like description.commonNames[0].name and description.commonNames[0].language description.commonNames[1].name and description.commonNames[1].language Thus, the list is a property of the description object rather than the actionBean supporting the form. When users navigate to the web form, the page is loaded with a single parameter that is the ID of the description. Most of the properties of the description object are not to be edited on the form; just the list of commonNames in the description. A description can have any number of commonNames. A stripes type converter converts the ID of the description into an actual description object that is accessible from the actionBean using the getDescription() method. The description object has a "void setCommonNames(List names)" method and a public "List getCommonNames()" method. The description in the actionBean then makes its existing commonNames available to the form which accessing their values using the description.getCommonNames() method. That works well. When the user modifies existing common names in the description, those changes are copied back into the description's common names and all is well. When the user adds content to the form fields for a new commonName, however, those values are not used to instantiate a new commonName. Nor is any newly instantiated commonName added to the list of commonNames in the description. Importantly, the setCommonNames(...) method of the description is never called. The content that should have been used to instantiate the new commonName is available in the form action bean (I have been checking using the context.getRequest().getParameterMap()). Any thoughts that people have on what is going wrong would be very much appreciated. Thanks in advance, Geoff Shuetrim -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Freemarker Servlet Error being thrown when using Stripes Layouts with Freemarker templates
Further to this issue, problems appear to arise between Stripes 1.5.3 and 1.5.4. 1.5.3 works without raising exceptions while 1.5.4 and 1.5.5 both lead to NPE based exceptions while 1.5.6 leads to a array out of bounds based exception. Regards Geoff Shuetrim On 15 April 2011 12:44, Geoff Shuetrim wrote: > In migrating from Stripes 1.5.1 to 1.5.6 an exception gets thrown every > time that I I load a page involving a Stripes Layout in a Freemarker > template. > I am using Freemarker 2.3.16 and I am using the standard freemarker servlet > (freemarker.ext.servlet.FreemarkerServlet). > I am not using a custom Stripes application initialization interceptor. > > The problem does not occur for JSP that use Stripes layout tags. It is only > arising when I use Freemarker templates. > The exception does not appear to prevent the page from rendering correctly. > > To keep things simple, I am using the following trivial layout definition: > > [#ftl] > [#assign s=JspTaglibs["http://stripes.sourceforge.net/stripes.tld";] /] > [@s["layout-definition"] /] > > and the following rendering of that layout: > > [#ftl] > [#assign s=JspTaglibs["http://stripes.sourceforge.net/stripes.tld";] /] > [@s["layout-render"] name="/layout/test.ftl"/] > > Forwarding to this freemarker template from a Stripes action bean, this > generates a blank web page. However I also get the error trace shown at the > end of this email. > > I would really appreciate insights into what is going wrong so that I can > upgrade to the latest version of stripes. > > Regards > > Geoff Shuetrim > > > WARN Log4JLoggerFactory.java 111 [warn] - Tag.SKIP_PAGE was ignored from a > net.sourceforge.stripes.tag.layout.LayoutDefinitionTag tag. > 15/04/2011 12:21:33 PM org.apache.catalina.core.ApplicationDispatcher > invoke > SEVERE: Servlet.service() for servlet Freemarker threw exception > java.lang.ArrayIndexOutOfBoundsException: -1 > at java.util.ArrayList.remove(ArrayList.java:390) > at > freemarker.ext.jsp.FreeMarkerPageContext.popWriter(FreeMarkerPageContext.java:438) > at > freemarker.ext.jsp.TagTransformModel$TagWriter.close(TagTransformModel.java:458) > at freemarker.core.Environment.visit(Environment.java:331) > at freemarker.core.UnifiedCall.accept(UnifiedCall.java:130) > at freemarker.core.Environment.visit(Environment.java:210) > at freemarker.core.MixedContent.accept(MixedContent.java:92) > at freemarker.core.Environment.visit(Environment.java:210) > at freemarker.core.Environment.process(Environment.java:190) > at freemarker.template.Template.process(Template.java:237) > at > freemarker.ext.servlet.FreemarkerServlet.process(FreemarkerServlet.java:452) > at > freemarker.ext.servlet.FreemarkerServlet.doGet(FreemarkerServlet.java:391) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) > at > org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) > at > org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) > at > org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) > at > net.sourceforge.stripes.action.ForwardResolution.execute(ForwardResolution.java:110) > at > net.sourceforge.stripes.controller.DispatcherHelper$7.intercept(DispatcherHelper.java:508) > at > net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:158) > at > net.sourceforge.stripes.controller.HttpCacheInterceptor.intercept(HttpCacheInterceptor.java:99) > at > net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155) > at > net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113) > at > net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155) > at > net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.java:74) > at > net.sourceforge.stripes.controller.DispatcherHelper.executeResolution(DispatcherHelper.java:502) > at > net.sourceforge.stripes.controller.DispatcherServlet.executeResolution(DispatcherServlet.java:286) > at > net.sourceforge.stripes.controller.DispatcherSer
[Stripes-users] Freemarker Servlet Error being thrown when using Stripes Layouts with Freemarker templates
In migrating from Stripes 1.5.1 to 1.5.6 an exception gets thrown every time that I I load a page involving a Stripes Layout in a Freemarker template. I am using Freemarker 2.3.16 and I am using the standard freemarker servlet (freemarker.ext.servlet.FreemarkerServlet). I am not using a custom Stripes application initialization interceptor. The problem does not occur for JSP that use Stripes layout tags. It is only arising when I use Freemarker templates. The exception does not appear to prevent the page from rendering correctly. To keep things simple, I am using the following trivial layout definition: [#ftl] [#assign s=JspTaglibs["http://stripes.sourceforge.net/stripes.tld";] /] [@s["layout-definition"] /] and the following rendering of that layout: [#ftl] [#assign s=JspTaglibs["http://stripes.sourceforge.net/stripes.tld";] /] [@s["layout-render"] name="/layout/test.ftl"/] Forwarding to this freemarker template from a Stripes action bean, this generates a blank web page. However I also get the error trace shown at the end of this email. I would really appreciate insights into what is going wrong so that I can upgrade to the latest version of stripes. Regards Geoff Shuetrim WARN Log4JLoggerFactory.java 111 [warn] - Tag.SKIP_PAGE was ignored from a net.sourceforge.stripes.tag.layout.LayoutDefinitionTag tag. 15/04/2011 12:21:33 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet Freemarker threw exception java.lang.ArrayIndexOutOfBoundsException: -1 at java.util.ArrayList.remove(ArrayList.java:390) at freemarker.ext.jsp.FreeMarkerPageContext.popWriter(FreeMarkerPageContext.java:438) at freemarker.ext.jsp.TagTransformModel$TagWriter.close(TagTransformModel.java:458) at freemarker.core.Environment.visit(Environment.java:331) at freemarker.core.UnifiedCall.accept(UnifiedCall.java:130) at freemarker.core.Environment.visit(Environment.java:210) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:210) at freemarker.core.Environment.process(Environment.java:190) at freemarker.template.Template.process(Template.java:237) at freemarker.ext.servlet.FreemarkerServlet.process(FreemarkerServlet.java:452) at freemarker.ext.servlet.FreemarkerServlet.doGet(FreemarkerServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) at net.sourceforge.stripes.action.ForwardResolution.execute(ForwardResolution.java:110) at net.sourceforge.stripes.controller.DispatcherHelper$7.intercept(DispatcherHelper.java:508) at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:158) at net.sourceforge.stripes.controller.HttpCacheInterceptor.intercept(HttpCacheInterceptor.java:99) at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155) at net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113) at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155) at net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.java:74) at net.sourceforge.stripes.controller.DispatcherHelper.executeResolution(DispatcherHelper.java:502) at net.sourceforge.stripes.controller.DispatcherServlet.executeResolution(DispatcherServlet.java:286) at net.sourceforge.stripes.controller.DispatcherServlet.service(DispatcherServlet.java:170) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:247) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:138) at org.acegisecurity.util.FilterToBe
Re: [Stripes-users] Missing StripesRequestWrapper when using web.xml to direct 404 errors to a Stripes action.
Ben, Thanks, that works a treat! Geoff S 2009/10/1 Ben Gunter > You have to add ERROR to your StripesFilter > mapping, similar to how it's shown in the DynamicMappingFilter javadocs. > > > http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/controller/DynamicMappingFilter.html > > -Ben > > On Thu, Oct 1, 2009 at 1:08 AM, Geoff Shuetrim wrote: > >> I am using Stripes 1.5.1 and Tomcat 6. >> >> I am trying to use a stripes action to respond to requests that result in >> a 404 error. >> >> I have added: >> >> >> 404 >> /errors/Error.action >> >> >> to the web application's web.xml file. >> >> When I trigger a 404 error, the following log entry is generated and the >> web browser is sent to the default 404 error page. >> >> 01/10/2009 2:53:49 PM org.apache.catalina.core.ApplicationDispatcher >> invoke >> SEVERE: Servlet.service() for servlet StripesDispatcher threw exception >> java.lang.IllegalStateException: A request made it through to some part of >> Stripes without being wrapped in a StripesRequestWrapper. The StripesFilter >> is responsible for wrapping the request, so it is likely that either the >> StripesFilter is not deployed, or that its mappings do not include the >> DispatcherServlet _and_ *.jsp. Stripes does not require that the Stripes >> wrapper is the only request wrapper, or the outermost; only that it is >> present. >> at >> net.sourceforge.stripes.controller.StripesRequestWrapper.findStripesWrapper(StripesRequestWrapper.java:81) >> at >> net.sourceforge.stripes.controller.DefaultActionBeanPropertyBinder.bind(DefaultActionBeanPropertyBinder.java:207) >> at >> net.sourceforge.stripes.controller.DispatcherHelper$3.intercept(DispatcherHelper.java:194) >> at >> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:158) >> at >> net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113) >> at >> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155) >> at >> net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.java:74) >> at >> net.sourceforge.stripes.controller.DispatcherHelper.doBindingAndValidation(DispatcherHelper.java:190) >> at >> net.sourceforge.stripes.controller.DispatcherServlet.doBindingAndValidation(DispatcherServlet.java:254) >> at >> net.sourceforge.stripes.controller.DispatcherServlet.service(DispatcherServlet.java:148) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) >> at >> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) >> at >> org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:438) >> at >> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) >> at >> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) >> at >> org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:416) >> at >> org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:343) >> at >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:144) >> at >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) >> at >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) >> at >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) >> at >> org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:427) >> at >> org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:384) >> at >> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1527) >> at java.lang.Thread.run(Thread.java:619) >> >> Any ideas on how to make such requests for Stripes actions be wrapped >> properly? >> >> Thanks >> >> Geoff Shuetrim >> >> >> -- >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. J
[Stripes-users] Missing StripesRequestWrapper when using web.xml to direct 404 errors to a Stripes action.
I am using Stripes 1.5.1 and Tomcat 6. I am trying to use a stripes action to respond to requests that result in a 404 error. I have added: 404 /errors/Error.action to the web application's web.xml file. When I trigger a 404 error, the following log entry is generated and the web browser is sent to the default 404 error page. 01/10/2009 2:53:49 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet StripesDispatcher threw exception java.lang.IllegalStateException: A request made it through to some part of Stripes without being wrapped in a StripesRequestWrapper. The StripesFilter is responsible for wrapping the request, so it is likely that either the StripesFilter is not deployed, or that its mappings do not include the DispatcherServlet _and_ *.jsp. Stripes does not require that the Stripes wrapper is the only request wrapper, or the outermost; only that it is present. at net.sourceforge.stripes.controller.StripesRequestWrapper.findStripesWrapper(StripesRequestWrapper.java:81) at net.sourceforge.stripes.controller.DefaultActionBeanPropertyBinder.bind(DefaultActionBeanPropertyBinder.java:207) at net.sourceforge.stripes.controller.DispatcherHelper$3.intercept(DispatcherHelper.java:194) at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:158) at net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113) at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155) at net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.java:74) at net.sourceforge.stripes.controller.DispatcherHelper.doBindingAndValidation(DispatcherHelper.java:190) at net.sourceforge.stripes.controller.DispatcherServlet.doBindingAndValidation(DispatcherServlet.java:254) at net.sourceforge.stripes.controller.DispatcherServlet.service(DispatcherServlet.java:148) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:438) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:416) at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:343) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:144) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:427) at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:384) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1527) at java.lang.Thread.run(Thread.java:619) Any ideas on how to make such requests for Stripes actions be wrapped properly? Thanks Geoff Shuetrim -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] How do I resolve buffer clearing problems when using stripes layout tags?
Can someone advise me on how to solve problem causing the following
warning messages to be shown for every single page that I load that uses
a stripes layout.
WARN Log.java 155 [warn] - Could not clear buffer before rendering a
layout.java.io.IOException: Can't clear
WARN Log4JLoggerFactory.java 111 [warn] - Tag.SKIP_PAGE was ignored
from a net.sourceforge.stripes.tag.layout.LayoutDefinitionTag tag.
My setup is:
Hardy Heron Ubuntu Linux amd64
Tomcat 5.5
Sun Java 1.5
Stripes 1.4.2
I am using Freemarker templates rather than JSPs.
My Freemarker template (standard.ftl) uses a layout like the following:
[#ftl]
[#assign s=JspTaglibs["http://stripes.sourceforge.net/stripes.tld";] /]
[EMAIL PROTECTED]"layout-definition"] ]
${title}
Universal page title
[EMAIL PROTECTED]"layout-component"] name="contents" /]
[/@]
The Freemarker templates providing the "contents" component of the
layout are like the following:
[#ftl]
[#assign s=JspTaglibs["http://stripes.sourceforge.net/stripes.tld";] /]
[EMAIL PROTECTED]"layout-render"] name="standard.ftl" title="Home"]
[EMAIL PROTECTED]"layout-component"] name="contents"]
Page content
[/@]
[/@]
Any insights into why the warnings are being triggered, what their
consequences are, and how to prevent them would be much appreciated.
Thanks
Geoff S
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] How to avoiding cluttering up my custom ActionBeanContext
I have been following the advice on: http://www.stripesframework.org/display/stripes/Best+Practices about using my own custom ActionBeanContext. This has been working fine for me but as my web-applications grow, I find that the custom ActionBeanContext gets filled up with a large number of basically unrelated get and set methods for the various things that I want to expose in the data model of my Freemarker templates. Each action bean that I add to the web application comes with one of two new things that it wants to make available to the presentation layer and as I add the get and set methods to the custom ActionBeanContext to inject those things into the session I get the kind of clutter that I described above. In trying to minimise this clutter, I have been finding myself putting relatively primitive objects into the session and then using calls from within my presentation layer to mold them into exactly the information that I want to present. That seems to be putting too much burden on the presentation layer and I would prefer to see that kind of data preparation work being done in either my action beans or in a layer closer to the actual underlying data model. Any thoughts on how to get this balance right? Should I just get over it and stuff my custom ActionBeanContext full of get and set methods that are serving entirely different classes of purposes? Thanks Geoff Shuetrim On Sun, 2008-04-13 at 20:31 -0500, Gregg Bolinger wrote: > Hey everyone. I'm in the processing of trying to line up my next gig as > my current one is coming to an end in the next several weeks. I'd > really like to work with Stripes so if any of you know of any 1099 where > remote work is possible I'd really appreciate it if you'd let me know. > > Thanks. > > Gregg > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Stripes-users mailing list > Stripes-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/stripes-users > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
