September 2009 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3630) Calling Renderer.render twice throws NPE in testing

by Abram Thielke (JIRA)

Calling Renderer.render twice throws NPE in testing --------------------------------------------------- Key: JBSEAM-3630 URL: https://jira.jboss.org/jira/browse/JBSEAM-3630 Project: Seam Issue Type: Bug Components: Mail Affects Versions: 2.1.0.GA Environment: JDK 1.5 Reporter: Abram Thielke Assignee: Pete Muir Attachments: modified-mail-example.zip Methods in Seam 2.1.0.GA that call Renderer.render( ... ) multiple times inside the same method throws an NPE. This works fine when I deploy the app, however in testing I get the NullPointerException. I modified the mail example packaged with Seam 2.1 to call render twice from the MailExample.send method and I get the same thing: [testng] ERROR [org.jboss.seam.example.mail.MailExample] Error sending mail [testng] java.lang.NullPointerException [testng] at org.jboss.seam.ui.facelet.RendererRequest.init(RendererRequest.java:49) [testng] at org.jboss.seam.ui.facelet.RendererRequest.run(RendererRequest.java:72) [testng] at org.jboss.seam.ui.facelet.FaceletsRenderer.render(FaceletsRenderer.java:43) [testng] at org.jboss.seam.example.mail.MailExample.send(MailExample.java:41) [testng] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [testng] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [testng] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [testng] at java.lang.reflect.Method.invoke(Method.java:585) [testng] at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) [testng] at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31) [testng] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) [testng] at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) [testng] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) [testng] at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77) [testng] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) [testng] at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) [testng] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) [testng] at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) [testng] at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166) [testng] at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102) [testng] at org.jboss.seam.example.mail.MailExample_$$_javassist_5.send(MailExample_$$_javassist_5.java) [testng] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [testng] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [testng] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [testng] at java.lang.reflect.Method.invoke(Method.java:585) [testng] at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329) [testng] at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:342) [testng] at org.jboss.el.parser.AstPropertySuffix.invoke(AstPropertySuffix.java:58) [testng] at org.jboss.el.parser.AstValue.invoke(AstValue.java:96) [testng] at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) [testng] at org.jboss.seam.mock.AbstractSeamTest$Request.invokeMethod(AbstractSeamTest.java:464) [testng] at org.jboss.seam.mock.AbstractSeamTest$Request.invokeAction(AbstractSeamTest.java:473) [testng] at org.jboss.seam.example.mail.test.MailTest$12.invokeApplication(MailTest.java:647) [testng] at org.jboss.seam.mock.AbstractSeamTest$Request.invokeApplicationPhase(AbstractSeamTest.java:647) [testng] at org.jboss.seam.mock.AbstractSeamTest$Request.emulateJsfLifecycle(AbstractSeamTest.java:596) [testng] at org.jboss.seam.mock.AbstractSeamTest$Request.access$300(AbstractSeamTest.java:178) [testng] at org.jboss.seam.mock.AbstractSeamTest$Request$2.doFilter(AbstractSeamTest.java:498) [testng] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) [testng] at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:51) [testng] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [testng] at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38) [testng] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [testng] at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90) [testng] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [testng] at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) [testng] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [testng] at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) [testng] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [testng] at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:177) [testng] at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:267) [testng] at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:380) [testng] at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:507) [testng] at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56) [testng] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [testng] at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58) [testng] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [testng] at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) [testng] at org.jboss.seam.mock.AbstractSeamTest$Request.run(AbstractSeamTest.java:492) [testng] at org.jboss.seam.example.mail.test.MailTest.testDoubleRender(MailTest.java:633) [testng] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [testng] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [testng] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [testng] at java.lang.reflect.Method.invoke(Method.java:585) [testng] at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:604) [testng] at org.testng.internal.Invoker.invokeMethod(Invoker.java:470) [testng] at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:564) [testng] at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:830) [testng] at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) [testng] at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) [testng] at org.testng.TestRunner.runWorkers(TestRunner.java:678) [testng] at org.testng.TestRunner.privateRun(TestRunner.java:624) [testng] at org.testng.TestRunner.run(TestRunner.java:495) [testng] at org.testng.SuiteRunner.runTest(SuiteRunner.java:300) [testng] at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:295) [testng] at org.testng.SuiteRunner.privateRun(SuiteRunner.java:275) [testng] at org.testng.SuiteRunner.run(SuiteRunner.java:190) [testng] at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:792) [testng] at org.testng.TestNG.runSuitesLocally(TestNG.java:765) [testng] at org.testng.TestNG.run(TestNG.java:699) [testng] at org.testng.TestNG.privateMain(TestNG.java:824) [testng] at org.testng.TestNG.main(TestNG.java:802) I'll attach the modified mail example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

