January 2012 - seam-issues - Jboss List Archives

[JBoss JIRA] Created: (SEAMFACES-33) Create a solution for consolidated page-flow, transactional control, security constraints and URL-rewriting

by Lincoln Baxter III (JIRA)

Create a solution for consolidated page-flow, transactional control, security constraints and URL-rewriting ----------------------------------------------------------------------------------------------------------- Key: SEAMFACES-33 URL: https://jira.jboss.org/browse/SEAMFACES-33 Project: Seam Faces Issue Type: Feature Request Components: Conversations Reporter: Lincoln Baxter III We need a solution to address consolidated page-flow, transactional control, security constraints, and perhaps URL-rewriting -- all in one place. It has been previously discussed that a type-safe API be possible for this - which is definitely preferred over XML configuration: http://old.nabble.com/Replacing-pages.xml-td27649799.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

5
27
0 / 0

[JBoss JIRA] Created: (SEAMCONFIG-48) EAR contained WAR's beans.xml not processed

by Mike Mosiewicz (JIRA)

EAR contained WAR's beans.xml not processed ------------------------------------------- Key: SEAMCONFIG-48 URL: https://issues.jboss.org/browse/SEAMCONFIG-48 Project: Seam Config Issue Type: Bug Affects Versions: 3.0.0.Final Environment: JBoss AS 7 Reporter: Mike Mosiewicz Assignee: Stuart Douglas I have the EAR app containing one ejb jar and one war. I placed seam-config.jar in EAR's lib directory. My beans.xml are discovered by weld as follows: 15:21:36,588 DEBUG [org.jboss.weld] (MSC service thread 1-3) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/mongodb-seam-0.0.1-SNAPSHOT.jar/META-INF/beans.xml" 15:21:36,591 DEBUG [org.jboss.weld] (MSC service thread 1-3) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-persistence-api-3.0.0.Final.jar/META-INF/beans.xml" 15:21:36,592 DEBUG [org.jboss.weld] (MSC service thread 1-3) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-security-api-3.0.0.Final.jar/META-INF/beans.xml" 15:21:36,594 DEBUG [org.jboss.weld] (MSC service thread 1-3) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-servlet-3.0.0.Final.jar/META-INF/beans.xml" 15:21:36,597 DEBUG [org.jboss.weld] (MSC service thread 1-3) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-solder-3.0.0.Final.jar/META-INF/beans.xml" 15:21:36,601 DEBUG [org.jboss.weld] (MSC service thread 1-3) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/commerce-ejb-0.0.1-SNAPSHOT.jar/META-INF/beans.xml" 15:21:36,603 DEBUG [org.jboss.weld] (MSC service thread 1-11) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/public-war.war/WEB-INF/beans.xml" It seems that for ejb and other library jars the extension is executed but not for war. Like this: 15:21:54,173 INFO [org.jboss.seam.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-10) Reading XML file: vfs:/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-security-api-3.0.0.Final.jar/META-INF/beans.xml 15:21:54,177 INFO [org.jboss.seam.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-10) Reading XML file: vfs:/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/commerce-ejb-0.0.1-SNAPSHOT.jar/META-INF/beans.xml 15:21:54,195 INFO [org.jboss.seam.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-10) Reading XML file: vfs:/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-servlet-3.0.0.Final.jar/META-INF/beans.xml 15:21:54,196 INFO [org.jboss.seam.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-10) Reading XML file: vfs:/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/mongodb-seam-0.0.1-SNAPSHOT.jar/META-INF/beans.xml 15:21:54,197 INFO [org.jboss.seam.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-10) Reading XML file: vfs:/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-solder-3.0.0.Final.jar/META-INF/beans.xml 15:21:54,204 INFO [org.jboss.seam.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-10) Adding XML Defined Bean: pl.proinet.seam.mongo.MongoResolver -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

6
11
0 / 0

[JBoss JIRA] (SEAMFACES-214) @ViewConfig after authorization redirect back to original page throws exception

by christoph langer (Created) (JIRA)

@ViewConfig after authorization redirect back to original page throws exception ------------------------------------------------------------------------------- Key: SEAMFACES-214 URL: https://issues.jboss.org/browse/SEAMFACES-214 Project: Seam Faces Issue Type: Bug Affects Versions: 3.1.0.Beta3 Environment: Jboss 7.0.2 Reporter: christoph langer See http://seamframework.org/Community/ViewScopeRedirectAfterLoginErrorIllega... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

7
9
0 / 0

