October 2007 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1959) Wildcard page view-id (*) in pages.xml file with login-required="true" cause error.

by Francisco Ant?ônio (JIRA)

Wildcard page view-id (*) in pages.xml file with login-required="true" cause error. ----------------------------------------------------------------------------------- Key: JBSEAM-1959 URL: http://jira.jboss.com/jira/browse/JBSEAM-1959 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 2.0.0.CR1 Environment: Windows XP Pro SP2 JBoss AS 4.2.0.GA JBoss Seam 2.0.0.CR1 Reporter: Francisco Ant?ônio The use of <page view-id="*" login-required="true" > in pages.xml file causes the following errors: a) ERROR [ResourceLifecycle] Exception in PhaseListener, render view : beforePhase java.lang.IllegalStateException: No active application scope and b) ERROR [ResourceLifecycle] Exception in PhaseListener, render view : beforePhase java.lang.IllegalStateException: No application context active If login-required="true" is just removed the above errors disappear. -- 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

16 years, 7 months

3
17
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2052) use "Add Entity" if instance is not managed

by Dan Allen (JIRA)

use "Add Entity" if instance is not managed ------------------------------------------- Key: JBSEAM-2052 URL: http://jira.jboss.com/jira/browse/JBSEAM-2052 Project: JBoss Seam Issue Type: Feature Request Components: Tools Affects Versions: 2.0.0.CR1 Reporter: Dan Allen Assigned To: Dan Allen Priority: Minor Fix For: 2.0.0.GA The edit pages created by the generate-entities command should read "Add Entity" if the instance is not managed and "Edit Entity" if the instance is managed, where "Entity" is the name of the entity. ${'#'}{${homeName}.managed ? 'Edit' : 'Add'} ${entityName} -- 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

16 years, 7 months

1
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1131) Example web.xml is incomplete

by Christian Bauer (JIRA)

Example web.xml is incomplete ----------------------------- Key: JBSEAM-1131 URL: http://jira.jboss.com/jira/browse/JBSEAM-1131 Project: JBoss Seam Issue Type: Bug Components: Tools Reporter: Christian Bauer I was running into this when using an ajax4jsf tag: SEVERE: Error Rendering View[/docDisplay.xhtml] javax.faces.FacesException: Resources framework is not initialised, check web.xml for Filter configuration at org.ajax4jsf.framework.resource.ResourceBuilderImpl.getWebXml(ResourceBuilderImpl.java:107) at org.ajax4jsf.framework.resource.ResourceBuilderImpl.getUri(ResourceBuilderImpl.java:309) at org.ajax4jsf.framework.resource.InternetResourceBase.getUri(InternetResourceBase.java:211) at org.ajax4jsf.framework.resource.BaseResourceRenderer.encodeBegin(BaseResourceRenderer.java:62) at org.ajax4jsf.framework.resource.OneTimeRenderer.encodeBegin(OneTimeRenderer.java:48) at org.ajax4jsf.framework.resource.BaseResourceRenderer.encode(BaseResourceRenderer.java:45) at org.ajax4jsf.framework.resource.InternetResourceBase.encode(InternetResourceBase.java:306) at org.ajax4jsf.framework.resource.ClientScript.encode(ClientScript.java:143) at org.ajax4jsf.framework.renderer.HeaderResourcesRendererBase.encodeResourcesArray(HeaderResourcesRendererBase.java:131) at org.ajax4jsf.framework.renderer.HeaderResourcesRendererBase.preEncodeBegin(HeaderResourcesRendererBase.java:117) at org.ajax4jsf.framework.renderer.RendererBase.encodeBegin(RendererBase.java:98) at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:512) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:242) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:249) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:249) at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:573) at org.ajax4jsf.framework.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108) at org.ajax4jsf.framework.ajax.AjaxViewHandler.renderView(AjaxViewHandler.java:229) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) It only happened right after redeployment, and if the first page I called (with an ajax4jsf tag on it) was behind my rewrite filter, last in web.xml: <filter> <filter-name>UrlRewriteFilter</filter-name> <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class> <init-param> <param-name>logLevel</param-name> <param-value>WARN</param-value> </init-param> <init-param> <param-name>statusEnabled</param-name> <param-value>false</param-value> </init-param> </filter> <filter-mapping> <filter-name>UrlRewriteFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> Note that this rewrites internally somehow, not with a redirect. If I called, right after deployment, a page with a not rewritten URL and an ajax4jsf tag on it, it would work fine. Interesting enough but after it would work once, even pages that had rewritten URLs worked fine. So there is some initialization issue hidden in this somewhere. After reading this http://jboss.com/index.html?module=bb&op=viewtopic&t=103561 I started playing with random web.xml settings. Take a seam-gen WAR deployment web.xml and make the following modifications: <filter-mapping> <filter-name>ajax4jsf</filter-name> <url-pattern>*.seam</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> <dispatcher>INCLUDE</dispatcher> </filter-mapping> <filter-mapping> <filter-name>Seam Filter</filter-name> <url-pattern>*.seam</url-pattern> </filter-mapping> This seems to work now. I have no idea what happens. Put this on the Java EE 6.0 list: web.xml must be replaced with something that makes sense. Or we need to find a proprietary way to configure a stack of a dozen filters with explicit URL pattern/precedence matching. Maybe we should move this into a Seam config file and initialize the web container programmatically (if that is possible). -- 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

