July 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2020) red-on-black code snippets in PDF

by Wolfgang Laun (JIRA)

red-on-black code snippets in PDF --------------------------------- Key: JBRULES-2020 URL: https://jira.jboss.org/jira/browse/JBRULES-2020 Project: JBoss Drools Issue Type: Quality Risk Security Level: Public (Everyone can see) Components: drools-docs Affects Versions: 5.0.0.CR1 Environment: n/a Reporter: Wolfgang Laun Assignee: Mark Proctor Priority: Critical Fix For: 5.0.0.CR1 In the PDF version of the docs, code snippets appear in red print on black backround. Headache tablets cost money. -- 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

12 years, 6 months

6
26
0 / 0

[JBoss JIRA] Created: (JBRULES-1809) Set package level attributes as defaults for rule attributes

by Greg Barton (JIRA)

Set package level attributes as defaults for rule attributes ------------------------------------------------------------ Key: JBRULES-1809 URL: https://jira.jboss.org/jira/browse/JBRULES-1809 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 5.0.0.M2 Reporter: Greg Barton Assignee: Mark Proctor Priority: Optional Fix For: 5.0.0.M3 It would be nice if default values for rule attributes could be set at the package level. -- 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

12 years, 6 months

7
20
0 / 0

[JBoss JIRA] Created: (JBRULES-2079) ruleBase.addPackage(packageBuilder.getPackage()); should fail-fast with a clear error message if the packageBuilder has any errors

by Geoffrey De Smet (JIRA)

ruleBase.addPackage(packageBuilder.getPackage()); should fail-fast with a clear error message if the packageBuilder has any errors ---------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-2079 URL: https://jira.jboss.org/jira/browse/JBRULES-2079 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.0.CR1 Reporter: Geoffrey De Smet Assignee: Mark Proctor Priority: Minor Fix For: 5.1.0.M1 After you 've build your package with packageBuilder, you've either called the hasErrors() method and done something about it or you didn't check the hasErrors() method because you didn't know (or want to know) it existed and you expect it to throw an exception because hasErrors() returns true. The principle of least surpise. You don't expect that it continues like everything is cool (while it's not) and crashes the moment you fire your first rules. The exception should be a runtime exception and the message should at least mention the first of the errors. The exception should probably contain a list of all errors of course too as a property. See InvalidStateException in hibernate-validator. -- 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

12 years, 6 months

6
16
0 / 0

[JBoss JIRA] Created: (JBRULES-2125) Drools core multithreading issue

by Andrey Nechaev (JIRA)

Drools core multithreading issue -------------------------------- Key: JBRULES-2125 URL: https://jira.jboss.org/jira/browse/JBRULES-2125 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.1.FINAL Environment: Java HotSpot v 1.6.0_06, WinXP SP3 Reporter: Andrey Nechaev Assignee: Mark Proctor Attachments: Main.java Attachement below is the code showing the problems. The program hangs and nothing is displayed in the Console. If I put lines 10-11 before the line 6, I get a NullPointerException: Exception in thread "main" java.lang.NullPointerException at org.drools.reteoo.ObjectSource.addObjectSink(ObjectSource.java:124) ... But, if I comment out the lines 2&3, everything works ok. -- 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

12 years, 6 months

9
20
0 / 0

[JBoss JIRA] Created: (JBRULES-2179) better integration of ruleflow and AgendaFilter

by Michal Bali (JIRA)

better integration of ruleflow and AgendaFilter ----------------------------------------------- Key: JBRULES-2179 URL: https://jira.jboss.org/jira/browse/JBRULES-2179 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.0.1.FINAL Reporter: Michal Bali Assignee: Mark Proctor Fix For: 5.1.0.M1 Attachments: agendaFilterWithRuleflow.zip Hi, I am creating this issue so that it won't be lost. See this post for more information: http://lists.jboss.org/pipermail/rules-users/2009-May/009110.html My original email with one reply message is pasted below: -------------------------------------------------------------- If a rule is not allowed to fire by an AgendaFilter the whole ruleflow stops. I've created a small test case (attached). It contains: - one DRL file with one dummy rule that is in some ruleflow-group. - one RF file with three nodes ('start', 'ruleflow group' and 'end') - a program that starts the process, and calls fireAllRules with custom agenda filter. Once the program is executed the ruleflow will stop inside the ruleflow-group. If I remove the agenda filter it works as expected (the ruleflow finishes). Tested with Drools 5.0.1. Best regards, Michal ---------------------------------------- Final reply from Mark: It seems like a reasonable request, that if all the rules have been cancelled, fired or filtered that the ruleflow-group should be de-activated so the flow can continue. We'll look into it for 5.1. --------------------------------------- Thanking you in advance, Michal -- 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

12 years, 6 months

7
15
0 / 0

[JBoss JIRA] Created: (JBRULES-2126) Simulation and testing framwork

by Mark Proctor (JIRA)

Simulation and testing framwork ------------------------------- Key: JBRULES-2126 URL: https://jira.jboss.org/jira/browse/JBRULES-2126 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-compiler, drools-core Reporter: Mark Proctor Assignee: Mark Proctor Fix For: 5.1.0.M1 Api for full simulation and testing. -- 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

12 years, 6 months

6
13
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1287) SOA-P test suite failures

by Aleksandar Kostadinov (JIRA)

