December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1286) Incorrect information in section 2.5.7.3. Agenda Filters

by Sergey Manukyan (JIRA)

Incorrect information in section 2.5.7.3. Agenda Filters -------------------------------------------------------- Key: JBRULES-1286 URL: http://jira.jboss.com/jira/browse/JBRULES-1286 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Manual Affects Versions: 4.0.2 Reporter: Sergey Manukyan Assigned To: Mark Proctor CORRECTION #1 Manual states : To use a filter specify it while calling FireAllRules. The following example will filter out all rules ending with the text "Test": workingMemory.fireAllRules( new RuleNameEndsWithAgendaFilter( "Test" ) ); Should be: To use a filter specify it while calling FireAllRules. The following example will only allow activation of rules ending with the text "Test". All others will be filtered out.: workingMemory.fireAllRules( new RuleNameEndsWithAgendaFilter( "Test" ) ); CORRECTION #2 Manual states : RuleNameEndWithAgendaFilter Should be : RuleNameEndsWithAgendaFilter -- 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

18 years, 4 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1099) Split documentation in "reference manual" and "user guide"

by Gernot Starke (JIRA)

Split documentation in "reference manual" and "user guide" ---------------------------------------------------------- Key: JBRULES-1099 URL: http://jira.jboss.com/jira/browse/JBRULES-1099 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Documentation Environment: all Reporter: Gernot Starke Assigned To: Mark Proctor Priority: Minor imho documentation for a product like JBoss Drools should consist of several DISTINCT parts, at least reference manual and user guide. That'd make it two different manuals - but especially the language documentation should get a more promininent location... (reference manual) -- 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

18 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1212) Improve performance on JBMExecutor

by Clebert Suconic (JIRA)

Improve performance on JBMExecutor ---------------------------------- Key: JBMESSAGING-1212 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1212 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.4.0.SP3 Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: Stable branch Because of JBMESSAGING-1200 we had to play with classLoader on the executor, and because of that we had to play with Security checks, for classLoader operations. It would be better to not do it on the executor... So I should investigate about setting the classLoader only on createProducer, createConsumer and its respective close methods. I will need to validate this against JCA and the TCK that was failing because of JBMESSAGING-1200 before. -- 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

18 years, 4 months

2
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1072) Ejb3TxPolicy does not rollback the transaction in case of an error

by Olaf Fricke (JIRA)

Ejb3TxPolicy does not rollback the transaction in case of an error ------------------------------------------------------------------ Key: EJBTHREE-1072 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1072 Project: EJB 3.0 Issue Type: Bug Affects Versions: HEAD Reporter: Olaf Fricke Priority: Blocker The class Ejb3TxPolicy is used to rollback the transaction in the case of exceptions. According to the ejb 3.0 spec, the transaction is rolled back in case of ApplicationException with rollback() evaluating to true, in case of RuntimeExceptions or in case of EjbException. All other exception will not lead to a rollback on the current transaction. Unfortunately, the same is true in case of errors. If, for example, an AssertionError (or a ClassDefNotFoundError etc.) occurs, the current transaction will be committed and not rolled back. This behaviour is wrong with respect to the ejb 3.0 spec (see for example table 14 on page 360 of ejbcore.pdf) A possible solution would be to wrap the error into a new RuntimeException after handling ApplicationException (in both methods handleExceptionInOurTx and handleInCallerTx): <code> if (t instanceof Error) { t = new RuntimeException(t); } if (!(t instanceof RuntimeException || t instanceof RemoteException)) { throw t; } </code> The wrapping is necessary, because both the EJBException and the EJBTransactionRolledbackException can only handle exceptions, but not errors. -- 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

18 years, 4 months

3
4
0 / 0

[JBoss JIRA] Created: (JBRULES-1060) Unexpected exit with no stack trace or other information

by christopher barham (JIRA)

Unexpected exit with no stack trace or other information -------------------------------------------------------- Key: JBRULES-1060 URL: http://jira.jboss.com/jira/browse/JBRULES-1060 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.0.GA Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340, JBOSS Rules feature/plugin 4.0.0 Reporter: christopher barham Assigned To: Mark Proctor When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information. I pared down my code to a simple example that demonstrates this below. I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit. I am running this from Eclipse. Garbage.java (fact bean): package com.sample; public class Garbage { private char id; private int someNumber; public Garbage(char garbageId, int someNumber) { setSomeNumber(someNumber); setId(garbageId); } public char getId() { return id; } public int getSomeNumber() { return someNumber; } public void setId(char id) { this.id = id; } public void setSomeNumber(int someNumber) { this.someNumber = someNumber; } @Override public String toString() { StringBuilder sb = new StringBuilder(); sb.append("a Garbage { "); sb.append("someNumber= "); sb.append(getSomeNumber()); sb.append(", id= "); sb.append(getId()); sb.append(" }"); return sb.toString(); } } StrangeExit.Java (Rule Engine startup and fact insertion): package com.sample; import java.io.InputStreamReader; import java.io.Reader; import org.drools.RuleBase; import org.drools.RuleBaseFactory; import org.drools.WorkingMemory; import org.drools.compiler.PackageBuilder; import org.drools.event.DebugWorkingMemoryEventListener; import org.drools.rule.Package; public class StrangeExit { public static final void main(String[] args) { try { long startTime = System.currentTimeMillis(); System.out.println("Starting problem at " + new java.util.Date()); RuleBase ruleBase = readRule(); WorkingMemory workingMemory = ruleBase.newStatefulSession(); workingMemory.addEventListener(new DebugWorkingMemoryEventListener()); assertAllFacts(workingMemory); workingMemory.fireAllRules(); long stopTime = System.currentTimeMillis(); long runTime = stopTime - startTime; System.out.println("Run time (milliseconds): " + runTime); System.out.println("Finished problem at " + new java.util.Date()); } catch (Throwable t) { t.printStackTrace(); } } private static void assertAllFacts(WorkingMemory workingMemory) { for (int i = 1; i <= 3; i++) { for (int j = 1; j <= 475; j++) { Garbage gar = new Garbage((char)(i + 64), j); workingMemory.insert(gar); } } } private static RuleBase readRule() throws Exception { Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl")); PackageBuilder builder = new PackageBuilder(); builder.addPackageFromDrl(source); Package pkg = builder.getPackage(); RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage(pkg); return ruleBase; } } The Rule itself: package com.sample import com.sample.Garbage; rule "Weird exit with no stack trace error" when $garA : Garbage( ) $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber ) then System.out.println("Something is up"); end -- 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

