November 2008 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3635) jboss-el jar do not have version information in jar manifest

by Marek Novotny (JIRA)

jboss-el jar do not have version information in jar manifest ------------------------------------------------------------ Key: JBSEAM-3635 URL: https://jira.jboss.org/jira/browse/JBSEAM-3635 Project: Seam Issue Type: Task Components: EL Reporter: Marek Novotny jboss-el.jar should have version number in Manifest.MF file for easy recognition what version of jar is 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

15 years, 6 months

1
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3688) IllegalStateException: No active event context with s:graphicImage and a call to "window.print()" function in IE

by Denis Forveille (JIRA)

IllegalStateException: No active event context with s:graphicImage and a call to "window.print()" function in IE ---------------------------------------------------------------------------------------------------------------- Key: JBSEAM-3688 URL: https://jira.jboss.org/jira/browse/JBSEAM-3688 Project: Seam Issue Type: Bug Components: JSF Controls Affects Versions: 2.1.0.SP1, 2.0.2.SP1 Reporter: Denis Forveille We have a page with an "s:graphicImage" tag like this <s:graphicImage value="#{materielDetailVueCtrl.form.image}" /> On the page there is a button that performs a call to "javascript:window.print();" When used in firefox, everything works fine. With IE 6, when we use this button, we receive a "No active event context" exception (See attached traceback) In FF everything works fine because, I think, the image is cached by default In IE 6, the image is not cached. Besides the exception, one solution would be to add the possibility to add a parameter to the s:graphicImage tag that will add a header in the response send for the mage to the browser For now we've hard-coded the following in org.jboss.seam.ui.graphicImage.GraphicImageResource : response.addHeader("Cache-Control","max-age=1800,must-revalidate"); That make IE 6 happy... -- 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, 6 months

1
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3686) seam-gen does not handle wire correctly on edit for creation

by Valerie Griffin (JIRA)

seam-gen does not handle wire correctly on edit for creation ------------------------------------------------------------ Key: JBSEAM-3686 URL: https://jira.jboss.org/jira/browse/JBSEAM-3686 Project: Seam Issue Type: Bug Components: Tools Affects Versions: 2.1.0.GA Environment: Hibernate, Richfaces Reporter: Valerie Griffin I've got a seam-gen'd project with quite a few foreign keys. Some of the foreign keys are used to create composite primary keys. The related entities are, quite appropriately, used in the generated ...Home.isWired method as: public boolean isWired() { if (getInstance().getSsoApplication() == null) return false; return true; } The ...Edit.xhtml code includes a save button appropriate for new entries: <h:commandButton id="save" value="Save" action="#{appPermissionHome.persist}" disabled="#{!appPermissionHome.wired}" rendered="#{!appPermissionHome.managed}"/> It is valid for the save button to be enabled only when the underlying component has been wired, but the generated xhtml does not actually cause anything to become wired! It includes: <s:decorate id="appNameField" template="layout/edit.xhtml"> <ui:define name="label">App name</ui:define> <h:inputText id="appName" disabled="#{appPermissionHome.managed}" required="true" size="20" maxlength="20" value="#{appPermissionHome.instance.id.appName}"> <a:support event="onblur" reRender="appNameField" bypassUpdates="true" ajaxSingle="true"/> </h:inputText> </s:decorate> The a:support property reRender needs to include ",save" to force the button to decide whether or not it needs to be enabled. The bypassUpdates property needs to be "false" (yay forced updates!) to force the update that isWired checks. I don't know for certain that this is enough to fix the problem because i changed my actual code to use a dropdown (h:selectOneMenu with s:selectItems and s:convertEntity) connected to the instance. To make that work, I added code to update id.appName in the entity's setSsoApplication method. -- 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, 6 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2704) Performance during iteration (datatable, repeat) in the UI with value bindings that run through interceptors

by Siarhei Dudzin (JIRA)

Performance during iteration (datatable, repeat) in the UI with value bindings that run through interceptors ------------------------------------------------------------------------------------------------------------ Key: JBSEAM-2704 URL: http://jira.jboss.com/jira/browse/JBSEAM-2704 Project: JBoss Seam Issue Type: Bug Components: Performance and Scalability Affects Versions: 2.0.1.GA, 2.0.0.GA Environment: Seam 2.0.0, 2.0.1 Reporter: Siarhei Dudzin "Since we don't cache this, a particular backing bean might be called hundreds or thousands of times during rendering of a datatable, if a value binding has to be evaluated for each row. If the backing bean is a Seam component, injection of dependencies will occur for every call, involving potentially thousands of map lookups." There is a discussion thread with a bit more data: http://www.seamframework.org/Community/SeamPerformanceOptimization The issue is also recognized at the seamframework.org site itself: http://www.seamframework.org/Documentation/TuningTheSeamWebsite#H-Iterati... Since the issue it known, this JIRA report is created for better traceability. -- 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, 6 months

6
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3486) Identity Management API allowing inheritance of entity annotations

by Leandro Hermida (JIRA)