16 years, 7 months

3
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1726) seam-gen corrupts image files

by Richard Teviotdale (JIRA)

seam-gen corrupts image files ----------------------------- Key: JBSEAM-1726 URL: http://jira.jboss.com/jira/browse/JBSEAM-1726 Project: JBoss Seam Issue Type: Bug Components: Tools Affects Versions: 2.0.0.BETA1, 1.2.1.GA Environment: Debian 4.0 Linux Kernel 2.6.18-4-amd64 sun jdk 1.5.0_12 ant 1.7.0 Reporter: Richard Teviotdale The files cal-next.png, cal-prev.png and dtpick.gif are corrupt when creating a new sem-gen project. May be caused by use of a filterset within an ant copy target. Please see forum posting. -- 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

16 years, 7 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1995) MultipartFilter maxRequestSize exceeded throws NullPointerException from ExceptionFilter

by Nathan Wray (JIRA)

MultipartFilter maxRequestSize exceeded throws NullPointerException from ExceptionFilter ---------------------------------------------------------------------------------------- Key: JBSEAM-1995 URL: http://jira.jboss.com/jira/browse/JBSEAM-1995 Project: JBoss Seam Issue Type: Patch Components: Core Affects Versions: 2.0.0.CR1, 2.0.0.BETA1 Environment: WinXP, jboss-4.2.1.GA, jboss-seam-2.0.0.CR1, Java VM: Java HotSpot(TM) Server VM 1.5.0_12-b04,Sun Microsystems Inc. Reporter: Nathan Wray using the <s:fileUpload /> component, when maxRequestSize is exceed and the user is not in a conversation scope, the server throws the user a null pointer exception rather than the message configured in pages.xml: 2007-09-28 10:24:40,703 ERROR [org.jboss.seam.web.ExceptionFilter] handling uncaught exception org.jboss.seam.web.FileUploadException: Multipart request is larger than allowed size at org.jboss.seam.web.MultipartRequest.<init>(MultipartRequest.java:280) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:80) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [...] 2007-09-28 10:24:40,703 ERROR [org.jboss.seam.web.ExceptionFilter] exception root cause 2007-09-28 10:24:40,718 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/set].[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception java.lang.NullPointerException at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:93) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:70) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:44) the code in ExceptionFilter at line 93 assumes a Manager will be found in the request causing a null pointer exception. I've patched this locally (against 2.0CR1) with the following: 93,94c93 < if (oldManager != null) < conversationId = oldManager.getCurrentConversationId(); --- > conversationId = oldManager.getCurrentConversationId(); 102,110c101,102 < if (conversationId != null) < { < ConversationPropagation.instance().setConversationId(conversationId); < Manager.instance().restoreConversation(); < } < else < { < Manager.instance().initializeTemporaryConversation(); < } --- > ConversationPropagation.instance().setConversationId(conversationId); > Manager.instance().restoreConversation(); -- 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

16 years, 7 months

2
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2023) short-circuit page actions on first navigation event

by Dan Allen (JIRA)

