November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBFORUMS-232) Add Italian and German support

by Ryszard Kozmik (JIRA)

Add Italian and German support ------------------------------ Key: JBFORUMS-232 URL: http://jira.jboss.com/jira/browse/JBFORUMS-232 Project: JBoss Forums Issue Type: Task Components: Forum View Layer, Portlet Productization Reporter: Ryszard Kozmik Assigned To: Ryszard Kozmik Fix For: 1.0.1 RC ResourceBundles for those languages have to be added and made simplified like the main 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

17 years

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1354) Duplicate parameter while trying to use pattern bound variables or globals in accumulate function

by Eric Miles (JIRA)

Duplicate parameter while trying to use pattern bound variables or globals in accumulate function ------------------------------------------------------------------------------------------------- Key: JBRULES-1354 URL: http://jira.jboss.com/jira/browse/JBRULES-1354 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Environment: JDK 1.5.0_13, Ubuntu 7.10 Reporter: Eric Miles Whenever I attempt to reference a pattern bound variable (declared outside of accumulate) or a global from within an accumulate function, I get a "Duplicate parameter" error. Example of pattern bound variable: rule "Test" when $obj: SomeObject() Integer() from accumulate( AnotherObject() , init (int total = 0 ), action ( total += $obj.getValue(); ), reverse ( total -= $obj.getValue(); ), result ( total) ) then System.out.println("HI!"); end The same happens when if I attempt to use a global. Here is an exact stacktrace of the error: org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name=Daily Core Hours, agendaGroup=MAIN, salience=0, no-loop=false] com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (32:1301) : Duplicate parameter $schedOut com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (32:1330) : Duplicate parameter $schedIn com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (41:1735) : Duplicate parameter $schedOut com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (41:1764) : Duplicate parameter $schedIn com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (51:2330) : Duplicate parameter $schedOut com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (51:2359) : Duplicate parameter $schedIn com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (58:2738) : Duplicate parameter $schedOut com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (58:2767) : Duplicate parameter $schedIn at org.drools.rule.Package.checkValidity(Package.java:424) at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:364) at com.kronos.webta.service.smarttime.rules.maxiflex.FlowTest.setUpBeforeClass(FlowTest.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.ClassRoadie.runBefores(ClassRoadie.java:49) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:36) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- 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

17 years

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4835) TECH REVIEW: Clustering Guide - Chapter 1 - Introduction

by samson kittoli (JIRA)

TECH REVIEW: Clustering Guide - Chapter 1 - Introduction -------------------------------------------------------- Key: JBAS-4835 URL: http://jira.jboss.com/jira/browse/JBAS-4835 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: JBossAS-4.2.2.GA Reporter: samson kittoli Assigned To: Norman Richards Attached is an Open Office 2.0 Document containing a chapter of the Clustering Guide 1. Open document in Open Office 2. Edit -> Changes -> Record 3. Edit the document 4. Save changes and reattach to this Jira It is important for track changes to be enabled so the re-write can be easily performed. http://labs.jboss.com/jbossas/docs/Clustering_Guide/beta422/html/ -- 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

17 years

4
8
0 / 0

[JBoss JIRA] Created: (JBBUILD-324) Build.xml in testsuite directory doesn't support multiple JVM argument

by Sunny Chan (JIRA)

Build.xml in testsuite directory doesn't support multiple JVM argument ---------------------------------------------------------------------- Key: JBBUILD-324 URL: http://jira.jboss.com/jira/browse/JBBUILD-324 Project: JBoss Build System Issue Type: Feature Request Components: Targets and Tasks Affects Versions: Repository Build head, Repsository Build Branch_4_0 Environment: Any Reporter: Sunny Chan Priority: Minor We are using the JBoss unit test as part of our JVM verification testsuite. We wanted to be able to invoke tests with multiple JVM options, but it didn't work. If you set parameters via build.sh -Djunit.vm.options with multiple paramters (e.g. -Djunit.vm.options="-d64 -verbose:gc"), it will fail with unrecongized option error. The problem is that in testsuite/build.xml, the junit.vm.options is passed onto junit ant task via <jvmarg value> tag rather then <jvmarg line> tag. The jvmarg line allows multiple JVM options exist in one line. Once I replace all instance of <jvmarg value="${junit.jvm.options}"/> with <jvmarg line="${junit.jvm.options}"/> then the problem goes away. I can provide a patch for this if you want - but I don't know the rules on patches (whether I need to be cleared for contribution) so let me know if you want that. -- 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

17 years

4
8
0 / 0

[JBoss JIRA] Created: (JBRULES-1336) Typo in RuleBaseConfiguration(ClassLoader classLoder, Properties properties) -- the ClassLoader specified in the constructor args is not used

by James Sparrow (JIRA)

