February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3582) Get the ejb3-4.0 testsuite passing

by Dimitris Andreadis (JIRA)

Get the ejb3-4.0 testsuite passing ---------------------------------- Key: JBAS-3582 URL: http://jira.jboss.com/jira/browse/JBAS-3582 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Dimitris Andreadis Assigned To: Bill Burke Fix For: JBossAS-4.0.5.CR1 There are currenlty 28 failures -- 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

19 years, 3 months

3
10
0 / 0

[JBoss JIRA] Created: (JBAS-4103) testsuite testcases' reports overwritten

by Aleksandar Kostadinov (JIRA)

testsuite testcases' reports overwritten ---------------------------------------- Key: JBAS-4103 URL: http://jira.jboss.com/jira/browse/JBAS-4103 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Reporter: Aleksandar Kostadinov When JBoss AS testsuite runs there is xml report produces for every testcase. If the same testcase is run twice without being renamed it overwrites the result from the previous run. This could lead to silent failures as if the first run fails and the second not, the final report will not show any problem. There appear to be some testcases doing so. We've noticed only org.jboss.test.jmx.test.RMIAdaptorAuthorizationUnitTestCase to fail the first time and not the second one, but we'd better avoid the possibility of this happening in the future. Affected seem to be many if not all current versions (4.0.4GA, 4.0.5GA, 4.0 branch, 4.2 branch, 5, etc.). See forum for a reference. There will always be the possibility different targets to include same testcases so we should probably rename tests run by all but tests-standard-unit target. -- 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

19 years, 3 months

4
11
0 / 0

[JBoss JIRA] Created: (JBAS-3901) Get the 4.2-compatibility tests passing

by Dimitris Andreadis (JIRA)

Get the 4.2-compatibility tests passing --------------------------------------- Key: JBAS-3901 URL: http://jira.jboss.com/jira/browse/JBAS-3901 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Dimitris Andreadis Fix For: JBossAS-4.2.0.CR1 -- 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

19 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-3855) JBosses org.jboss.invocation.InvocationStatistics are not serializable and therfore cant be queried by twiddle.sh

by Ramon Grunder (JIRA)

JBosses org.jboss.invocation.InvocationStatistics are not serializable and therfore cant be queried by twiddle.sh ----------------------------------------------------------------------------------------------------------------- Key: JBAS-3855 URL: http://jira.jboss.com/jira/browse/JBAS-3855 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: JBossAS-4.0.4.GA Reporter: Ramon Grunder Assigned To: Scott M Stark here is a sample call including the stack trace which describes the error: $ twiddle.sh -s jnp://localhost:1099 get jboss.j2ee:service=EJB,jndiName=ejb/Dummy InvokeStats 13:51:56,120 ERROR [Twiddle] Exec failed java.io.NotSerializableException: org.jboss.invocation.InvocationStatistics at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) ... -- 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

19 years, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (JBFORUMS-172) Change AdminView

by Ryszard Kozmik (JIRA)

Change AdminView ---------------- Key: JBFORUMS-172 URL: http://jira.jboss.com/jira/browse/JBFORUMS-172 Project: JBoss Forums Issue Type: Sub-task Components: Forum View Layer Reporter: Ryszard Kozmik Assigned To: Ryszard Kozmik Fix For: 1.0.1 RC Change L&F of AdminView to new one. -- 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-890) First call to MDB doesn't honour maxSize of StrictMaxPool

by Carlo de Wolf (JIRA)

First call to MDB doesn't honour maxSize of StrictMaxPool --------------------------------------------------------- Key: EJBTHREE-890 URL: http://jira.jboss.com/jira/browse/EJBTHREE-890 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC10 - FD Environment: mdb unit test Reporter: Carlo de Wolf Start up AS 4.2 clean and run mdb unit test. -- 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

19 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-4144) Remove remaining uses of the legacy ejbunit class (JUnitEJB)

by Fernando Nasser (JIRA)

Remove remaining uses of the legacy ejbunit class (JUnitEJB) ------------------------------------------------------------ Key: JBAS-4144 URL: http://jira.jboss.com/jira/browse/JBAS-4144 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.2.0.CR1 Reporter: Fernando Nasser Not all uses of the legacy ejbunit class have been removed. They should be. "Ideally this should be replaced with the version that is in our testsuite under org.jboss.test.util.ejb.*. It was derived from this junitejb code and extended." -- Scott Once this is done, 'junitejb' can be removed from JBoss AS thirdpart. -- 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

19 years, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JBPM-856) Expose management info via JMX

by Ronald van Kuijk (JIRA)

Expose management info via JMX ------------------------------ Key: JBPM-856 URL: http://jira.jboss.com/jira/browse/JBPM-856 Project: JBoss jBPM Issue Type: Feature Request Affects Versions: jBPM jPDL 3.2 Environment: N/A Reporter: Ronald van Kuijk Assigned To: Tom Baeyens Priority: Minor Fix For: jBPM 4.0 Some management info should/could be exposed via JMX. What has to be defined. -- 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