4
8
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4217) returnToCapturedView fails if captureCurrentView was called on a POST request from IE with long params

by Matthew Lieder (JIRA)

returnToCapturedView fails if captureCurrentView was called on a POST request from IE with long params ------------------------------------------------------------------------------------------------------ Key: JBSEAM-4217 URL: https://jira.jboss.org/jira/browse/JBSEAM-4217 Project: Seam Issue Type: Bug Affects Versions: 2.1.2.CR2 Environment: Java 6, Tomcat 6, Internet Explorer 7 Reporter: Matthew Lieder If a POST request is made to a Seam page that requires authentication, the redirect after authentication fails with an IE "Unable to display page" error if the POST request's parameters combined add up to >2000 characters, approximately. The root of the problem is that when Seam redirects afterwards, it builds a GET URL and does a standard 301 redirect to it, which fails in IE if the URL is >2083 characters. The solution would seem to be either to replace the 301 redirect with another POST request, or to not include the parameters in the URL and instead reconstitute them upon render of the page that's being redirected to. This bug was triggered by the fix for JBSEAM-4066. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2717) Tomcat Integration reference guide chapter

by Jay Balunas (JIRA)

Tomcat Integration reference guide chapter ------------------------------------------ Key: JBSEAM-2717 URL: http://jira.jboss.com/jira/browse/JBSEAM-2717 Project: JBoss Seam Issue Type: Task Components: Documentation Issues, Platform interoperability Affects Versions: 2.1.0.A1, 2.0.1.GA Reporter: Jay Balunas Assigned To: Jay Balunas Priority: Minor Following the existing interop reference guide chapters create a tomcat integration chapter. This chapter will cover deployments and limitations with and without JBoss embedded. There is already some information on tomcat deployment in the reference guide but it needs to be cleaned up with this single chapter. Likely version: tomcat 6.X References: http://tomcat.apache.org/ http://techieexchange.wordpress.com/2007/11/11/rad-seam-development-with-... http://www.jroller.com/wesleyhales/entry/running_seam_2_0_on http://www.michaelyuan.com/blog/2007/07/24/seam-20-and-tomcat/ http://jira.nuxeo.org/browse/NXP-1160 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

4
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3406) Back button in nested conversations

by Pablo Caballero (JIRA)

Back button in nested conversations ----------------------------------- Key: JBSEAM-3406 URL: https://jira.jboss.org/jira/browse/JBSEAM-3406 Project: Seam Issue Type: Bug Affects Versions: 2.0.3.CR1 Environment: Linux, jboss-4.2.2.GA Reporter: Pablo Caballero Pressing the back button after closing a nested conversation does not propagate to the parent conversation and creates a new conversation. For Example (see attached example files) Start parent conversation view id first.xhtml (let say conversation Id is 2) Start nested conversation view id second.xhtml (conversation Id is 3) Close nested conversation and redirect to first.xhtml (conversation id 2) Press the back button to try to view second.xhtml. Since the nested conversation is closed and no-conversation-view-id="/first.xhtml", the view stays in first.xhtml. However, a new conversation has been created with id 5. Conversation 2 is still active but in the background. (I Tried using natural conversations, but I believe nested and natural are not supported at this time) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

3
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4288) Seam-Wicket doesn't propagate to ResourceLinks

by Clint Popetz (JIRA)

Seam-Wicket doesn't propagate to ResourceLinks ---------------------------------------------- Key: JBSEAM-4288 URL: https://jira.jboss.org/jira/browse/JBSEAM-4288 Project: Seam Issue Type: Bug Components: Wicket Affects Versions: 2.2.0.CR1 Reporter: Clint Popetz Assignee: Clint Popetz Fix For: 2.2.1.CR1 Need to override RequestCycle.encodeSharedResourceURL and propagate cid as request parameter, because there is no pagemap for SharedResources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4282) Seam-Wicket conversation propagation doesn't respect endBeforeRedirect

by Clint Popetz (JIRA)

