July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBESB-71) Move existing tests to JUnit

by Arvinder Singh (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-71?page=comments#action_12339464 ] Arvinder Singh commented on JBESB-71: ------------------------------------- Mark, the current tests consist of the following files: -rw-rw-r-- 1 raj raj 1954 Jun 30 20:41 Controller.java -rw-rw-r-- 1 raj raj 2598 Jun 30 20:41 DrainQueuesAndTopics.java -rw-rw-r-- 1 raj raj 7654 Jun 30 20:15 TestNotification.java -rw-rw-r-- 1 raj raj 3034 Jun 30 20:15 TestObjStore.java -rw-rw-r-- 1 raj raj 2005 Jun 27 13:34 TestParamsRepository.java -rw-rw-r-- 1 raj raj 3332 Jun 27 13:57 TestPersonAddrPhone.java I started working on TestPersonAddrPhone.java and converted it into AddressUnitTest PersonUnitTest and together with a small infrastructure org have added them to common/tests ... its builds/compiles/tests fine. The rest of the tests I feel can be ignored because 1) lets get the infrastructure for testing in place per module (common is done) 2) they don't use junit 3) some are based on functional type tests which require a running server I propose: 1) Leave them for now. 2) Let me add the infrastructure for the rest of the modules 3) check the code and merge with head then we can move on from this task and say that any new code must have tests. I'm open to suggestions in continueing this. > Move existing tests to JUnit > ---------------------------- > > Key: JBESB-71 > URL: http://jira.jboss.com/jira/browse/JBESB-71 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: ESB Core, Testing > Affects Versions: 4.0 Alpha 1 > Reporter: Mark Little > Assigned To: Arvinder Singh > Fix For: 4.0 Beta 1 > > > JUnit is the best way forward. We may eventually use the Distributed Test Framework that JBossTS uses, but even that can run JUnit tests. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBRULES-318) eval() not re-evaluated when objects were modified

by Edson Tirelli (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-318?page=all ] Edson Tirelli resolved JBRULES-318. ----------------------------------- Fix Version/s: 3.0.3 (was: 3.0.2) Resolution: Done In addition to fix JoinNode.modifyTuple() as I did previously, a fix to JoinNode.modifyObject() also had to be done. The problem is that when a node is removed from a linked list, its "previous" and "next" references are nulled out and the modifyObject() method was not taking that in account. Let me know if you find any other problem. Commited in revision #5052. Edson > eval() not re-evaluated when objects were modified > -------------------------------------------------- > > Key: JBRULES-318 > URL: http://jira.jboss.com/jira/browse/JBRULES-318 > Project: JBoss Rules > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.0.1 > Environment: JBossRules 3.0.1 > Eclipse 3.2 rc7 > JDK 5 > Reporter: Jean-Pierre GRILLON > Assigned To: Edson Tirelli > Fix For: 3.0.3 > > Attachments: Drools-eval.zip > > > I face a problem (bug?): I have a condition using ?eval? which doesn?t seem to be reevaluated when objects are modified. > The class NumberTest wraps a number (field nb) and the index (field index). > The rule gets 2 NumberTest, the first number is greater than the second one ; and the eval condition should test that the first index is less than the second. But the rule is fired even if this condition is not fulfilled (see the check function). -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBRULES-318) eval() not re-evaluated when objects were modified

by Edson Tirelli (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-318?page=all ] Edson Tirelli reopened JBRULES-318: ----------------------------------- Hi, Thanks for having fixed this. Unfortunately, I think that I am facing a regression when using the same example (just use the conditions under comment "Works great"): rule "Order" salience 200 when #Works great n1 : NumberTest($nb1 : nb, $index1 : index); n2 : NumberTest($nb2 : nb -> ($nb2.compareTo($nb1) < 0), index > $index1); then System.out.println("Swapping " + n1 + " with " + n2); check(n1, n2); swap(n1, n2); modify(n1); modify(n2); end I got an error in the middle of the test (using 3.0.2), which wasn't the case with 3.0.1. Did I made a mistake writing my rules, or is it a regression? Swapping N[4] index=1 with N[3] index=2 Swapping N[3] index=1 with N[2] index=3 Swapping N[2] index=1 with N[1] index=4 Swapping N[1] index=1 with N[0] index=5 Swapping N[4] index=2 with N[1] index=5 Swapping N[2] index=4 with N[1] index=2 Shouldn't come here... false Swapping N[3] index=3 with N[1] index=4 Swapping N[2] index=2 with N[1] index=3 Number is N[0] index=1 Number is N[1] index=2 Number is N[2] index=3 Number is N[3] index=4 Number is N[4] index=5 Thanks, Jean-Pierre Grillon > eval() not re-evaluated when objects were modified > -------------------------------------------------- > > Key: JBRULES-318 > URL: http://jira.jboss.com/jira/browse/JBRULES-318 > Project: JBoss Rules > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.0.1 > Environment: JBossRules 3.0.1 > Eclipse 3.2 rc7 > JDK 5 > Reporter: Jean-Pierre GRILLON > Assigned To: Edson Tirelli > Fix For: 3.0.2 > > Attachments: Drools-eval.zip > > > I face a problem (bug?): I have a condition using ?eval? which doesn?t seem to be reevaluated when objects are modified. > The class NumberTest wraps a number (field nb) and the index (field index). > The rule gets 2 NumberTest, the first number is greater than the second one ; and the eval condition should test that the first index is less than the second. But the rule is fired even if this condition is not fulfilled (see the check function). -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-693) Change ant build scripts in starter kit to make the JBoss HTTP port number as a property instead of hardcoded.

by Brad O'Hearne (JIRA)

Change ant build scripts in starter kit to make the JBoss HTTP port number as a property instead of hardcoded. --------------------------------------------------------------------------------------------------------------- Key: JBPM-693 URL: http://jira.jboss.com/jira/browse/JBPM-693 Project: JBoss jBPM Issue Type: Feature Request Affects Versions: jBPM 3.1.1 Environment: JBoss 4.0.4 Reporter: Brad O'Hearne Assigned To: Tom Baeyens Priority: Minor This is a fairly trivial request, but make the port number of the JBoss installation a configuration property, rather than hardcoding it in the build.deploy.xml file. Its kind of a nuisance to have to change these manually on all the deploy targets. Thx. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-3281) Implementation of javax.management.timer.Timer does not match javadoc

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3281?page=all ] Dimitris Andreadis reassigned JBAS-3281: ---------------------------------------- Assignee: Dimitris Andreadis (was: Darran Lofthouse) > Implementation of javax.management.timer.Timer does not match javadoc > --------------------------------------------------------------------- > > Key: JBAS-3281 > URL: http://jira.jboss.com/jira/browse/JBAS-3281 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMX > Affects Versions: JBossAS-4.0.4.GA > Environment: Java 1.4 (For Java 5.0 we use the implementation supplied with the JRE) > Reporter: Darran Lofthouse > Assigned To: Dimitris Andreadis > Priority: Critical > Fix For: JBossAS-4.0.5.CR1 > > > The implementation of javax.management.timer.Timer does not match the javadoc: - > http://java.sun.com/j2ee/1.4/docs/api/javax/management/timer/Timer.html > By default the timer should be using fixed-delay execution, our implementation is defaulting to fixed-rate execution. > In addition to this to use fixed-rate execution you should use the method addNotification(String, String, Object, Date, long, long, boolean), however we have not implemented this method and we just throw a RuntimeException if it is invoked. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-945) Add section to install chapter on configuring build for clustered

