[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4342) RemotingTest.testMapWrapper() relies on undefined behavior
by Jozef Hartinger (JIRA)
RemotingTest.testMapWrapper() relies on undefined behavior
----------------------------------------------------------
Key: JBSEAM-4342
URL: https://jira.jboss.org/jira/browse/JBSEAM-4342
Project: Seam
Issue Type: Bug
Components: Remoting, Test Harness
Affects Versions: 2.2.0.GA
Environment: Java(TM) SE Runtime Environment (build pxi3260sr4-20090219_01(SR4))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 …
[View More]jvmxi3260-20090215_29883 (JIT enabled, AOT enabled)
J9VM - 20090215_029883_lHdSMr
JIT - r9_20090213_2028
GC - 20090213_AA)
JCL - 20090218_01
Reporter: Jozef Hartinger
Assignee: Shane Bryzak
Fix For: 2.2.1.CR1
The test expects the elements to be returned in the same order in which they were created:
<map><element><k><str>bar</str></k><v><str>zzzzz</str></v></element><element><k><str>foo</str></k><v><str>aaaaa</str></v></element></map>
However, on IBM JVM, the order of elements is not preserved in the returned tree, so the tree looks like this:
<map><element><k><str>foo</str></k><v><str>aaaaa</str></v></element><element><k><str>bar</str></k><v><str>zzzzz</str></v></element></map>
The assumption of the test is incorrect, because the marshal() method of MapWrapper class iterates over a Set of keys and thus the order cannot be guaranteed.
--
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
[View Less]
15 years, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4348) <begin-task> clobbers the conversation flush-mode
by Marshall Treadaway (JIRA)
<begin-task> clobbers the conversation flush-mode
-------------------------------------------------
Key: JBSEAM-4348
URL: https://jira.jboss.org/jira/browse/JBSEAM-4348
Project: Seam
Issue Type: Bug
Components: BPM
Affects Versions: 2.1.1.GA
Environment: JBoss AS 4.2.2, Seam 2.1.1 GA, jBPM 3.2.1 (I think)
Reporter: Marshall Treadaway
As far as I can tell, using the <begin-task> tag in a …
[View More]page.xml file for a page seems to set the flush-mode to "auto" and ignore any other declared flush-mode settings.
While developing a series of simple task pages for a jBPM process I am implementing, I noticed that form data was being flushed and committed to the database immediately after been submitted via an AJAX request. I supposed this was because the flush-mode was not what I thought it was.
(First issue, there is no Conversation.instance().getFlushModeType() method, which would have been useful)
-The link used to get to this page used "end" for conversation propagation.
-The page.xml for the page used <begin-conversation join="true" flush-mode="MANUAL"/> and <begin-task task-id="#{taskId}"/>
I tried adding flush-mode="manual" to the begin-task tag, but it had no affect (changes were still being flushed and committed to the database. I tried removing the <begin-conversation> tag altogether after reading that <begin-task> should start a conversation anyways (or was it <start-task>?). I then got an error about needing to use "join=true" for my conversation settings.
Finally, I was able to get around this by using a page action like below, leaving the <begin-conversation join="true" flush-mode="MANUAL">, and removing the <begin-task> tag.
@RequestParameter
private Long taskId;
public void beginTask(){
if(taskId != null){
BusinessProcess.instance().resumeTask(taskId);
Conversation.instance().changeFlushMode(FlushModeType.MANUAL);
}
}
I hope this is coherent. Also, this is my first time to report an issue here. Forgive me if I did anything wrong.
--
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
[View Less]
15 years, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4347) NullPointerException in UISelectItems when var attribute is not specified in s:selectItems
by Julien Kronegg (JIRA)
NullPointerException in UISelectItems when var attribute is not specified in s:selectItems
------------------------------------------------------------------------------------------
Key: JBSEAM-4347
URL: https://jira.jboss.org/jira/browse/JBSEAM-4347
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.2.GA
Reporter: Julien Kronegg
Priority: Minor
When having a <s:selectItems value="#{myList}"/> , a …
[View More]NullPointerException is raised:
java.lang.NullPointerException
at com.sun.faces.context.RequestMap.put(ExternalContextImpl.java:1066)
at org.jboss.seam.ui.component.UISelectItems$ContextualSelectItem.setup(UISelectItems.java:73)
at org.jboss.seam.ui.component.UISelectItems$ContextualSelectItem.create(UISelectItems.java:90)
at org.jboss.seam.ui.component.UISelectItems.asSelectItems(UISelectItems.java:195)
at org.jboss.seam.ui.component.UISelectItems.getValue(UISelectItems.java:166)
at org.ajax4jsf.util.SelectUtils.getSelectItems(SelectUtils.java:84)
at org.richfaces.renderkit.InplaceSelectBaseRenderer.getItemLabel(InplaceSelectBaseRenderer.java:175)
....
>From the referenced forum thread and from UISelectItems.java:73, it turns out that the var attribute is not specified.
Instead of an ugly NPE, Seam should fail gracefully by one of these solutions:
1) throwing a comprehensive exception message
2) having a property "var" as mandatory
--
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
[View Less]
15 years, 5 months