May 2007 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-993) s:graphicImage should optionally expire images from the session

by Pete Muir (JIRA)

s:graphicImage should optionally expire images from the session --------------------------------------------------------------- Key: JBSEAM-993 URL: http://jira.jboss.com/jira/browse/JBSEAM-993 Project: JBoss Seam Issue Type: Bug Components: JSF Affects Versions: 1.2.0.GA Reporter: Pete Muir Assigned To: Pete Muir Priority: Minor Currently images are expired immediately. Use a async timed seam method to expire methods from the store. -- 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

18 years, 10 months

2
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1038) fileUpload should support styleClass

by Reind D (JIRA)

fileUpload should support styleClass ------------------------------------- Key: JBSEAM-1038 URL: http://jira.jboss.com/jira/browse/JBSEAM-1038 Project: JBoss Seam Issue Type: Bug Affects Versions: 1.1.7.CR1 Reporter: Reind D fileUpload should support styleClass. -- 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

18 years, 10 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1239) Throw distinquishable exception time if size limit of MultipartRequest is exceeded

by Christian Bauer (JIRA)

Throw distinquishable exception time if size limit of MultipartRequest is exceeded ---------------------------------------------------------------------------------- Key: JBSEAM-1239 URL: http://jira.jboss.com/jira/browse/JBSEAM-1239 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Christian Bauer Priority: Minor java.lang.RuntimeException: Multipart request is larger than allowed size org.jboss.seam.web.MultipartRequest.<init>(MultipartRequest.java:282) org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:74) org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49) org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49) org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84) org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:96) org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:220) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) I can't catch this and display a proper error message. Also the pages.xml exception handling doesn't catch it, since it happens too early in a filter. If there is any reasonable way we need to make this exception case more customizable. -- 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

18 years, 10 months

2
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1161) s:link breaks @DataModelSelection functionallity, when having a page action

by Daniel Wiell (JIRA)

s:link breaks @DataModelSelection functionallity, when having a page action --------------------------------------------------------------------------- Key: JBSEAM-1161 URL: http://jira.jboss.com/jira/browse/JBSEAM-1161 Project: JBoss Seam Issue Type: Bug Affects Versions: 1.2.1.GA Environment: Seam 1.2.1.GA, MyFaces 1.1.6 nighly from march, Facelets 1.1.11 Reporter: Daniel Wiell If a s:link is used to select a row in a dataTable. A field annotated with @DataModelSelection always get the first row of the dataModel **if** the view has a page action. When the page action is removed or a regular h:commandLink is used, everything works as expected. Here are some code to help reproducing this: ------------------------ The controller @Name("fruitStore") public class FruitStore { public static final List<Fruit> FRUITS = Arrays.asList( new Fruit(1, "Apple", "Red"), new Fruit(2, "Pear", "Green"), new Fruit(3, "Orange", "Orange"), new Fruit(4, "Banana", "Yellow")); @DataModel(scope = ScopeType.PAGE) private List<Fruit> fruits = FRUITS; @DataModelSelection private Fruit selectedFruit; public Fruit getSelectedFruit() { return selectedFruit; } public String init() { return null; } } ------------------------ The domain object public class Fruit { private long id; private String name; private String color; public Fruit(long id, String name, String color) { this.id = id; this.name = name; this.color = color; } public long getId() { return id; } public void setId(long id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } public String getColor() { return color; } public void setColor(String color) { this.color = color; } } ------------------------ Relavant parts from pages.xml <page view-id="/fruitSelection.xhtml" action="#{fruitStore.init}"> <navigation> <rule if-outcome="selectFruit"> <begin-conversation/> <redirect view-id="/fruitOverview.xhtml"> <param name="fruitId" value="#{fruitStore.selectedFruit.id}"/> </redirect> </rule> </navigation> </page> ------------------------ fruitSelection.xhtml <?xml version='1.0' encoding='UTF-8'?> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html" xmlns:s="http://jboss.com/products/seam/taglib"> <head></head> <body> <h:form> Select a fruit: <h:dataTable var="fruit" value="#{fruits}"> <h:column>  <s:link value="#{fruit.name}" action="selectFruit"/> </h:column> <h:column>  <h:commandLink value="#{fruit.name}" action="selectFruit"/> </h:column> </h:dataTable> </h:form> </body> -- 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

18 years, 10 months

3
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-952) Automatically search for unknown wiki links

by Christian Bauer (JIRA)

Automatically search for unknown wiki links ------------------------------------------- Key: JBSEAM-952 URL: http://jira.jboss.com/jira/browse/JBSEAM-952 Project: JBoss Seam Issue Type: Feature Request Components: Wiki Reporter: Christian Bauer Assigned To: Christian Bauer Priority: Minor Don't bail out on /wiki/SomeUnknownWikiName or /wiki/someunknownwikiname but do a document search for 'unknownwikiname' instead. Similar to how http://www.php.net/searchforthis works. -- 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

18 years, 10 months

1
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1366) SeamApplicationMessageBundle doesn't follow ResourceBundle contract

by Michael Youngstrom (JIRA)