18 years, 4 months

4
10
0 / 0

[JBoss JIRA] Created: (JBRULES-1386) OC4J Support

by Jason Lee (JIRA)

OC4J Support ------------ Key: JBRULES-1386 URL: http://jira.jboss.com/jira/browse/JBRULES-1386 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.1.0 Environment: OC4J 10.1.3.3 Reporter: Jason Lee Priority: Minor The current nightly build fails to deploy and/or run on OC4J 10.1.3.3. To fix this, I did the following: * Upgrade jboss-seam to 2.0.0 CVS (GA might work, but I added some logging to org.jboss.seam.init.Initialization to help track down deployment issues) * Upgrade jboss-el to 2.0.0.GA * Added Mojarra 1.2_07 jars * Added the following to web.xml: <context-param> <param-name> com.sun.faces.forceLoadConfiguration</param-name> <param-value>true</param-value> </context-param> -- 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

18 years, 4 months

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1338) DirectoryScanner should only take into account relevant files

by Jￃﾶrg Erdmenger (JIRA)

DirectoryScanner should only take into account relevant files ------------------------------------------------------------- Key: JBRULES-1338 URL: http://jira.jboss.com/jira/browse/JBRULES-1338 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Reporter: Jￃﾶrg Erdmenger Currently DirectoryScanner in its configure and loadPackageChanges methods takes into account all types of files and hands them to FileScanner. This causes issues when the directory specified is under source management control (at least if CVS or Subversion are used) as the .svn or similar files/dirs cause FileScanner to barf. Now I'm sure that for plenty of cases the dir passed to DirectoryScanner won't be SCM managed but I think there might also be lots of situations where it is. Considering that it would be such a trivial change to either: - only take into account .pkg and .drl files (or do we need .dsl, .rf as well) - or at least ignore dot files (and maybe directories in general?) I think it will be worth doing. -- 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

18 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1225) allow dump of generated .java files during rule compilation

by Godmar Back (JIRA)

allow dump of generated .java files during rule compilation ----------------------------------------------------------- Key: JBRULES-1225 URL: http://jira.jboss.com/jira/browse/JBRULES-1225 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0.1 Reporter: Godmar Back Assigned To: Mark Proctor Please add an option to dump the generated .java code. Otherwise, debugging compile errors is a night mare. Even when dialect "MVEL" isn't used, some expression seem to become MVEL expressions. In addition, it seems that bean-Syntax (as in x.prop) can be used in the conditions of a rule, but the consequence requires that you use x.getProp()). It's also not clear in which scope/package/class the generated code lives. -- 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

18 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1213) Client side connection exception is not thrown on the client side when the lease times out

by Jay Howell (JIRA)

Client side connection exception is not thrown on the client side when the lease times out ------------------------------------------------------------------------------------------ Key: JBMESSAGING-1213 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1213 Project: JBoss Messaging Issue Type: Bug Components: JMS Remoting Affects Versions: 1.4.0.SP3 Reporter: Jay Howell Assigned To: Tim Fox Clients that are connected that experience a lease timeout are not notified that they no longer have a connection on the server. The behavior is that clients think that they are alive, while they will no longer get any messages. Also something of note, the Server side pinger has been disabled for JBM. Note: this is an issue that can either be fixed on the remoting side or the JBM side. Discussing this with Clebert, it may be prudent to fix it on both sides. I've opened this jira to facilitate the communication about where the logic should go. Please refer to the linked Remoting Jira JBREM-888 that was opened for this same topic. -- 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

18 years, 4 months

3
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1121) Allow command line configuration of ServerPeerID

by Brian Stansberry (JIRA)

Allow command line configuration of ServerPeerID ------------------------------------------------ Key: JBMESSAGING-1121 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1121 Project: JBoss Messaging Issue Type: Feature Request Components: JMS Clustering Affects Versions: 1.4.0.GA Reporter: Brian Stansberry Assigned To: Tim Fox Fix For: AS 5.0 Integration, EAP 4.3 Integration The ServerPeer ServerPeerID is currently hard coded at 0 in messaging-service.xml. If you want to set up a cluster, the only way to get it to work is to manually change the value in that file in each node. This needs to be configurable from the command line; i.e via system property substitution. Need to be sure any changes made in the messaging-service.xml are also reflected in docs/examples/binding-manager/sample-bindings.xml. -- 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

18 years, 4 months

4
13
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 December 2007