[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-541) ConversationEntry reports the wrong description
by Norman Richards (JIRA)
ConversationEntry reports the wrong description
-----------------------------------------------
Key: JBSEAM-541
URL: http://jira.jboss.com/jira/browse/JBSEAM-541
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 1.1.0.CR1
Reporter: Norman Richards
Assigned To: Gavin King
The linked forum post shows one example of this bug, though it is not directly the issue the poster is complaining of.
Using the forum application as a guide, start a conversation and then start a nested conversation. End the nested conversation. The description of the parent conversation in the converstion list on will be incorrect. (it will have the name of the current conversation that just ended)
This happens because of the following code:
public String getDescription()
{
if ( isCurrent() )
{
String desc = Conversation.instance().description;
if (desc!=null) return desc;
}
return description;
}
public boolean isCurrent()
{
Manager manager = Manager.instance();
if ( manager.isLongRunningConversation() )
{
return id.equals( manager.getCurrentConversationId() );
}
else if ( manager.isNestedConversation() )
{
return id.equals( manager.getParentConversationId() );
}
else
{
return false;
}
}
The parent conversation entry is considered "current". (isLongRunning() is false and isNestedConversation() is true) Because of this, the ConversationEntry description is ignored in favor of Conversation.instance().description. (Again, Conversation.instance(), is the nested conversation that just ended)
Subsequent requests display the conversation description correctly since they are done in the context of the correct conversation.
The isNestedConversation() check looks to be the source of the problem. I can't figure out what case that would make sense for.
--
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
17 years, 6 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1262) Should be able to customize Hibernate validation messages based on context (by page, or role like Seam component scopes)
by Nathaniel Stoddard (JIRA)
Should be able to customize Hibernate validation messages based on context (by page, or role like Seam component scopes)
------------------------------------------------------------------------------------------------------------------------
Key: JBSEAM-1262
URL: http://jira.jboss.com/jira/browse/JBSEAM-1262
Project: JBoss Seam
Issue Type: Feature Request
Affects Versions: 1.2.1.GA
Reporter: Nathaniel Stoddard
Currently, each validation specified a single message resource to be used as the error message. It would be helpful if there was some way to customize the error messages to be used such that in one case "Contact address is required." is displayed, while in others "Billing address is required", for example. Annotating model classes with validation rules limits the reuse of those classes since the validation messages offer limited flexibility.
Since validated fields in the domain classes aren't necessarily associated with a UIInput on a page, it would be helpful to have more flexible annotations, such as:
@MaxLength(messages = {@Message(role='contactForm', value='contact.too_long'), @Message(role='billingForm', value='billing.too_long')})
private String field;
Also needed would be some way of indicated to the UIView which 'role' should be used when validation takes place.
--
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
17 years, 6 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1009) optionally login-require in a more specific page should be able to override a wildcard login-require
by Leo Baschy (JIRA)
optionally login-require in a more specific page should be able to override a wildcard login-require
----------------------------------------------------------------------------------------------------
Key: JBSEAM-1009
URL: http://jira.jboss.com/jira/browse/JBSEAM-1009
Project: JBoss Seam
Issue Type: Patch
Components: Security
Affects Versions: 1.2.0.GA
Environment: all
Reporter: Leo Baschy
This should be optional to switch on, so no one's existing expectations of security get broken.
The point is about having a generic wildcard <page view-id="*" scheme="http" login-required="true"> to secure the whole site, and then allowing specific pages or specific wildcards to have login-required="false". E.g. for a registration (with preview) section as one cannot be logged in if one isn't registered yet.
Some may suggest instead forcing pages into dedicated secure and not-secure directories, but in reality if there are multiple reasons to force pages into directories different ways (security, hyperlink management, publishability of URLs, etc.), one cannot serve all of them.
--
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
17 years, 6 months
[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
17 years, 6 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-808) StatckOverflowError if factory specifies it's component
by John Ray (JIRA)
StatckOverflowError if factory specifies it's component
-------------------------------------------------------
Key: JBSEAM-808
URL: http://jira.jboss.com/jira/browse/JBSEAM-808
Project: JBoss Seam
Issue Type: Bug
Environment: Latest from CVS
Reporter: John Ray
I accidently specified the name of my component instead of a context variable and this resulted in a StatckOverflowError. For example
@Stateful
@Name("foo")
@Scope(ScopeType.EVENT)
public class FooAction implements Foo {
@Out("bar")
private String bar;
@Factory("foo")
public void initBar() {
...
}
}
I'd sugest changing the code in org.jboss.seam.Component at line 490 to include an if/throw. I highlighted the 2 new lines with an asterisk
if ( method.isAnnotationPresent(org.jboss.seam.annotations.Factory.class) )
{
Init init = (Init) applicationContext.get( Seam.getComponentName(Init.class) ); //can't use Init.instance() here 'cos of unit tests
String contextVariable = toName( method.getAnnotation(org.jboss.seam.annotations.Factory.class).value(), method );
* if (contextVariable.equals(name))
* throw new IllegalStateException("@Factory method can not be for it's own component: " + name);
init.addFactoryMethod(contextVariable, method, this);
}
--
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
17 years, 6 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1770) Infinite loop when in some pages.xml configuration
by Richard Leherpeur (JIRA)
Infinite loop when in some pages.xml configuration
--------------------------------------------------
Key: JBSEAM-1770
URL: http://jira.jboss.com/jira/browse/JBSEAM-1770
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 2.0.0.BETA1
Environment: windows XP, RHEL 5.0
Reporter: Richard Leherpeur
You can download this example on the Seam web site: navigation.zip
I have the following classes:
Code:
@Name("user")
@Scope(ScopeType.CONVERSATION)
public class User implements Serializable {
private String pet;
public String getPet() {
return pet;
}
public void setPet(String pet) {
this.pet = pet;
}
}
Code:
@Name("navigation")
@Scope(ScopeType.CONVERSATION)
public class Navigation implements Serializable {
@In(required=true)
User user;
@Logger
private Log log;
public String animalOutcome(){
if (user == null){
return "Dog"; // Just to make sure we don't return null
}
log.info("********* Outcome: " + user.getPet());
return user.getPet();
}
public User getUser() {
return user;
}
public void setUser(User user) {
this.user = user;
}
}
Code:
@Name("animals")
public class AnimalList
{
private List<String> animals;
@Unwrap
public List<String> unwrap()
{
if (animals == null)
{
animals = new ArrayList<String>();
animals.add("Dog");
animals.add("Cat");
animals.add("Goldfish");
animals.add("Rabbit");
animals.add("Snake");
animals.add("Parrot");
}
return animals;
}
}
Pages.xhtml is defined as followed:
Code:
<pages xmlns="http://jboss.com/products/seam/pages"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.com/products/seam/pages http://jboss.com/products/seam/pages-2.0.xsd">
<page view-id="/pageOne.xhtml">
<begin-conversation join="true" pageflow="navigation" />
</page>
<page view-id="/animalPage.xhtml" action="#{navigation.animalOutcome}">
<navigation>
<rule if-outcome="Dog">
<redirect view-id="/animal/dog.xhtml"/>
</rule>
<rule if-outcome="Cat">
<redirect view-id="/animal/cat.xhtml"/>
</rule>
<rule if-outcome="Goldfish">
<redirect view-id="/animal/goldfish.xhtml"/>
</rule>
<rule if-outcome="Rabbit">
<redirect view-id="/animal/rabbit.xhtml"/>
</rule>
<rule if-outcome="Snake">
<redirect view-id="/animal/snake.xhtml"/>
</rule>
<rule if-outcome="Parrot">
<redirect view-id="/animal/parrot.xhtml"/>
</rule>
</navigation>
</page>
</pages>
The pageflow is defined as:
Code:
<pageflow-definition
xmlns="http://jboss.com/products/seam/pageflow"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.com/products/seam/pageflow http://jboss.com/products/seam/pageflow-2.0.xsd"
name="navigation">
<start-page name="displayChoice" view-id="/pageOne.xhtml">
<redirect/>
<transition name="next" to="animalPage" />
</start-page>
<page name="animalPage" view-id="/animalPage.xhtml">
<end-conversation/>
<redirect/>
</page>
</pageflow-definition>
And finally the pageOne.xhtml:
Code:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:c="http://java.sun.com/jstl/core"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:s="http://jboss.com/products/seam/taglib">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Test Navigation</title>
</head>
<body>
<div id="container">
<h3>Choose an animal</h3>
<h:form>
<h:selectOneMenu value="#{user.pet}">
<s:selectItems value="#{animals}" var="animal" label="#{animal}" noSelectionLabel="Select your pet"/>
</h:selectOneMenu>
<h:commandButton value="Go To Pet Page" action="next" />
</h:form>
</div>
</body>
</html>
When I select an animal, I get the following stacktrace:
Code:
INFO: Added Library from: jar:file:/C:/Jboss/jboss-4.2.0.GA/server/default/tmp/d
eploy/tmp50163navigation.ear-contents/navigation-exp.war/WEB-INF/lib/jsf-facelet
s.jar!/META-INF/jstl-core.taglib.xml
13:23:07,046 INFO [Navigation] ********* Outcome: Cat
13:23:07,218 INFO [Navigation] ********* Outcome: Cat
13:23:07,281 INFO [Navigation] ********* Outcome: Cat
13:23:07,359 INFO [Navigation] ********* Outcome: Cat
13:23:07,437 INFO [Navigation] ********* Outcome: Cat
13:23:07,515 INFO [Navigation] ********* Outcome: Cat
13:23:07,609 INFO [Navigation] ********* Outcome: Cat
13:23:07,687 INFO [Navigation] ********* Outcome: Cat
13:23:07,781 INFO [Navigation] ********* Outcome: Cat
13:23:07,859 INFO [Navigation] ********* Outcome: Cat
1:
Code:
<page view-id="/animalPage.xhtml">
<navigation evaluate="#{navigation.outcome}">
...
where #{navigation.outcome} returns outcome
-> redirection to /animalPage.xhtml (which doesn't exist) because evaluate EL expression is never called
2:
Code:
<page view-id="/animalPage.xhtml" action="#{navigation.animalOutcome}">
<navigation evaluate="#{navigation.outcome}">
...
where #{navigation.animalOutcome} returns void and #{navigation.outcome} returns outcome
-> We enter a loop where action expression is called then evaluate expression is called, etc....
3:
Code:
<page view-id="/animalPage.xhtml" action="#{navigation.animalOutcome}">
<navigation from-action="#{navigation.animalOutcome}">
...
where #{navigation.animalOutcome} returns outcome
-> We enter a loop where action expression is called indefinitely
4:
Code:
<page view-id="/animalPage.xhtml" action="#{navigation.animalOutcome}">
<navigation>
...
where #{navigation.animalOutcome} returns outcome
-> We enter a loop where action expression is called indefinitely
--
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
17 years, 6 months