[JBoss JIRA] Created: (JBSEAM-4728) NPE involving o.j.s.mock.AbstractSeamTest.Request.init() and o.j.s.ui.facelet.RendererRequest.cleanup()

by Flavio Costa (JIRA)

NPE involving o.j.s.mock.AbstractSeamTest.Request.init() and o.j.s.ui.facelet.RendererRequest.cleanup() ------------------------------------------------------------------------------------------------------- Key: JBSEAM-4728 URL: https://jira.jboss.org/browse/JBSEAM-4728 Project: Seam Issue Type: Bug Components: Mail, Test Harness Affects Versions: 2.2.0.GA Environment: java version "1.6.0_22" Seam 2.2.0.GA Reporter: Flavio Costa Assignee: Pete Muir I'm trying to come up with a solution to integrate Wiser (http://code.google.com/p/subethasmtp/wiki/Wiser) and Seam Mail (so that I can create tests asserting that the e-mail is actually sent) but I stumbled into a problem. Seam Mail uses the "o.j.s.ui.facelet.RendererRequest" which sets up some mock objects to be able to render a XHTML in a String and send the e-mail. This works fine in production, I can call it several times during a single request. It works like a charm. The problems happens when trying to test the given method using SeamTest and its infrastructure. What happens is, during o.j.s.mock.AbstractSeamTest.Request.init() it creates a new MockFacesContext and saves it so that whenever you call FacesContext.getInstance() or MockFacesContextFactory.getFacesContext() this same instance will be returned. That's ok... for now. Things get messier now. Below code is extracted from RendererRequest.init() ..... originalFacesContext = FacesContext.getCurrentInstance(); facesContext = RendererFacesContextFactory.instance().getFacesContext(request, response); .... Problem here is that, due to AbstractSeamTest.Request.init() 'originalFacesContext == facesContext' and when RendererRequest.cleanup() is eventually called 'facesContext.release()' what happens is: (Extracted from MockFacesContext.release()) setCurrentInstance(null); MockFacesContextFactory.setFacesContext(null); The next time someone calls MockFacesContext.getInstance() or MockFacesContextFactory.getFacesContext() they will return null and eventually this will result in a NPE. Which is exactly what happens with me due to the fact that I call "Renderer.instance().render("mail.xhtml")" multiple times inside a method. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBSEAM-4654) s:selectItems noSelectionLabel does not generate option value

by Andrew Wheeler (JIRA)

s:selectItems noSelectionLabel does not generate option value ------------------------------------------------------------- Key: JBSEAM-4654 URL: https://jira.jboss.org/browse/JBSEAM-4654 Project: Seam Issue Type: Bug Components: Core Affects Versions: 2.2.1.CR1 Environment: JBoss 6 M3 Reporter: Andrew Wheeler When a selectOneMenu has no items other than the no selection option it does not render the option value as org.jboss.seam.ui.NoSelectionConverter.noSelectionValue. In this case the there are no values in person.images. <h:selectOneMenu id="portrait" value="#{person.portrait}"> <s:selectItems value="#{person.images}" var="i" label="#{i.annotation}" hideNoSelectionLabel="false" noSelectionLabel="Select a portrait..."/> <s:convertEntity/> </h:selectOneMenu> This renders: <select id="person:portraitDecoration:portrait" name="person:portraitDecoration:portrait" size="1"> <option selected="selected">Select a portrait...</option> </select> The result is that any form submit causes a java.lang.NumberFormatException with message: "For input string: "Select a portrait..."" I have debugged a little and I can see that the converter is not firing when rendering the page. It does however fire for other selectOneMenu items on the page that have one or more items. A similar and perhaps related issue is referenced in the JBoss Forum. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

10
24
0 / 0

[JBoss JIRA] Created: (JBSEAM-4529) org.jboss.seam.framework.Query --- count query generation fails if the query contains a JOIN FETCH operation written in uppercase

by Wolfgang Schwendt (JIRA)

org.jboss.seam.framework.Query --- count query generation fails if the query contains a JOIN FETCH operation written in uppercase ---------------------------------------------------------------------------------------------------------------------------------- Key: JBSEAM-4529 URL: https://jira.jboss.org/jira/browse/JBSEAM-4529 Project: Seam Issue Type: Bug Components: Core Affects Versions: 2.2.0.GA Environment: Seam 2.2.1 Rev 11984 Reporter: Wolfgang Schwendt Priority: Minor org.jboss.seam.framework.Query. The count query generation fails with an exception if the query contains a JOIN FETCH operation written in uppercase (rather than lowercase). -- 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