Identity Management API allowing inheritance of entity annotations ------------------------------------------------------------------ Key: JBSEAM-3486 URL: https://jira.jboss.org/jira/browse/JBSEAM-3486 Project: Seam Issue Type: Feature Request Affects Versions: 2.1.0.CR1, 2.1.0.BETA1 Reporter: Leandro Hermida Priority: Minor In reference to question posed on forum: http://www.seamframework.org/Community/IdentityManagementEntityAnnotation... I was wondering if the Identity Management API supports putting some of the entity annotations in parent classes? As an example I have a User entity bean which will have @UserPrincipal, @UserPassword, @UserEnabled, @UserRoles and it inherits from a Person class which has the first and last name and thus @UserFirstName and @UserLastName. -- 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, 6 months

2
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3683) SEAM 2.1.0 documentation does not mention the implied namespace feature

by Vimal Kansal (JIRA)

SEAM 2.1.0 documentation does not mention the implied namespace feature ----------------------------------------------------------------------- Key: JBSEAM-3683 URL: https://jira.jboss.org/jira/browse/JBSEAM-3683 Project: Seam Issue Type: Bug Components: Documentation Issues Affects Versions: 2.1.0.GA Reporter: Vimal Kansal SEAM 2.1.0 has implied namespace feature which makes use of @Namespace annotation optional for namespace mapping. This feature is not mentioned in the documentation -- 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, 7 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3682) empty data for date type throws exception in JXLHelper.createCell

by Ted Jenkins (JIRA)

empty data for date type throws exception in JXLHelper.createCell ----------------------------------------------------------------- Key: JBSEAM-3682 URL: https://jira.jboss.org/jira/browse/JBSEAM-3682 Project: Seam Issue Type: Bug Components: Excel Affects Versions: 2.1.0.GA Reporter: Ted Jenkins If data type is missing/empty string, and it is cellType date, a String exception will be thrown. I'm thinking it should probably just fail gracefully, like so: case date: if(null == data || data.equals("")) { return new Label(column, row, data.toString(), cellFormat); } else { return new DateTime(column, row, (Date) data, cellFormat); } -- 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, 7 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3681) WTF code in RuleBasedPermissionResolver

by egor kolesnikov (JIRA)

WTF code in RuleBasedPermissionResolver --------------------------------------- Key: JBSEAM-3681 URL: https://jira.jboss.org/jira/browse/JBSEAM-3681 Project: Seam Issue Type: Bug Components: Security Affects Versions: 2.1.0.SP1 Reporter: egor kolesnikov We've got some lulz reading this today: public class RuleBasedPermissionResolver implements PermissionResolver, Serializable //skipped private void synchronizeContext() { Identity identity = Identity.instance(); getSecurityContext().insert(identity.getPrincipal()); if (getSecurityContext() != null) // just a BRILLIANT check after calling insert() on the previous line { //skipped } } } Please fix this "professional open source" code in the next version :) -- 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, 7 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2562) 'Transaction failed' JSF message when number of restriction in EntityQuery changes

by Siarhei Dudzin (JIRA)

'Transaction failed' JSF message when number of restriction in EntityQuery changes ---------------------------------------------------------------------------------- Key: JBSEAM-2562 URL: http://jira.jboss.com/jira/browse/JBSEAM-2562 Project: JBoss Seam Issue Type: Bug Components: Framework Affects Versions: 2.0.1.GA Environment: JBoss AS 4.2.2, Windows XP Reporter: Siarhei Dudzin When getRestrictions() from EntityQuerry returns dynamic list with restrictions a JSF error message 'Transaction failed' is shown (no exceptions just a message). I noticed this happens when the size of the list is decreased in comparison with the previous request (There is also a warning in the logs). While this JSF message is shown the query still works! After some debugging I've found that the underlying error is that a value binding could not be found. A temprorarily workaround is to keep the restriction list constant by filling the 'gaps' with placeholders like #{true}=true (just to keep the size constant). -- 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, 7 months

3
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2881) Conversation Switcher doesn't work with natural conversations

by Caleb Land (JIRA)

Conversation Switcher doesn't work with natural conversations ------------------------------------------------------------- Key: JBSEAM-2881 URL: http://jira.jboss.com/jira/browse/JBSEAM-2881 Project: Seam Issue Type: Bug Components: JSF Controls, JSF Integration Affects Versions: 2.0.2.CR1 Environment: Seam 2.0.2.CR1, Mac OS X 10.5, Java 1.5.0_13 Reporter: Caleb Land The Switcher component's (org.jboss.seam.faces.Switcher) switch() method does not work correctly when using natural conversations. The issue is related to line 102 (in trunk and in 2.0.2.CR1) where seam tests whether the selected item is an outcome or a conversation id: boolean isOutcome = conversationIdOrOutcome==null || !Character.isDigit( conversationIdOrOutcome.charAt(0) ); The problem is that with natural conversations, the value of conversationIdOrOutcome is something like "accountEdit:4" so the switcher thinks it's a view. I copied the code from the Switcher and created a new component and replaced that line with: boolean isOutcome = conversationIdOrOutcome==null || (!Character.isDigit(conversationIdOrOutcome.charAt(0)) && conversationIdOrOutcome.indexOf(':') < 0); and it works correctly. Of course this approach is naive, but it seems to work for me. -- 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, 7 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 November 2008