by Roy Russo (JIRA)

Add section to install chapter on configuring build for clustered ----------------------------------------------------------------- Key: JBPORTAL-945 URL: http://jira.jboss.com/jira/browse/JBPORTAL-945 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 2.4 Final Reporter: Roy Russo Assigned To: Roy Russo -- 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, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-370) generate counter ids for working memories

by Mark Proctor (JIRA)

generate counter ids for working memories ----------------------------------------- Key: JBRULES-370 URL: http://jira.jboss.com/jira/browse/JBRULES-370 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Leaps, Reteoo Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 Each time a RuleBase generates a new WorkingMemory it should get an ID from a counter. -- 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, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-369) generate RuleBases with a UUID id

by Mark Proctor (JIRA)

generate RuleBases with a UUID id --------------------------------- Key: JBRULES-369 URL: http://jira.jboss.com/jira/browse/JBRULES-369 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Leaps, Reteoo Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 All RuleBases should have a unique id generated from a UUID. -- 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, 6 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBSEAM-263) Constrain object graph that is returned from remoting requests

by Gavin King (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-263?page=all ] Gavin King closed JBSEAM-263. ----------------------------- Fix Version/s: 1.1 Resolution: Done Done by shane > Constrain object graph that is returned from remoting requests > -------------------------------------------------------------- > > Key: JBSEAM-263 > URL: http://jira.jboss.com/jira/browse/JBSEAM-263 > Project: JBoss Seam > Issue Type: Feature Request > Components: Remoting > Affects Versions: 1.0 > Reporter: Shane Bryzak > Priority: Minor > Fix For: 1.1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Introduce a method for constraining the object graph that is returned from a remote request. Currently the remoting API recursively walks the object graph of the return value and packages up everything that is referenced either directly or indirectly by the result. This is potentially a bad thing as it is quite possible to unintentionally return a mountain of unwanted data. > This issue can be addressed by annotating the @WebRemote methods with an additional annotation, @Constrain and including a list of "trim-points", paths within the object graph that should be excluded from the result. > For example, a remotable method returns a Customer entity, which contains references to a Rep/Staff entity: > Customer > id > firstName > lastName > rep > -> Staff > firstName > lastName > userName > password > In this example it is undesirable to return the Staff instance, as it contains sensitive information (their password). To prevent this, the method would be annotated like so: > @WebMethod > @Constrain("rep") > public Customer getCustomer(int customerId) { > ... > } > The @Constrain annotation would accept a String array parameter, which allows multiple trim-points to be specified. Dot notation would be used to exclude fields further down the object tree, e.g. @Constrain({"rep.username", "rep.password"}) would include the Customer's rep field, but exclude the rep's username and password field from the result. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-944) Update CMS force dialect chapter

by Roy Russo (JIRA)

Update CMS force dialect chapter -------------------------------- Key: JBPORTAL-944 URL: http://jira.jboss.com/jira/browse/JBPORTAL-944 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 2.4 Final Reporter: Roy Russo Assigned To: Roy Russo -- 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, 6 months

1
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 July 2006