SeamApplicationMessageBundle doesn't follow ResourceBundle contract ------------------------------------------------------------------- Key: JBSEAM-1366 URL: http://jira.jboss.com/jira/browse/JBSEAM-1366 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.3.0.ALPHA Reporter: Michael Youngstrom Fix For: 1.3.0.ALPHA SeamApplicationMessageBundle is backed by the Messages component. This is fine except if a that does not exist is specified then Messages will return the key as the value. This works great for Messages but it can cause problems for SeamApplicationMessageBundle. Many existing JSF components have an algorithm similar to this to display messages and other component text: 1. Get faces-config specified bunleName 2. Try to get value from resource bundle of specified bundleName 3. Catch MissingResourceException 4. Try component built in resource bundle for default message. Since SeamApplication returns "org.jboss.seam.jsf.SeamApplicationMessageBundle" by default if there is no user specified message-bundle in the faces-config this could cause some problems. Is it possible for SeamApplicationMessageBundle to throw MissingResourceException if the key is not found in Messages instead of simply returning what Messages returns which is the key itself? Mike -- 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

18 years, 10 months

3
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1298) UIDecorate ignores programmatic faces messages

by Christian Bauer (JIRA)

UIDecorate ignores programmatic faces messages ---------------------------------------------- Key: JBSEAM-1298 URL: http://jira.jboss.com/jira/browse/JBSEAM-1298 Project: JBoss Seam Issue Type: Bug Components: Core Reporter: Christian Bauer <s:decorate id="usernameDecorate" template="includes/formFieldDecorate.xhtml"> <ui:define name="label">Username</ui:define> <h:inputText tabindex="4" size="16" maxlength="16" required="true" id="username" value="#{userHome.instance.username}"> <a:support event="onblur" action="#{userHome.validateUsername}" reRender="usernameDecorate"/> </h:inputText> </s:decorate> The userHome.validateUsername() method: User foundUser = userDAO.findUser(getInstance().getUsername(), false, false); if ( foundUser != null && foundUser != getInstance() ) { facesMessages.addToControlFromResourceBundleOrDefault( "username", FacesMessage.SEVERITY_ERROR, getMessageKeyPrefix() + "usernameExists", "A user with that name already exists." ); return false; } return true; (This is actually wrapped again, the validateUsername() method returns void.) The decoration is not rendered as invalid. If I remove the identifier of the input field, a global message is correctly displayed. -- 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

18 years, 10 months

2
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1160) EMF implicit lookup/resolve precedence

by Christian Bauer (JIRA)

EMF implicit lookup/resolve precedence -------------------------------------- Key: JBSEAM-1160 URL: http://jira.jboss.com/jira/browse/JBSEAM-1160 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Christian Bauer Currently impossible to use WAR deployment and Unit testing. Only way to configure it is as follows: <core:managed-persistence-context name="entityManager" auto-create="true" entity-manager-factory="#{wikiEntityManagerFactory}" persistence-unit-jndi-name="java:/EntityManagerFactories/wiki"> </core:managed-persistence-context> <core:entity-manager-factory installed="@seamPersistenceUnit@" name="wikiEntityManagerFactory" persistence-unit-name="wiki"/> <core:ejb installed="@embeddedEjb@"/> So either the EMF is started by Seam during WAR deployment (seamPersistenceUnit) and available as a component instance in application scope, or the EMF is deployed by the E-EJB3 container and bound to JNDI with the magic JBoss configuration property in persistence.xml. The managed-persistence-context now needs to access the EMF polymorphically, no matter where it is bound. If you try the above code, you will see that the entity-manager-factory attribute always has precedence, and if it resolves to null, you get an NPE. Instead, the JNDI lookup should be attempted. -- 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

18 years, 10 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1168) Attempting to configure parent conversation id parameter throws exception

by Mike Quilleash (JIRA)

Attempting to configure parent conversation id parameter throws exception ------------------------------------------------------------------------- Key: JBSEAM-1168 URL: http://jira.jboss.com/jira/browse/JBSEAM-1168 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.1.6.GA Environment: Any Reporter: Mike Quilleash Defining this (note this is what the xsd defines) <core:manager conversation-timeout="5000" conversation-id-parameter="cid" conversation-is-long-running-parameter="clr" parent-conversation-id-parameter="pcid"/> Throw the following: java.lang.IllegalArgumentException: no such setter method: org.jboss.seam.core.Manager.parentConversationIdParameter at org.jboss.seam.util.Reflections.getSetterMethod(Reflections.java:198) at org.jboss.seam.Component.initInitializers(Component.java:375) at org.jboss.seam.Component.<init>(Component.java:266) at org.jboss.seam.Component.<init>(Component.java:207) at org.jboss.seam.init.Initialization.addComponent(Initialization.java:781) at org.jboss.seam.init.Initialization.addComponents(Initialization.java:690) at org.jboss.seam.init.Initialization.init(Initialization.java:451) at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:33) As Manager.setParentConversationIdParameter() is protected, not public. -- 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

18 years, 10 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1186) log API improvement

by Mikhail Grushinskiy (JIRA)

log API improvement ------------------- Key: JBSEAM-1186 URL: http://jira.jboss.com/jira/browse/JBSEAM-1186 Project: JBoss Seam Issue Type: Feature Request Components: Core Environment: all Reporter: Mikhail Grushinskiy Priority: Minor Instead of log.debug("Creating new order for user: #0 product: #1 quantity: #2", user.username(), product.name(), quantity); #0, #1, #2 why couldn't we just always use #? Parameters are already ordered. There is no need to number them in the format string, this will be just another source of errors. Another question what happens if you have more parameters after format string than #n placeholders. I think in such case these parameters should be appended at the end of the format string in output so not values are lost . -- 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

18 years, 10 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues May 2007