February 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-677) Setup integration testing

by Geoffrey De Smet (JIRA)

Setup integration testing ------------------------- Key: JBRULES-677 URL: http://jira.jboss.com/jira/browse/JBRULES-677 Project: JBoss Rules Issue Type: Task Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Minor based on solver configs -- 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

12 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1103) Tabu asperation based on stepscore

by Geoffrey De Smet (JIRA)

Tabu asperation based on stepscore ---------------------------------- Key: JBRULES-1103 URL: http://jira.jboss.com/jira/browse/JBRULES-1103 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Fix For: FUTURE Move tabu and property tabu could use "aspiration" Basically even if it's tabu, a move is accepted if the stepscore improves. For solution tabu this is pointless. Aspiration should occur on stepScore and NOT on decisionScore -- 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

12 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-153) EJB timer clustering and failover support

by Galder Zamarreno (JIRA)

EJB timer clustering and failover support ----------------------------------------- Key: JBCLUSTER-153 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-153 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Galder Zamarreno Assigned To: Brian Stansberry Support for clustered EJB timer service providing failover -- 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

12 years, 9 months

6
7
0 / 0

[JBoss JIRA] Created: (JBRULES-1469) Add DecisionTable example for the TroubleTicket example

by Mark Proctor (JIRA)

Add DecisionTable example for the TroubleTicket example ------------------------------------------------------- Key: JBRULES-1469 URL: http://jira.jboss.com/jira/browse/JBRULES-1469 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 5.0.0-M1 -- 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

12 years, 9 months

5
19
0 / 0

[JBoss JIRA] Created: (JBRULES-681) Multi-threaded local search solving

by Geoffrey De Smet (JIRA)

Multi-threaded local search solving ----------------------------------- Key: JBRULES-681 URL: http://jira.jboss.com/jira/browse/JBRULES-681 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Optional Use Future's to spread all possible moves in each step over a number of threads. This number of threads is equal to the number of cpu's by default, as no IO is done during solving. Problems: - each thread will needs it own WorkingMemory and during a step, each working memory will need to be updated - a bunch of classes will need to be thread safe, or at least visibility save, such as bestsolutionrecaller. - Barriers will be needed to collect the result of each step - decks might be a great way to spread out the load -- 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

12 years, 9 months

1
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-880) Hard-coded localhost in ejb3 test suite

by Aleksandar Kostadinov (JIRA)

Hard-coded localhost in ejb3 test suite --------------------------------------- Key: EJBTHREE-880 URL: http://jira.jboss.com/jira/browse/EJBTHREE-880 Project: EJB 3.0 Issue Type: Bug Reporter: Aleksandar Kostadinov When the ejb3 testsuite is run with "-Dnode0=IP1 -Dnode1=IP2" and IP1!=localhost there are some tests failing with "Retries exceeded, couldn't reconnect to 127.0.0.1:####". I see this for 4_0 and 4_2 jboss branches, but guess it's the same with head. One of the testcases is IiopRemoteUnitTestCase. I've checked ejb3/src/test/org/jboss/ejb3/test/iiop/unit/IiopRemoteUnitTestCase.java and there is 'props.put("java.naming.provider.url", "corbaloc::localhost:3528/NameService");'. Instead of localhost there should be used the node0 property. I guess the others have the same problem. -- 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

12 years, 9 months

6
16
0 / 0

[JBoss JIRA] Created: (JASSIST-44) Maven profiles for tools.jar should take account of Mac OS

by Martin Burger (JIRA)

