April 2009 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4104) FilmConverter having @In => NPE

by Daniel Roth (JIRA)

FilmConverter having @In => NPE ------------------------------- Key: JBSEAM-4104 URL: https://jira.jboss.org/jira/browse/JBSEAM-4104 Project: Seam Issue Type: Bug Components: Examples Environment: Jboss.5.01.GA Reporter: Daniel Roth Assignee: Daniel Roth Fix For: 2.1.2.GA -- 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, 1 month

1
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3597) hibernate-validator not copied to lib folder on Vista

by Daniel Roth (JIRA)

hibernate-validator not copied to lib folder on Vista ----------------------------------------------------- Key: JBSEAM-3597 URL: https://jira.jboss.org/jira/browse/JBSEAM-3597 Project: Seam Issue Type: Bug Components: Build Affects Versions: 2.1.0.CR1, 2.1.0.GA Environment: Windows Vista, jdk6, maven 2.0.9, ant 1.7.1 Reporter: Daniel Roth Priority: Minor If I do a clean checkout from the trunk (2.1.1-snapshot) and run 'ant dist', hibernate-validator.jar won't be copied to the lib folder. Consequently, quite a few of the examples fail to build. On my ubuntu linux (8.04) the jar is copied. This is present in tagged 2.1.0.GA version as well. -- 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, 1 month

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4101) build fails on Turkish locale, while compiling generated filese

by Murat ALPAY (JIRA)

build fails on Turkish locale, while compiling generated filese --------------------------------------------------------------- Key: JBSEAM-4101 URL: https://jira.jboss.org/jira/browse/JBSEAM-4101 Project: Seam Issue Type: Bug Components: Build Affects Versions: 2.1.1.GA Reporter: Murat ALPAY Attachments: HtmlSelectItems.java Seam build fails on Turkish, while compiling generated files. I have copy pasted a part of the generated java file that has error. 'I' is converted to 'ı' on Turkish locale but compiler correctly complains prıvate, publıc keywords and such... package org.jboss.seam.ui.component.html; import javax.el.ELException; import javax.el.ValueExpression; import javax.faces.FacesException; import javax.faces.context.FacesContext; import org.jboss.seam.ui.component.UISelectItems; publıc class HtmlSelectItems extends UISelectItems{ publıc statıc fınal String COMPONENT_FAMILY = "javax.faces.SelectItems"; publıc statıc fınal String COMPONENT_TYPE = "org.jboss.seam.ui.SelectItems"; /* * if true the SelectItem will be rendered disabled. Can reference the var variable */ prıvate Boolean _disabled = null; -- 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, 1 month

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4100) a4j:include - FacesContext.getCurrentInstance().getViewRoot().getViewId() isn't always correct

by David Schlotfeldt (JIRA)

a4j:include - FacesContext.getCurrentInstance().getViewRoot().getViewId() isn't always correct ---------------------------------------------------------------------------------------------- Key: JBSEAM-4100 URL: https://jira.jboss.org/jira/browse/JBSEAM-4100 Project: Seam Issue Type: Bug Affects Versions: 2.1.1.GA Reporter: David Schlotfeldt When a request is made by from inside a a4j:include component UIInclude will set the ViewIdHolder to it self. It does this to ensure FacesContext.getCurrentInstance().getViewRoot().getViewId() returns the viewId of the a4j:include. Everything works fine if you only need to access the viewId when its already rendered and its posting back. If you, as I am, change the viewId of the UIInclude (the UIInclude is bound to a property of a managed bean), when the page is rendered back it renders the new "view" assigned to the UIInclude. When its rendered any manage-bean used from inside the a4j:include will see the viewId as the "outter view" not the view assigned to the a4j:include. I believe the simplest and best solution easiest solution is when rendering the children of uiinclude to: --- AjaxContext ajaxContext = AjaxContext.getCurrentInstance(context); ViewIdHolder viewIdHolder = ajaxContext.getViewIdHolder(); // Store reference to current ajaxContext.setViewIdHolder(this); // This is UIInclude // render children here... ajaxContext.setViewIdHolder(viewIdHolder ); // Put previous back --- -- 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, 1 month

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2026) Maven archetypes

by Pete Muir (JIRA)

Maven archetypes ---------------- Key: JBSEAM-2026 URL: http://jira.jboss.com/jira/browse/JBSEAM-2026 Project: JBoss Seam Issue Type: Feature Request Reporter: Pete Muir Assigned To: Dan Allen Fix For: 2.0.x Create some maven archetypes to compliment seam-gen. -- 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, 1 month

9
20
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4094) SeamComponentPostProcessor.postProcessAfterInitialization returns null when Seam component name differs from Spring bean name

by Ravan Naidoo (JIRA)