Seam-Wicket conversation propagation doesn't respect endBeforeRedirect ---------------------------------------------------------------------- Key: JBSEAM-4282 URL: https://jira.jboss.org/jira/browse/JBSEAM-4282 Project: Seam Issue Type: Bug Components: Wicket Affects Versions: 2.2.0.CR1 Reporter: Clint Popetz Assignee: Clint Popetz Fix For: 2.2.1.CR1 SeamWebApplication and its inner classes use Manager.isLongRunningConversation to determine whether to propagate conversation ids across request targets, but if a user calls endBeforeRedirect and then redirects to a new page, that page will get the old conversation id. It should instead use the isReallyLongRunningConversation...a method whose very name suggests a design flaw :P -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4281) Conversations are not propagated to modal windows

by Clint Popetz (JIRA)

Conversations are not propagated to modal windows ------------------------------------------------- Key: JBSEAM-4281 URL: https://jira.jboss.org/jira/browse/JBSEAM-4281 Project: Seam Issue Type: Bug Components: Wicket Affects Versions: 2.2.0.CR1 Reporter: Clint Popetz Assignee: Clint Popetz Fix For: 2.2.1.CR1 Wicket does not use its own RequestCycleProcessor.respond when showing a ModalWindow, so the seam/wicket integration mechanism that propagates conversations doesn't propagate them to modal windows. A workaround is to create the modal window with an anonymous subclass that puts the conversation id in the javascript that is appended for opening the window: add(modalWindow = new ModalWindow("yourModalTitle") { protected AppendingStringBuffer postProcessSettings(AppendingStringBuffer settings) { return settings.replace(0, Integer.MAX_VALUE, settings.toString().replaceFirst("(settings.src=\"[^\"]+)\"", "$1&cid=" + org.jboss.seam.core.Manager.instance().getCurrentConversationId()+'"')); } }); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4231) Invalid Content Id for email attchments

by Tom Goring (JIRA)

Invalid Content Id for email attchments --------------------------------------- Key: JBSEAM-4231 URL: https://jira.jboss.org/jira/browse/JBSEAM-4231 Project: Seam Issue Type: Bug Affects Versions: 2.1.1.GA Environment: NA Reporter: Tom Goring Seam should not set the content id for attachments (e.g. in the case of a PDF). Some email clients don't like it and the attachments becomes hidden. I think this should be done in the case of disposition eq "attachment" and not for "inline" http://www.seamframework.org/Community/PDFAttachmentsAndLotusNotes65Outlo... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4060) back button in pageflow should work after a redirect

by Dan Allen (JIRA)

back button in pageflow should work after a redirect ---------------------------------------------------- Key: JBSEAM-4060 URL: https://jira.jboss.org/jira/browse/JBSEAM-4060 Project: Seam Issue Type: Feature Request Components: BPM Affects Versions: 2.1.1.GA Reporter: Dan Allen Fix For: 2.2.0.CR1 When the current page in a pageflow is validated, Seam is reference the page-scoped FacesPage. This component is only available on a faces request. Therefore, if a redirect is used in the pageflow, then it is no possible to use the back button, even if it is enabled in the pageflow definition, since the page-scope won't be available in that case. The validation should be changed to rely on information in the conversation rather than the page-scope. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4105) NullPointer exception configuring a component using a qualified XML element

by Dan Allen (JIRA)

NullPointer exception configuring a component using a qualified XML element --------------------------------------------------------------------------- Key: JBSEAM-4105 URL: https://jira.jboss.org/jira/browse/JBSEAM-4105 Project: Seam Issue Type: Bug Components: Core Affects Versions: 2.1.2.CR1 Reporter: Dan Allen Assignee: Dan Allen Fix For: 2.1.2.GA Consider the case where there is an existing component defined with the @Name annotation. Now, you want to be able to configure that component in XML. If the class name for the component cannot be derived from the name of the component, then Seam throws a NullPointerException. Case in point. Assume the following component package com.mydomain.project; @Name("com.mydomain.project.init") public class ProjectInit { ... } Now assume I am configuring it with: <project:init stage="test"/> Because the class of the component, com.mydomain.project.ProjectInit, cannot be derived form the component name, com.mydomain.project.init, Seam tries to do something with the class object that leads to a NullPointerException. What should happen is that Seam should recognize it is configuring an existing component and ignore that fact that it cannot resolve the class. That is the intended behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues September 2009