12 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBSEAM-4701) Cookie path being set to empty string via getRequestContextPath forming invalid cookies in IE

by Brian Dill (JIRA)

Cookie path being set to empty string via getRequestContextPath forming invalid cookies in IE --------------------------------------------------------------------------------------------- Key: JBSEAM-4701 URL: https://jira.jboss.org/browse/JBSEAM-4701 Project: Seam Issue Type: Bug Affects Versions: 2.1.2.GA Reporter: Brian Dill When using <s:token /> in JSF the javax.faces.ClientToken cookie that is created can potentially have an empty ("") path which will cause it to not be accepted in some versions of Internet Explorer. The following code in ClientUidSelector is the problem. setCookiePath(FacesContext.getCurrentInstance().getExternalContext().getRequestContextPath()); This bug can be manifested as "viewId: /myPage.xhtml - No client identifier provided." I'll try to post a patch file here asap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

6
14
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4398) RememberMe Issue - Base 64 encoded cookie containing '=' is not processed correctly in some cases

by Peter Goldstein (JIRA)

RememberMe Issue - Base 64 encoded cookie containing '=' is not processed correctly in some cases ------------------------------------------------------------------------------------------------- Key: JBSEAM-4398 URL: https://jira.jboss.org/jira/browse/JBSEAM-4398 Project: Seam Issue Type: Bug Affects Versions: 2.2.0.GA, 2.1.2.GA Environment: Observed on Windows Vista, JBoss 5.1.0 GA. Problem likely exists on other operating systems and other Tomcat 6 based systems. Reporter: Peter Goldstein When attempting to use the RememberMe component in auto-login mode I discovered a bug in the cookie handling of this component. When attempting to log using an auth token I was encountering repeated failures - the token was simply not being found in the database. After some investigation I discovered that the problem was that the value parameter passed into the query was truncated by one character - the last character was cut off. I tracked the problem further back, and discovered that the truncated value originated in JBoss' Tomcat. The cookie value being passed in was missing the last two '=' characters. Some Google searching revealed that this was deliberate - Tomcat 6 in the JBoss 5.1.0 GA configuration enforces strict character rules in the cookie value, which excludes '='. I'm not sure if Tomcat 6 is 'right' or not, but I do know that either way, this is a trivial issue to address on the Seam side. All one has to do is replace the '=' from the Base64 encoded token value with another allowed character (say '_' or '-') before placing it in a cookie, and reverse the process when reading a cookie. I have a patch for this issue on the 2.2.0 GA code. I simply need to know how to submit it. -- 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

12 years, 3 months

8
15
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1126) Generate-entities creates a class with the error

by Alex Narinsky (JIRA)

Generate-entities creates a class with the error ------------------------------------------------ Key: JBSEAM-1126 URL: http://jira.jboss.com/jira/browse/JBSEAM-1126 Project: JBoss Seam Issue Type: Bug Components: EJB3 Affects Versions: 1.2.1.GA, 1.2.0.GA Reporter: Alex Narinsky Priority: Minor I am using generate-entities. Prior to version 1.2 this worked fine. Starting from version 1.2 one generated class contains the error - double definition of one "In" element. Please, see the text below @Name("moviesHome") public class MoviesHome extends EntityHome<Movies> { @In(create = true) ContactsHome contactsHome; @In(create = true) ProjectsHome projectsHome; @In(create = true) ContactsHome contactsHome; -- 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

12 years, 3 months

5
6
0 / 0

[JBoss JIRA] Created: (JBSEAM-4658) <s:conversationPropagation> better validation of type parameter

by Andrew Wheeler (JIRA)

<s:conversationPropagation> better validation of type parameter --------------------------------------------------------------- Key: JBSEAM-4658 URL: https://jira.jboss.org/browse/JBSEAM-4658 Project: Seam Issue Type: Bug Affects Versions: 2.2.1.CR1 Environment: JBoss AS M3 Reporter: Andrew Wheeler The examples for <s:conversationPropagation> in section 7.1 of the documentation state that a nested conversation is started with type="nested". If used with a commandLink this causes handleConversationPropagation to begin a null pageflow. The result is that a NullPointerException is thrown. Section 33.1.1.5 correctly states that type should be "nest". I suggest that a check is performed on the conversationPropagation control to throw an exception if the wrong type is passed. The documentation should be corrected to be consistent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues January 2012