SeamComponentPostProcessor.postProcessAfterInitialization returns null when Seam component name differs from Spring bean name ----------------------------------------------------------------------------------------------------------------------------- Key: JBSEAM-4094 URL: https://jira.jboss.org/jira/browse/JBSEAM-4094 Project: Seam Issue Type: Bug Components: Spring Affects Versions: 2.1.1.GA Reporter: Ravan Naidoo Given the following Spring xml : <bean id="fooBarBean" class="...."> <seam:component name="fooBarSeam" intercept="false"/> </bean> SeamComponentPostProcessor.postProcessAfterInitialization() returns null when the Seam component name differs from the Spring bean name. This results in a null reference in the Spring Context for bean name "fooBarBean" and indirectly a null Seam Component. SeamComponentPostProcessor.postProcessAfterInitialization() uses the SpringComponent.forSpringBeanName() to identify if a Spring bean (fooBarBean) is a Seam Component. When true, it proceeds to instruct the Component.getInstance() to wrap the bean so that it can be managed by Seam. At this point the SeamComponentPostProcessor passes the Spring bean name (fooBarBean) to the getInstance method instead of the Seam component name (fooBarSeam). The method cannot find the Seam component and returns a null. Unfortunately, my unit test did not pick up this problem due to the fact that the SeamComponentPostProcessor sets a threadlocal ObjectFactory with a direct reference to the bean as instantiated by Spring. So during the execution of the test, the SpringComponent.instanciateIoCBean() used the threadlocal ObjectFactory to get a reference to the bean. In my deployed application, initialization and requests occur in different threads. In that case, the ObjectFactory is null and the Spring BeanFactory is asked for the reference. Which is now null due to the SeamComponentPostProcessor. Another interesting side affect of the above naming problem in combination with the threadlocal ObjectFactory mechanism, was that when I defined 2 Spring beans as Seam components : <bean id="fooBarBean" class="...."> <seam:component/> </bean> <bean id="someOtherBean" class="...."> <seam:component name="someOtherBeanSeam" intercept="false"/> </bean> Then tried Component.getInstance("fooBarBean"), I got the following exception : "java.lang.AssertionError: javax.el.ELException: java.lang.IllegalArgumentException: value of context variable is not an instance of the component bound to the context variable: fooBarBean. If you are using hot deploy, you may have attempted to hot deploy a session or application-scoped component definition while using an old instance in the session." Swapping the order in the xml resolve eliminates the exception. -- 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, 1 month

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4085) Quite login not working

by Stephen Friedrich (JIRA)

Quite login not working ----------------------- Key: JBSEAM-4085 URL: https://jira.jboss.org/jira/browse/JBSEAM-4085 Project: Seam Issue Type: Bug Components: Security Affects Versions: 2.1.1.GA Reporter: Stephen Friedrich When the user is not yet logged in and directly hits a page that is protected with login-required="true" auto-login does not kick in. The user is redirected to the login page in any case. This is due to the current implementation of Pages.isLoginRedirectRequired: private boolean isLoginRedirectRequired(String viewId, Page page) { return page.isLoginRequired() && !viewId.equals( getLoginViewId() ) && !Identity.instance().isLoggedIn(); } IMHO it should better tryLogin() first, like private boolean isLoginRedirectRequired(String viewId, Page page) { if (!page.isLoginRequired() || viewId.equals(getLoginViewId())) { return false; } Identity identity = Identity.instance(); identity.tryLogin(); return !identity.isLoggedIn(); } -- 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, 1 month

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3956) allow customization of charts and chart datasets through callbacks

by Norman Richards (JIRA)

allow customization of charts and chart datasets through callbacks ------------------------------------------------------------------ Key: JBSEAM-3956 URL: https://jira.jboss.org/jira/browse/JBSEAM-3956 Project: Seam Issue Type: Feature Request Components: PDF Reporter: Norman Richards Assignee: Norman Richards Fix For: 2.1.2.CR1 -- 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, 1 month

1
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4088) Add a property to select the JPA persistence provider to use in seam-gen

by Julien Kronegg (JIRA)

Add a property to select the JPA persistence provider to use in seam-gen ------------------------------------------------------------------------ Key: JBSEAM-4088 URL: https://jira.jboss.org/jira/browse/JBSEAM-4088 Project: Seam Issue Type: Feature Request Components: Platform interoperability Affects Versions: 2.1.2.CR1 Reporter: Julien Kronegg Priority: Minor It would be nice to have a property "jpa.provider" which is defaulted to "hibernate" and which can take other values such as "openjpa". Such parameter should be passed to .FTL which can determine which proprietary code to generate. For example, the "yes_no" type leads to the following annotations: Hibernate: @org.hibernate.annotations.Type(type="yes_no") OpenJPA: @org.apache.openjpa.persistence.ExternalValues("true=Y", "false=N") @org.apache.openjpa.persistence.Type(char.class) -- 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, 1 month

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3444) s:defaultAction not work in firefox, and patch

by liu lei (JIRA)

s:defaultAction not work in firefox, and patch ---------------------------------------------- Key: JBSEAM-3444 URL: https://jira.jboss.org/jira/browse/JBSEAM-3444 Project: Seam Issue Type: Bug Components: JSF Controls Affects Versions: 2.0.2.SP1 Reporter: liu lei s:defaultAction not work in firefox. the problem is that firefox donnot have the "click()" event, but have the "onclick()" event. So i change the "click()" to "onclick()", which is supported both in ie and firefox. String functionBody = "{var keycode;" + "if (window.event) keycode = window.event.keyCode;" + "else if (event) keycode = event.which;" + "else return true;" + "if (keycode == 13) " + // "{ document.getElementById('" + actionComponentId + "').click();return false; } " + //wrong!!!!!!!!! "{ document.getElementById('" + actionComponentId + "').click();return false; } " + //right!!!!!!!!!!!!! "else return true; }"; -- 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, 1 month

3
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues April 2009