August 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1125) Java Step over is broken

by Mark Proctor (JIRA)

Java Step over is broken ------------------------ Key: JBRULES-1125 URL: http://jira.jboss.com/jira/browse/JBRULES-1125 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Eclipse IDE Reporter: Mark Proctor Assigned To: Kris Verlaenen Fix For: 4.0.1 Java Step Over is broken. I put in a break point and I can't step through the 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

18 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1128) Xstream should be optional for drools-core and it should use the non-legacy groupId

by Geoffrey De Smet (JIRA)

Xstream should be optional for drools-core and it should use the non-legacy groupId ------------------------------------------------------------------------------------ Key: JBRULES-1128 URL: http://jira.jboss.com/jira/browse/JBRULES-1128 Project: JBoss Rules Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 4.0.0.GA Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Fix For: FUTURE  <dependency> <groupId>com.thoughtworks.xstream</groupId> <artifactId>xstream</artifactId> <version>1.2.2</version> </dependency>  <dependency> <groupId>com.thoughtworks.xstream</groupId> <artifactId>xstream</artifactId> <optional>true</optional> </dependency> -- 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, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1115) Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost between the instance available within the rule and that of the original bean

by Anthony Dawson (JIRA)

Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost between the instance available within the rule and that of the original bean ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-1115 URL: http://jira.jboss.com/jira/browse/JBRULES-1115 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.0.GA Environment: HP-UX java version "1.5.0.05" Reporter: Anthony Dawson Assigned To: Mark Proctor Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost between the instance available within the rule and that of the original bean During the execution of the rules when I modify a list my changes are not reflected in my bean. Changes which affect simple objects like integers, strings etc are modified OK but lists do not get updated in the bean. Details of this problem are described in the forum messages. http://www.nabble.com/How-to-limit-results-from-a-collect-statement-tf423... -- 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, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4593) Leak in org/jboss/mx/loading/UnifiedClassLoader3

by Mike Millson (JIRA)

Leak in org/jboss/mx/loading/UnifiedClassLoader3 ------------------------------------------------ Key: JBAS-4593 URL: http://jira.jboss.com/jira/browse/JBAS-4593 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-4.0.5.GA Reporter: Mike Millson Assigned To: Scott M Stark [description pasted from support case] After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.amfam" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following: found a path to the target: 26093 (depth: 5) 0 0 Heap root 26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer; 124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue; 160611 0 Instance: [Ljava/lang/Object; 161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification; 217357 0 Instance: Ljavax/management/Notification; 26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3; So, even though our application is undeployed, strong paths from their classloaders to heap roots exist. Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this 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

18 years, 11 months

4
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1122) Eclipse-JDT compiler jar (core-3.2.0.666.jar) for drools creates problems/conflicts with the existing one (jasper-compiler-jdt.jar - used by tomcat for JSP compilation)

by Suman Ghosh (JIRA)

Eclipse-JDT compiler jar (core-3.2.0.666.jar) for drools creates problems/conflicts with the existing one (jasper-compiler-jdt.jar - used by tomcat for JSP compilation) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Key: JBRULES-1122 URL: http://jira.jboss.com/jira/browse/JBRULES-1122 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.0.GA, 3.0.6 Environment: Windows XP / JDK 1.5.0_06-b05 Reporter: Suman Ghosh Assigned To: Mark Proctor I'm running a service using JBoss, which uses Drools for its various rule-based components. The propblem arises like this - when I use the JDTcompiler in Drools, tomcat crashes with the following stacktrace (when used to access JSPs - such as the JBoss JMX console).... ----------------------------------------------------START------------------------------------------------------------------- type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem; org.apache.jasper.servlet.JspServlet.service(JspServlet.java:272) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) root cause java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem; org.apache.jasper.compiler.JDTCompiler$2.acceptResult(JDTCompiler.java:345) org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:417) org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:404) org.apache.jasper.compiler.Compiler.compile(Compiler.java:297) org.apache.jasper.compiler.Compiler.compile(Compiler.java:276) org.apache.jasper.compiler.Compiler.compile(Compiler.java:264) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:303) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17 logs. ---------------------------------------------------END-------------------------------------------------------------------- Seems that the class CompilationResult from the new JDT distribution has a different signature for the getProblems() method - but tomcat expects the earlier one only. For my application, I *have* to use the JDT compiler for my rule base, and on the other hand, I require the jboss jmx-console, for service monitoring and method invokations :( Please suggest a solution! -- 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, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1123) Custom Consequence Exception handlers