19 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-854) Condition in transition not retrieved from database JBPM_TRANSITIONS#DECISION_

by Arjan van Bentem (JIRA)

Condition in transition not retrieved from database JBPM_TRANSITIONS#DECISION_ ------------------------------------------------------------------------------ Key: JBPM-854 URL: http://jira.jboss.com/jira/browse/JBPM-854 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2 beta 2 Environment: All Reporter: Arjan van Bentem Assigned To: Tom Baeyens Though table JBPM_DECISIONCONDITION is replaced by column DECISION_ in table JBPM_TRANSITIONS, the Java code will still query that old table to load processes that were deployed using a previous version. For an empty query result Hibernate will return an empty List (at least for the Hypersonic database), while the code only checks for the List to be null. This fails, and results in conditions not being taken from JBPM_TRANSITIONS. Fix: replace line 105 of Decision.java (version 1.3) http://fisheye.jboss.com/browse/JBPM/jbpm.3/jpdl/jar/src/main/java/org/jb... 48 List decisionConditions = null; : 105 } else if (decisionConditions!=null) { 106 // backwards compatible mode based on separate DecisionCondition with 105 } else if (decisionConditions!=null && !decisionConditions.isEmpty()) { To test one could replace org.jbpm.graph.node.JpdlDbTest#testDecision() to use correct EL expression, and then signal the process to invoke the troublesome code: http://fisheye.jboss.com/browse/JBPM/jbpm.3/jpdl/jar/src/test/java/org/jb... public void testDecision(){ ProcessDefinition processDefinition = ProcessDefinition.parseXmlString( "<process-definition>" + " <start-state>" + " <transition to='d' />" + " </start-state>" + " <decision name='d'>" + " <transition name='one' to='a'>" + " <condition>#{a == 1}</condition>" + " </transition>" + " <transition name='two' to='b'>" + " <condition>#{a == 2}</condition>" + " </transition>" + " <transition name='three' to='c'>" + " <condition>#{a == 3}</condition>" + " </transition>" + " </decision>" + " <state name='a' />" + " <state name='b' />" + " <state name='c' />" + "</process-definition>"); processDefinition = saveAndReload(processDefinition); Decision decision = (Decision) processDefinition.getNode("d"); assertEquals("#{a == 1}", decision.getLeavingTransition("one").getCondition()); assertEquals("#{a == 2}", decision.getLeavingTransition("two").getCondition()); assertEquals("#{a == 3}", decision.getLeavingTransition("three").getCondition()); // Assure org.jbpm.graph.node.Decision#execute gets the conditions from // table JBPM_TRANSITIONS rather than the obsolete JBPM_DECISIONCONDITION: ProcessInstance processInstance = new ProcessInstance(processDefinition); processInstance.getContextInstance().setVariable("a", new Integer(2)); processInstance.signal(); assertEquals(processDefinition.getNode("b"), processInstance.getRootToken().getNode()); } -- 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

19 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-853) Attribute 'expression' not taken from Condition element

by Arjan van Bentem (JIRA)

Attribute 'expression' not taken from Condition element ------------------------------------------------------- Key: JBPM-853 URL: http://jira.jboss.com/jira/browse/JBPM-853 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2 beta 2 Environment: All Reporter: Arjan van Bentem Assigned To: Tom Baeyens The <condition> element allows for either specifying an attribute 'expression', or for giving the expression as the text of the element itself. So, both <condition>#{true}</condition> and <condition expression="#{true}"/> should work. However, the latter expression is ignored (and does not get stored in the database but results in a zero-length (non-null) value in column DECISION_ in JBPM_TRANSITIONS instead). This is caused by org.dom4j.Element#getTextTrim() returning en empty String rather than null. Fix: replace line 745 of JpdlXmlReader (version 1.7) http://fisheye.jboss.com/browse/JBPM/jbpm.3/jpdl/jar/src/main/java/org/jb... 739 String condition = transitionElement.attributeValue("condition"); 740 if (condition==null) { 741 Element conditionElement = transitionElement.element("condition"); 742 if (conditionElement!=null) { 743 condition = conditionElement.getTextTrim(); 744 // for backwards compatibility 745 if (condition==null) { 746 condition = conditionElement.attributeValue("expression"); 747 } 748 } 749 } with 745 if (condition==null || condition.length()==0) { In the DecisionConditionsTest Unit test one could change one (and ONLY one) of the conditions to use the attribute rather than the element text. Like on line 42 of DecisionConditionsTest (version 1.1) replace http://fisheye.jboss.com/browse/JBPM/jbpm.3/jpdl/jar/src/test/java/org/jb... 41 " <transition name='lead' to='put it in the lead db'>" + 42 " <condition>#{budget > 100}</condition>" + 43 " </transition>" + with 42 " <condition expression='#{budget > 100}'/>" + Thanks to cdart_rrr for pointing this out in the forums. -- 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

19 years, 3 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

jboss-jira February 2007