Typo in RuleBaseConfiguration(ClassLoader classLoder, Properties properties) -- the ClassLoader specified in the constructor args is not used --------------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-1336 URL: http://jira.jboss.com/jira/browse/JBRULES-1336 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Reporter: James Sparrow The RuleBaseConfiguration constructor: {code} public RuleBaseConfiguration(ClassLoader classLoder, Properties properties) { init( classLoader, properties ); } {code} contains a typo--the call to init should pass the (mis-spelled) classLoder, not the member field classLoader. As it is, the null member field is passed instead, resulting in the given ClassLoader instance being unused. Trivial fix: Just correct the spelling of the constructor arg name: {code} public RuleBaseConfiguration(ClassLoader classLoader, Properties properties) { init( classLoader, properties ); } {code} -- 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

17 years

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1325) OutOfMemry with the use of WorkingMemoryFileLogger

by Delbart Vincent (JIRA)

OutOfMemry with the use of WorkingMemoryFileLogger -------------------------------------------------- Key: JBRULES-1325 URL: http://jira.jboss.com/jira/browse/JBRULES-1325 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Reporter: Delbart Vincent Priority: Critical Hello, In my tests of the 4.0.3, I have some : java.lang.OutOfMemoryError. So, I try a simple test with 10.000 sequential execution of 1 rule with no context and just a workingmemorylogger and I have the error : java.lang.OutOfMemoryError: Java heap space My code is : public class ExecReglesMemotyTest { private static final Reader DRL = new InputStreamReader(ExecReglesMemotyTest.class .getResourceAsStream("/rules/exemple.drl")); private static final String FICHIER_LOG = "session"; /** * @param args */ public static void main(String[] args) { try { PackageBuilder builder = new PackageBuilder(); builder.addPackageFromDrl(DRL); RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage(builder.getPackage()); for (int i = 0; i < 10000; i++) { StatefulSession session = ruleBase.newStatefulSession(); WorkingMemoryFileLogger logger = new WorkingMemoryFileLogger(session); logger.setFileName(FICHIER_LOG); session.fireAllRules(); logger.writeToDisk(); session.dispose(); } } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } } } with this rule (doesn't matter): #created on: Fri Nov 09 15:48:45 CET 2007 package initPackage #list any import classes here. rule "ERG9" when then end I try this in 4.0.1, and it's working (no OutOfMemoryError) What's the problem ? thanks for any information, V. -- 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

17 years

3
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-1204) Investogate shutdown hook usage in an MBeanServer environment

by Manik Surtani (JIRA)

Investogate shutdown hook usage in an MBeanServer environment ------------------------------------------------------------- Key: JBCACHE-1204 URL: http://jira.jboss.com/jira/browse/JBCACHE-1204 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.CR1, 2.1.0.GA -- 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

17 years

1
11
0 / 0

[JBoss JIRA] Created: (JBCACHE-1226) State transfer doesn't clean out persistent store if size of transferred persistent state is 0

by Brian Stansberry (JIRA)

State transfer doesn't clean out persistent store if size of transferred persistent state is 0 ---------------------------------------------------------------------------------------------- Key: JBCACHE-1226 URL: http://jira.jboss.com/jira/browse/JBCACHE-1226 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.1.SP7 Reporter: Brian Stansberry Assigned To: Manik Surtani Priority: Minor StateTransferIntegrator_140.integratePersistentState() is a no-op if the size of the provided persistent state is 0. So, if persistent state transfer is enabled but the provider doesn't have any persistent state to transfer, any stale persistent state laying around on the recipient will not get cleaned up. A fix for this needs to properly discriminate between the above case and one where no persistent state is available because persistent state transfer is disabled. Manik, I found this when a solution to an EJB3 bug didn't work as expected. I can tweak my solution to get around it, so this isn't urgent for me. Feel free to assign to me, although I likely won't get to it for a long time. This likely affects all releases in the 1.x series. A *quick* look at how this works leads me to expect it's not an issue in 2.x. -- 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

17 years

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-4301) Evaluate replacing FileCacheLoader with JdbmCacheLoader

by Brian Stansberry (JIRA)

Evaluate replacing FileCacheLoader with JdbmCacheLoader ------------------------------------------------------- Key: JBAS-4301 URL: http://jira.jboss.com/jira/browse/JBAS-4301 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 Need to establish a relationship with the JDBM guys to see how suitable and supportable it is. -- 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

17 years

1
1
0 / 0

[JBoss JIRA] Created: (JBBUILD-378) Research options for testing dependency version ranges

by Paul Gier (JIRA)

Research options for testing dependency version ranges ------------------------------------------------------ Key: JBBUILD-378 URL: http://jira.jboss.com/jira/browse/JBBUILD-378 Project: JBoss Build System Issue Type: Task Components: Maven Reporter: Paul Gier Fix For: MavenBuild 2007 It would be helpful to be able to automatically run a maven build with each of the valid combinations of dependency versions. For example, if a dependency includes a version range of 1.1, 1.2, and 1.3. We would want to build and test the project using each of these versions to make sure that they all work correctly. Sherriff on the maven forum has worked on something like this for continuum. When we move our automated builds to hudson, maybe we could create something similar to this. -- 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

17 years

2
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2007