short-circuit page actions on first navigation event ---------------------------------------------------- Key: JBSEAM-2023 URL: http://jira.jboss.com/jira/browse/JBSEAM-2023 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 2.0.0.CR1 Reporter: Dan Allen Priority: Minor Fix For: 2.0.x Page actions currently have one severe quirk. If multiple page actions are configured for a view-id pattern, they all execute without checking whether or not a navigation has occurred (a navigation match was found). What is even more strange is that even when a navigation match is found and the JSF NavigationHandler has processed the navigation, the actions just keep on executing. I cannot imagine that invoking the navigation handler multiple times was anticipated behavior. Even if it is, the developer is still going to be massively confused which navigation event is going to actually stick. Here is the current logic: for ( Action action: getActions() ) { if ( action.isExecutable() ) { String outcome = action.getOutcome(); String fromAction = outcome; if (outcome==null) { fromAction = action.getMethodExpression().getExpressionString(); result = true; outcome = Pages.toString( action.getMethodExpression().invoke() ); Pages.handleOutcome(facesContext, outcome, fromAction); } else { Pages.handleOutcome(facesContext, outcome, fromAction); } } } I think that the short-circuit that needs to take place is that if the response is marked as complete (which indicates a redirect navigation) or if the UIViewRoot changed (which indicates a non-redirect navigation), then the actions should stop executing. We should definitely include a test case if we make this change. Its too important to screw up. If there is a desire to maintain the previous behavior, then I believe a flag should be added on the page element like so <page short-circuit-actions="false"> -- 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

16 years, 7 months

4
13
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2041) groovybooking demo fails to deploy

by Norman Richards (JIRA)

groovybooking demo fails to deploy ---------------------------------- Key: JBSEAM-2041 URL: http://jira.jboss.com/jira/browse/JBSEAM-2041 Project: JBoss Seam Issue Type: Bug Reporter: Norman Richards Looks like an issue with the packaging for the new build. org.jboss.deployment.DeploymentException: No META-INF/application.xml found at org.jboss.deployment.EARDeployer.init(EARDeployer.java:146) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:872) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:809) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy9.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner. -- 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

16 years, 7 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-280) Integrate the page context with Seam Remoting

by Shane Bryzak (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-280?page=all ] Shane Bryzak updated JBSEAM-280: -------------------------------- Fix Version/s: 2.0.0.GA Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial] (was: [Interactive Demo/Tutorial, Documentation (Ref Guide, User Guide, etc.)]) > Integrate the page context with Seam Remoting > --------------------------------------------- > > Key: JBSEAM-280 > URL: http://jira.jboss.com/jira/browse/JBSEAM-280 > Project: JBoss Seam > Issue Type: Feature Request > Components: Remoting > Reporter: Shane Bryzak > Assigned To: Shane Bryzak > Fix For: 2.0.0.GA > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Support the propogation of Seam's Page Context between remoting requests. > Functional Requirements: > * The page context should be stored client-side in the global js variable Seam.pageContext. > * The page context should be included in any Seam Remoting requests in the packet header, i.e.: > <page-context><variable name="foo"><ref id="0"/></variable>...</page-context> > * The page context should be returned by all remoting requests and replace the local copy > * The client web page should be able to manipulate the page context, changing values, adding new values, etc via Seam.pageContext, e.g. Seam.pageContext.foo = bar; > Non functional requirements: > * Add a server-side convenience method to convert an object to serialized XML > * Add a client-side convenience method to deserialize XML into an object > * Create a <pageContext/> JSF tag that will embed a <script> block into the web page that initializes the page context when the page is first loaded > * Modify the client-side remoting framework to support the dynamic discovery of object types. Use the __type field (or something similar) to identify the object type. This will mean that type stubs will not need to be explicitly imported. -- 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

16 years, 7 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1190) Disabling install of core components no longer works

by Mike Quilleash (JIRA)

Disabling install of core components no longer works ---------------------------------------------------- Key: JBSEAM-1190 URL: http://jira.jboss.com/jira/browse/JBSEAM-1190 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.2.1.GA Environment: Any Reporter: Mike Quilleash Upgrading from Seam 1.1.6 to 1.2.1 seems to have broken the ability to do this... <component class="org.jboss.seam.web.ExceptionFilter" installed="false"/> In my WEB-INF/components.xml. The logic in the dependency manager scans both component descriptors, ignores the first as it is set to not install and then installs the second (default) one as normal. I believe the precedence of two components is not being honoured with regard to the installed flag. Possible in private boolean tryToInstall(String key) { it should stop looping immediatly if it finds a non-installed component rather than skipping that descriptor and continuing to the next loop. This is a rather major issue for me as the exception filter is causing problems elsewhere (see bug 1188) and I can't seem to find out how to turn it off! -- 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

16 years, 7 months

3
12
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2020) OC4J example: login error

by Pete Muir (JIRA)

OC4J example: login error ------------------------- Key: JBSEAM-2020 URL: http://jira.jboss.com/jira/browse/JBSEAM-2020 Project: JBoss Seam Issue Type: Bug Components: Examples Affects Versions: 2.0.0.CR1 Reporter: Pete Muir Fix For: 2.0.0.CR2 Getting an exception calling #{authenticator.authenticate} (ITE from invoke() ). -- 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

16 years, 7 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues October 2007