Maven profiles for tools.jar should take account of Mac OS ---------------------------------------------------------- Key: JASSIST-44 URL: http://jira.jboss.com/jira/browse/JASSIST-44 Project: Javassist Issue Type: Bug Environment: Maven version: 2.0.8 Java version: 1.5.0_13 OS name: "mac os x" version: "10.4.11" arch: "i386" Family: "unix" Reporter: Martin Burger Assigned To: Shigeru Chiba The pom.xml uses different profiles to add the tools.jar to the dependencies. However, it is already included in the runtime for Mac OS X and some free JDKs and does not exist as a separate file 'tools.jar'. See: http://maven.apache.org/general.html#tools-jar-dependency As soon as http://jira.codehaus.org/browse/MNG-3106 gets fixed, activation should look like the following example: <activation> <jdk>1.6</jdk> <property> <name>java.vendor</name> <value>Sun Microsystems Inc.</value> </property> </activation> In the meantime <profiles> <profile> <id>tools.jar</id> <activation> <property> <name>java.vendor</name> <value>Sun Microsystems Inc.</value> </property> </activation> <dependencies> <dependency> <groupId>com.sun</groupId> <artifactId>tools</artifactId> <version>1.6</version> <scope>system</scope> <optional>true</optional> <systemPath>${java.home}/../lib/tools.jar</systemPath> </dependency> </dependencies> </profile> </profiles> should do the job. It could be a permanent solution because the different profiles differ only in the version element. -- 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

12 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-4526) JBossMQ UIL2 Read/Write Tasks should not be doing initialization

by Adrian Brock (JIRA)

JBossMQ UIL2 Read/Write Tasks should not be doing initialization ---------------------------------------------------------------- Key: JBAS-4526 URL: http://jira.jboss.com/jira/browse/JBAS-4526 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.2.1.GA Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.GA, JBossAS-4.2.2.CR1 The JBossMQ UIL2 Read/Write tasks both do their stream initialization when each thread starts. This code needs changing such that the streams are allocated before started the threads. Only if all resources can be succesfully allocated should we start the threads. -- 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

12 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JBRULES-443) Release drools binaries with debug information

by Juergen none (JIRA)

Release drools binaries with debug information ---------------------------------------------- Key: JBRULES-443 URL: http://jira.jboss.com/jira/browse/JBRULES-443 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Reporter: Juergen none Assigned To: Mark Proctor Priority: Trivial Would it be possible to supply a debug-build of the binaries in addition to the existing downloads (where at least the drools jar files are without debug-info)? -- 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

13 years

3
4
0 / 0

[JBoss JIRA] Created: (JBREM-552) cannot init cause of ClassCastException

by John Mazzitelli (JIRA)

cannot init cause of ClassCastException --------------------------------------- Key: JBREM-552 URL: http://jira.jboss.com/jira/browse/JBREM-552 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.Beta2 (Boon) Reporter: John Mazzitelli Assigned To: Tom Elrod Priority: Minor Fix For: 2.0.0.CR1 (Boon) I'm in a catch clause within InvokerRegistry and I'm getting a weird exception thrown: java.lang.IllegalStateException: Can't overwrite cause at java.lang.Throwable.initCause(Throwable.java:320) at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:447) at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324) at org.jboss.remoting.Client.connect(Client.java:385) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.getRemotingClient(JBossRemotingRemoteCommunicator.java:470) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.send(JBossRemotingRemoteCommunicator.java:430) at org.jboss.on.communications.command.client.AbstractCommandClient.invoke(AbstractCommandClient.java:167) at org.jboss.on.communications.command.client.ClientCommandSender.send(ClientCommandSender.java:820) at org.jboss.on.communications.command.client.ServerPollingThread.run(ServerPollingThread.java:102) Look at line 447 and you'll see it is trying to init the cause of a ClassNotFoundException. Running in a debugger, the newly constructed exception created on 446 has a null cause. Looking then at Throwable.initCause and you'll see a null cause causes this IllegalStateException to be thrown. The cause needs to be "this", not null (I don't know why, seems like it should also look for null, but whatever - that's the way the JDK is written). The fix is simple - use the constructor that takes a throwable as its second parameter. Not sure why initCause it being used, as opposed to this constructor. e.g.: new ClassNotFoundException("Can not invoke loadClientInvokerClass method on " + transportFactoryClass, e); (notice the ", e" parameter). There are three other instances where initCause is called on ClassNotFoundException that also need to be fixed. See the other catch clauses in here. -- 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

13 years

5
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2008