February 2008 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1954) JDK 1.6 tests failing

by Pete Muir (JIRA)

JDK 1.6 tests failing --------------------- Key: JBSEAM-1954 URL: http://jira.jboss.com/jira/browse/JBSEAM-1954 Project: JBoss Seam Issue Type: Task Affects Versions: 2.0.0.CR1 Reporter: Pete Muir Running Seam testsuite with JDK 1.6 is giving errors (not surprisingly). http://hudson.jboss.org/hudson/job/JBossSeam-sun16/ -- 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, 3 months

5
15
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2339) add javadoc target to seam-gen project

by Dan Allen (JIRA)

add javadoc target to seam-gen project -------------------------------------- Key: JBSEAM-2339 URL: http://jira.jboss.com/jira/browse/JBSEAM-2339 Project: JBoss Seam Issue Type: Feature Request Components: Tools Affects Versions: 2.0.0.GA Reporter: Dan Allen Priority: Minor Fix For: 2.0.x We have just about every other standard Ant target configured, why not have one to generate JavaDoc? This would really impress managers as well as developers. Besides, who doesn't generated JavaDoc at some point these days? -- 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, 3 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2033) style h:messages (perhaps using rich:messages)

by Dan Allen (JIRA)

style h:messages (perhaps using rich:messages) ---------------------------------------------- Key: JBSEAM-2033 URL: http://jira.jboss.com/jira/browse/JBSEAM-2033 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.1.GA The styles used for the h:messages still use the old style before RichFaces was added (It is beige and orange). This looks really bad. RichFaces just added a sweet looking message style in 3.1. Let's use that! -- 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, 3 months

3
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2133) inline EL in component property value not properly detected

by Dan Allen (JIRA)

inline EL in component property value not properly detected ----------------------------------------------------------- Key: JBSEAM-2133 URL: http://jira.jboss.com/jira/browse/JBSEAM-2133 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 2.0.0.CR2 Reporter: Dan Allen Assigned To: Dan Allen Priority: Critical Fix For: 2.0.1.GA Currently, the EL notation in a property is only being evaluated if the property starts with "#{". There are two problems with this assumption. 1. Inline EL can only be used if the property starts with an expression (i.e. <property name="message">#{applicationName} is a cool application</property>) 2. There is no way to escape EL so that is is evaluated by the property accepting the string (rather than when the value is assigned). The correct behavior would be to treat the property value as a value expression if it CONTAINS "#{". The benefits are two fold: 1. A property value can use inline EL that is evaluated when the property value is set (see above) 2. The resolved value of the property can be EL (delayed EL) that is to be interpreted by the component as needed. This is done by escaping the EL per the unified EL spec (i.e. <property name="created-message">The user \#{user.name} has been created!</property) Surprisingly, everything is already in place. All that needs to happen is the check for EL needs to change from "startsWith" to "contains". -- 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, 3 months

3
13
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2520) EL Expressions in JPDL files cause EL exceptions AGAIN

by David Heggie (JIRA)

EL Expressions in JPDL files cause EL exceptions AGAIN ------------------------------------------------------ Key: JBSEAM-2520 URL: http://jira.jboss.com/jira/browse/JBSEAM-2520 Project: JBoss Seam Issue Type: Bug Components: BPM Affects Versions: 2.0.1.CR1 Reporter: David Heggie The same thing that happened in the linked issue JBSEAM-1937 is happening again. This time it is only causing exceptions when evaluating a simple value expression eg. #{someComponent}. Looking through the code the problem is happening again in the org.jboss.seam.bpm.SeamExpressionEvaluator where it "Successfully" creates a MethodExpression and then tries to invoke it which causes a ELException which is not caught (only MethodNotFoundException is caught) and the call exits without trying to evaluate the expression as a ValueExpression. -- 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, 3 months

4
11
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1277) ServerConversationContext does not process removals / additions when an exception propagates up

by Chris Rudd (JIRA)

ServerConversationContext does not process removals / additions when an exception propagates up ----------------------------------------------------------------------------------------------- Key: JBSEAM-1277 URL: http://jira.jboss.com/jira/browse/JBSEAM-1277 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.2.0.GA Reporter: Chris Rudd I have an Stateful EJB Component that throws an exception (this is expected, im testing that the system can recover from that error). This causes the component to be removed from the seam contexts (via the RemoveInterceptor). Then the exception floats up and is caught by the ExceptionFilter, and is redirected to a new view. All that works correctly. BUT when I return to the conversation that contained the EJB component, the component is still in it (even though the RemoveInterceptor removed it). Ive traced it down to this : ServerConversationContext.remove -- this adds the removal to the removals list, but does not update the session.attributes (the real storage for the context). ServerConversationContext.flush -- this applies the removals / additions to the session attributes map. The problem is that flush is never called when an exception propagates out. Thus the changes to that context are never flushed to the session attributes. -- 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, 3 months