SOA-P test suite failures ------------------------- Key: JBMESSAGING-1287 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1287 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP3_CP01 Reporter: Aleksandar Kostadinov Assigned To: Tim Fox I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml. * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73... 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. -- 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, 6 months

6
30
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1491) add support for Ingres RDBMS to JBoss Messaging

by murray armfield (JIRA)

add support for Ingres RDBMS to JBoss Messaging ----------------------------------------------- Key: JBMESSAGING-1491 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1491 Project: JBoss Messaging Issue Type: Patch Affects Versions: 1.4.0.SP3.CP06, EAP/SOA-P Integration, 2.0.0 Beta, 1.4.3.GA, 2.0.0.GA, Unscheduled, AS 5.0 Integration Environment: N/A Reporter: murray armfield Assignee: Tim Fox Priority: Minor I've been working on JBoss support on Ingres. I've written an ingres-persistence-service.xml file for use with Ingres for inclusion as part of JBoss Messaging -- 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

12 years, 6 months

6
44
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1490) BridgeService should be JAAS aware

by Nicholas Sayer (JIRA)

BridgeService should be JAAS aware ---------------------------------- Key: JBMESSAGING-1490 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1490 Project: JBoss Messaging Issue Type: Feature Request Affects Versions: 1.4.2.GA Environment: n/a Reporter: Nicholas Sayer Assignee: Tim Fox Priority: Optional org.jboss.jms.server.bridge.BridgeService currently requires a username and password for the source and destination. It would be better if it could be configured with a JAAS login context name. This would allow username and password information to be set in, for example, a SecureIdentityLoginModule. For example: <application-policy name = "JmsBridgeRealm"> <authentication> <login-module code = "org.jboss.resource.security.SecureIdentityLoginModule" flag = "required"> <module-option name = "principal">${bridge.user}</module-option> <module-option name = "userName">${bridge.user}</module-option> <module-option name = "password">${bridge.encryptedPassword}</module-option> <module-option name = "ignoreMissigingMCF">true</module-option>  <module-option name = "managedConnectionFactoryName">jboss.nonexistent:service=NonExistent,name=NonExistent</module-option> </login-module> </authentication> </application-policy> There is undoubtedly a better way to accomplish this (probably to pass the JAAS context directly into the JMS connection factory used to vend connections for the bridge), but we're using this as a crude hack for now: import java.util.Set; import javax.security.auth.Subject; import javax.security.auth.login.LoginContext; import javax.security.auth.login.LoginException; import javax.security.auth.login.CredentialNotFoundException; import javax.resource.spi.security.PasswordCredential; import org.jboss.jms.server.bridge.BridgeService; public class JAASAwareBridgeService extends BridgeService { private String sourceContext, targetContext; public void setSourceLoginContext(String ctxName) { this.sourceContext = ctxName; } public String getSourceLoginContext() { return this.sourceContext; } public void setTargetLoginContext(String ctxName) { this.targetContext = ctxName; } public String getTargetLoginContext() { return this.targetContext; } public void start() throws Exception { setupSourceCredentials(); setupTargetCredentials(); super.start(); } private void setupSourceCredentials() throws LoginException { PasswordCredential pc = getPasswordCredential(this.sourceContext); super.setSourceUsername(pc.getUserName()); super.setSourcePassword(new String(pc.getPassword())); } private void setupTargetCredentials() throws LoginException { PasswordCredential pc = getPasswordCredential(this.targetContext); super.setTargetUsername(pc.getUserName()); super.setTargetPassword(new String(pc.getPassword())); } private static PasswordCredential getPasswordCredential(String contextName) throws LoginException { LoginContext ctx = new LoginContext(contextName); ctx.login(); Subject s = ctx.getSubject(); Set<PasswordCredential> creds = s.getPrivateCredentials(PasswordCredential.class); if (creds.isEmpty()) throw new CredentialNotFoundException("Login context '" + contextName + "' subject has no PasswordCredential"); return creds.iterator().next(); // get 1st } } -- 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

12 years, 6 months

4
21
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1478) inconsistent test suite performance

by Aleksandar Kostadinov (JIRA)

inconsistent test suite performance ----------------------------------- Key: JBMESSAGING-1478 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1478 Project: JBoss Messaging Issue Type: Bug Components: Tests and Performance Affects Versions: 1.4.0.SP3.CP04 Reporter: Aleksandar Kostadinov Assignee: Tim Fox I see inconsistent performance running the JBM test suite. Here I have 2 builds on the same physical machine (windows), using local disk storage so environment should be pretty stable. The mysql database is shared but I doubt it is the culprit. I run the test suite with the following options: property( name: "functional.tests.database", value: dbname ) property( name: "stress.tests.database", value: dbname ) property( name: "clustering.tests.database", value: dbname ) property( name: "test.target", value: "report" ) property( name: "test.bind.address", value: properties["env.MYTESTIP_1"] ) property( name: "jboss.messaging.groupname", value: properties["env.BUILD_TAG"]) property( name: "jboss.messaging.datachanneludpaddress", value: properties["env.MCAST_ADDR"] ) property( name: "jboss.messaging.controlchanneludpaddress", value: properties["env.MCAST_ADDR"] ) Are there any other options I can add to increase isolation from other processes in the same LAN? Would you be able to look at these 2 builds and based on the logs, say why is the first one taking longer and eventually timeout? http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/163/ http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/164/ -- 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

12 years, 6 months

4
24
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2009