by Mark Proctor (JIRA)

Custom Consequence Exception handlers ------------------------------------- Key: JBRULES-1123 URL: http://jira.jboss.com/jira/browse/JBRULES-1123 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 4.0.1 RuleBaseConfiguration should allow the user to specify a custom handler for consequence exceptions. -- 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, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1106) Copied rules using a guided DSL in BRMS produce duplicate rule names in built binary packages.

by Shahad Ahmed (JIRA)

Copied rules using a guided DSL in BRMS produce duplicate rule names in built binary packages. ---------------------------------------------------------------------------------------------- Key: JBRULES-1106 URL: http://jira.jboss.com/jira/browse/JBRULES-1106 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.0.GA Environment: Windows XP SP2, Sun JRE 1.5_09 Reporter: Shahad Ahmed Assigned To: Mark Proctor I found the following problem when creating rules using the guided rule editor in the BRMS with a DSL. If you use the copy option to copy an existing rule, everything seems okay and a new copy of the rule is created in the package. However, if you build the package and view the package source then any rule that was copied from another rule has the same name as the original rule. Consequently your rule package has rules with the same name and will throw an error when loaded into a rulebase. Note this problem does not appear to occur if you do not use a DSL. Here's how to replicate the problem for a clean BRMS install: 1. Create a new category called test. 2. In the defaultPackage create a new DSL called test as shown below: [when]true=eval(true) [then]report=System.out.println("Hello"); 3. Save the test DSL 4. Create a new Business Rule in the defaultPackage called test1 with category test and using the guided rule editor. 5 Add a when expression using the DSL sentence "true" and add a then action using the DSL sentence "report". In the rule option, add the dialect attribute and set it to "java". 6. Save rule test1. 7. Click on the Copy tab to copy test1. Name the new rule test2. You will see a dialog that confirms the creation of rule test2. 8. Open rule test2 from the rule browser and it seems okay and has the name test2 (minor funny is that test2 has version 2, whereas test1 only has version 1). 9. Select the package option on the left of the BRMS and select the defaultPackage so that you see the "Build, Validate and Deploy" option. Select this and build the package. 10 Now click on the Show Package Source button and you will see two rules both named test1 (as shown below) instead of two rules named test1 and test2 as expected. This package is incorrect, even though the rules in the BRMS seem to correctly have names test1 and test2. I can confirm that trying to load the exported binary package into a rulebase cause an error to be reported (so it's not just a bug in the show package source code, but in the generated binary as well). package defaultPackage rule "test1" dialect "java" when eval(true) then System.out.println("Hello"); end rule "test1" dialect "java" when eval(true) then System.out.println("Hello"); end Shahad -- 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, 11 months

4
4
0 / 0

[JBoss JIRA] Closed: (JBMICROCONT-93) Add JBossRetro builds for Microcontainer projects

by Paul Gier (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-93?page=all ] Paul Gier closed JBMICROCONT-93. -------------------------------- Resolution: Done The basic retro builds and tests are now in place. I created new issues for setting up hudson builds, and for resolving the remaining issues with the tests. Due to a limitation in maven, the retro modules have to be built individually instead of as an aggregated project. I will try to get this issue resolved in an upcoming release of maven. > Add JBossRetro builds for Microcontainer projects > ------------------------------------------------- > > Key: JBMICROCONT-93 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-93 > Project: JBoss MicroContainer > Issue Type: Sub-task > Components: General > Reporter: Adrian Brock > Assigned To: Paul Gier > Fix For: JBossMC-2.0.0.CR1 > > > Make JBossRetro builds for the microcontainer projects > such that they can use JDK5 features. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBBUILD-406) Create retro build for aop

by Paul Gier (JIRA)

Create retro build for aop -------------------------- Key: JBBUILD-406 URL: http://jira.jboss.com/jira/browse/JBBUILD-406 Project: JBoss Build System Issue Type: Task Components: Maven Reporter: Paul Gier Fix For: Maven Build - App Server AOP needs a retro build -- 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, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-4546) Fix RunAsSecurityInterceptor

by Kabir Khan (JIRA)

Fix RunAsSecurityInterceptor ---------------------------- Key: JBAS-4546 URL: http://jira.jboss.com/jira/browse/JBAS-4546 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: AOP Affects Versions: JBossAS-4.2.1.GA Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: JBossAS-4.2.2.GA Add this fix once branch is no longer frozen -- 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, 11 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 August 2007