4
9
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1902) Cannot use Seam EntitySecurityListener and MDBs

by Mike Pettypiece (JIRA)

Cannot use Seam EntitySecurityListener and MDBs ----------------------------------------------- Key: JBSEAM-1902 URL: http://jira.jboss.com/jira/browse/JBSEAM-1902 Project: JBoss Seam Issue Type: Bug Components: Security Affects Versions: 2.0.0.BETA1 Reporter: Mike Pettypiece After turning on Seam's EntitySecurityListener, the follow exception occurs when working with a @Restrict-annotated entity from a MDB. java.lang.IllegalStateException: No active session context at org.jboss.seam.security.Identity.instance(Identity.java:157) at org.jboss.seam.security.EntitySecurityListener.postLoad(EntitySecurityListener.java:26) ... There obviously isn't a session context in this case. Seam probably shouldn't check security permissions when there is no active session context. As well it would be useful to be able to programatically turn off security on a per-Identity basis. Please see the referenced Forum link for more details. -- 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, 3 months

4
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2469) add postback flag to page actions

by Dan Allen (JIRA)

add postback flag to page actions --------------------------------- Key: JBSEAM-2469 URL: http://jira.jboss.com/jira/browse/JBSEAM-2469 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 2.0.1.CR1 Reporter: Dan Allen Assigned To: Dan Allen Fix For: 2.0.x Page actions are incredibly useful, but sometimes they can get in the way during a postback. I would like to see a postback attribute added to the <action> tag that can be used to disable the action on postback. It's possible using a conditional, but it is ugly and a lot of typing. Here is the logic that would go into Pages.java private boolean isPostBack(FacesContext facesContext) { return facesContext.getExternalContext().getRequestParameterMap(). containsKey(ResponseStateManager.VIEW_STATE_PARAM); } The conditional alternative would be: <action execute="#{component.action}" if="#{empty param['javax.faces.ViewState']}"/> -- 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, 3 months

5
22
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2348) seam generate-ui fails for @OneToOne @PrimaryKeyJoinColumn annotated fields

by Thorsten Kunz (JIRA)

seam generate-ui fails for @OneToOne @PrimaryKeyJoinColumn annotated fields --------------------------------------------------------------------------- Key: JBSEAM-2348 URL: http://jira.jboss.com/jira/browse/JBSEAM-2348 Project: JBoss Seam Issue Type: Bug Components: Tools Affects Versions: 2.0.0.GA Environment: Seam 2.0.0.GA JBoss Tools Reporter: Thorsten Kunz Since I do use JBoss Tool I assume that this is cause by an error in the underlying seam generate-ui. It fails if you have entities annotated like this: public class User implements Serializable { @Id @GeneratedValue private Long id; @OneToOne @PrimaryKeyJoinColumn private UserData userData; } public class UserData implements Serializable { @Id private Long id; @OneToOne @PrimaryKeyJoinColumn private User user; } This will result in this Exception: org.eclipse.core.runtime.CoreException: org.hibernate.tool.hbm2x.ExporterException: Error while processing template view/list.xhtml.ftl org.eclipse.core.runtime.CoreException[666]: org.hibernate.tool.hbm2x.ExporterException: Error while processing template view/list.xhtml.ftl Caused by: freemarker.core.InvalidReferenceException: Expression property.value.typeName is undefined on line 39, column 6 in view/list.xhtml.ftl -- 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, 3 months

5
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1943) Support for destroying the entire ConversationStack

by Jacob Orshalick (JIRA)

Support for destroying the entire ConversationStack --------------------------------------------------- Key: JBSEAM-1943 URL: http://jira.jboss.com/jira/browse/JBSEAM-1943 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 2.0.0.CR1 Reporter: Jacob Orshalick There are situations where I would like to be able to destroy the entire conversation stack if a particular action occurs (say a user cancels everything during a nested conversation, an exception occurs during a nested conversation, etc). I am currently accomplishing this through the following: private void endRootConversation() { Conversation conversation = Conversation.instance(); while(conversation.isNested()) { conversation.root(); } conversation.endBeforeRedirect(); } I would prefer to say something like @End(root=true) or specifying conversationPropogation="endRoot". Similar discussions on the forum are: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112414&postdays=... http://www.jboss.com/index.html?module=bb&op=viewtopic&t=118936&postdays=... -- 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, 3 months

4
26
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues February 2008