September 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-887) Performance: test with OpenJDK (IcedTea)

by Bela Ban (JIRA)

Performance: test with OpenJDK (IcedTea) ---------------------------------------- Key: JGRP-887 URL: https://jira.jboss.org/jira/browse/JGRP-887 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 -- 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

16 years

1
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2154) equality assertion behavior not supported in streams

by Jaroslaw Kijanowski (JIRA)

equality assertion behavior not supported in streams ---------------------------------------------------- Key: JBRULES-2154 URL: https://jira.jboss.org/jira/browse/JBRULES-2154 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (fusion) Affects Versions: 5.0.1.FINAL Reporter: Jaroslaw Kijanowski Assignee: Edson Tirelli Happens with 5.0.1 and trunk 27324 I've configured my knowledge base to use the EQUALITY assertion behavior. When I insert two equal facts into the session, only one gets processed (objects and their fact handles are equal). However when I insert two equal facts via streams, my rule fires twice (objects are equal, but their fact handles are not). Isn't equality assertion behavior supported when using streams? Attaching rule, model and test class. If you run it you will see following output: equal 1 That's expected. If you remove the comment from WorkingMemoryEntryPoint stream = ... FactHandle fh1 = stream.insert(message1); FactHandle fh2 = stream.insert(message2); and comment out FactHandle fh1 = ksession.insert(message1); FactHandle fh2 = ksession.insert(message2); and modify the rule file to use streams (just remove comments) you will get this output: 1 1 Means the rule fired twice. -- 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

16 years

3
5
0 / 0

[JBoss JIRA] Created: (JGRP-1023) S3_PING: certificate exception when run on EC2

by Bela Ban (JIRA)

S3_PING: certificate exception when run on EC2 ---------------------------------------------- Key: JGRP-1023 URL: https://jira.jboss.org/jira/browse/JGRP-1023 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 S3_PING does not work on EC2. It works perfectly when run on a local box -- 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

16 years

2
7
0 / 0

[JBoss JIRA] Created: (JBRULES-2206) exists Foo() does not fire if facts inserted before rule

by Wolfgang Laun (JIRA)

exists Foo() does not fire if facts inserted before rule -------------------------------------------------------- Key: JBRULES-2206 URL: https://jira.jboss.org/jira/browse/JBRULES-2206 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.0.1.FINAL Reporter: Wolfgang Laun Assignee: Mark Proctor Facts of some type Foo are inserted into a StatefulKnowledgeSession, then a rule with LHS exists Foo() is added and fireAllRules() is called, but the rule does not fire. If the same is done with the FOP-equivalent rule containing CE not(not Foo()), the rule fires. -- 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

16 years

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2266) Memory leaks where the classloader cannot be garbage collected / impossible to dispose tomcat devloader when i reload context (drools keep reference)...

by GREFFET Emmanuel (JIRA)

Memory leaks where the classloader cannot be garbage collected / impossible to dispose tomcat devloader when i reload context (drools keep reference)... -------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-2266 URL: https://jira.jboss.org/jira/browse/JBRULES-2266 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: All Affects Versions: 4.0.7 Environment: XP SP2 2Mo Tomcat 5.5.9 / drools 4.0.7 Reporter: GREFFET Emmanuel Assignee: Mark Proctor Priority: Critical (sorry for my English) We use drools 4.0.7 in a hospital application. We load drools and our programs (services) with tomcat Devloader (5.5.9) We use drools in statefullsession (retract and insert facts by rules in a ruleFlow). everything is perfect for us, except a little problem of "dispose" with tomcat due to drools. Through the Tomcat console when we try to restart our webapp, tomcat can't dispose the old Devloader (in Eclipse we can see that many drools class use class attribute ClassLoader without any dispose ???) In production, we used different webapps in a Tomcat, so we can't easily stop Tomcat, so until we stop tomcat, the reload of the webapps is longer and longer ... (many devloader(s) can't dispose)... anyone has had this problem ? -- 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

16 years

3
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2150) stream mode requires DroolsStreamUtils

by Jaroslaw Kijanowski (JIRA)

stream mode requires DroolsStreamUtils -------------------------------------- Key: JBRULES-2150 URL: https://jira.jboss.org/jira/browse/JBRULES-2150 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (fusion) Affects Versions: 5.0.1.FINAL Reporter: Jaroslaw Kijanowski Assignee: Edson Tirelli Attachments: cep.drl, CEPTest.java, Sensor.java I'm using sliding windows (hence stream mode). Here's my rule: rule 'r' when Number( dv:doubleValue > 1 ) from accumulate( Sensor( $v : value ) over window:length( 2 ), average( $v ) ) then System.out.println(dv); end Here's my class: ++++++++++++++++++++++++++++++++++++++++++++++ public class CEPTest { public static void main(String[] args) throws Exception { . . . kbase.addKnowledgePackages(kbuilder.getKnowledgePackages()); KnowledgeBase kbase2 = (KnowledgeBase) DroolsStreamUtils.streamIn(DroolsStreamUtils.streamOut(kbase), null); final StatefulKnowledgeSession ksession = kbase2.newStatefulKnowledgeSession(); System.out.println("T1"); ksession.insert(new Sensor(1.0)); ksession.fireAllRules(); System.out.println("T2"); ksession.insert(new Sensor(2.0)); ksession.fireAllRules(); System.out.println("T3"); ksession.insert(new Sensor(3.0)); ksession.fireAllRules(); ksession.dispose(); } } ++++++++++++++++++++++++++++++++++++++++++++++ The output is (as expected): +++++++++++++++ T1 T2 1.5 T3 2.5 +++++++++++++++ I'm wondering why I have to use DroolsStreamUtils to get a knowledge base? When I use kbase (which didn't went through DroolsStreamUtils) instead of kbase2 to create a new session, the output will be: +++++++++++++++ T1 T2 2.0 T3 3.0 +++++++++++++++ Attaching all 3 files needed to reproduce - rule, model and test. -- 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

16 years

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1398) Document constraint weighting in the solver manual

by Geoffrey De Smet (JIRA)

Document constraint weighting in the solver manual -------------------------------------------------- Key: JBRULES-1398 URL: http://jira.jboss.com/jira/browse/JBRULES-1398 Project: JBoss Drools Issue Type: Task Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Optional use examination examples? -- 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

16 years

1
2
0 / 0

[JBoss JIRA] Created: (JBMETA-208) Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing

by Richard Kennard (JIRA)

Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing ------------------------------------------------------------------------------------------ Key: JBMETA-208 URL: https://jira.jboss.org/jira/browse/JBMETA-208 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.1.GA Environment: JBoss AS 5.1.0.GA Reporter: Richard Kennard Assignee: Alexey Loubyansky The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example... <ejb-jar> </ejb-jar> ...instead of... <ejb-jar version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"> </ejb-jar> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced. An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation... http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/p... ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA. -- 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

16 years

7
23
0 / 0

[JBoss JIRA] Created: (JBJMX-109) loaderRepositoryClass="..." seems to be useless

by David Schlotfeldt (JIRA)

loaderRepositoryClass="..." seems to be useless ----------------------------------------------- Key: JBJMX-109 URL: http://jira.jboss.com/jira/browse/JBJMX-109 Project: JBoss JMX Issue Type: Feature Request Affects Versions: JBossAS-4.0.0 Reporter: David Schlotfeldt This isn't exactly an error, and maybe we just aren't suppose to use it, but DTD and documentation says we can specify an implementation of org.jboss.mx.loading.LoaderRepository to use in many xml files, such as jboss-app.xml, with the loaderRepositoryClass attribute. Well even though you can -- you can't. You can't because a number of classes including UnifiedClassLoader cast objects directly to UnifiedLoaderRepository3 instead of LoaderRepository. Which means your implementations actually need to extend UnifiedLoaderRepository3. Also HeirarchicalLoaderRepository3 is not flexible. You would think it would be possible to create a hierarchy of LoaderRepositorys but you can't. This is because it expects its parent to be a UnifiedLoaderRepository3 -- okay fine, whatever. So you should at least be able a HeirarchicalLoaderRepository3 object as a parent to another HeirarchicalLoaderRepository3 object since UnifiedLoaderRepository3 extends UnifiedLoaderRepository3. You can't . Why? Well because I am PRETTY SURE that HeirarchicalLoaderRepository3.getPackageClassLoaders(..) returns a Set of PkgClassLoader objects while UnifiedLoaderRepository3 .getPackageClassLoaders(..) (the method it overrides!) returns a Set of RepositoryClassLoader objects. When HeirarchicalLoaderRepository3 calls getPackageClassLoaders(...) on its parent repository it casts items to RepositoryClassLoader , since that is what UnifiedLoaderRepository3 returns. This means if you make HeirarchicalLoaderRepository3 have a parent of type HeirarchicalLoaderRepository3 you will get a ClassCastException since.. well.. a PkgClassLoader isn't a RepositoryClassLoader class. LoadMgr3 is actually programmed to expect the Set returned by getPackageClassLoaders(...) to be both RepositoryClassLoader and PkgClassLoader objects probably because of this. I COMPLETELY understand how code gets messy through time but this code should really be cleaned up -- especially if we are allowing users to specify a LoaderRepository implementation. As it stands the loaderRepositoryClass attribute SEEMS to be useless to specify your own implementation. -- 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

16 years

3
2
0 / 0

[JBoss JIRA] Created: (JASSIST-39) failure to compile an instance method which invokes a static method in a different class and both methods have the same return type, name and argument types

by twieger (JIRA)

failure to compile an instance method which invokes a static method in a different class and both methods have the same return type, name and argument types ------------------------------------------------------------------------------------------------------------------------------------------------------------ Key: JASSIST-39 URL: http://jira.jboss.com/jira/browse/JASSIST-39 Project: Javassist Issue Type: Bug Reporter: twieger Assigned To: Shigeru Chiba The testcase below demonstrates the problem. The first invocation of CtNewMethod#make works, the second one fails. It looks like the problem is related with MemberResolver#lookupMethod. The check to enable the creation of a recursively called method is not precise enough. It actually succeeds, although the current method is an instance method, and the method which shall be invoked is a static method. ========================================== package experimental; import javassist.CannotCompileException; import javassist.ClassPool; import javassist.CtClass; import javassist.CtNewMethod; import org.testng.annotations.Test; public class TestJavaAssist { @Test public void testJavaAssist() throws CannotCompileException { ClassPool classPool = new ClassPool(); classPool.appendSystemPath(); CtClass ctClass = classPool.makeClass("Test"); CtNewMethod.make("public String foox(){return experimental.TestJavaAssist.foo();}", ctClass); CtNewMethod.make("public String foo(){return experimental.TestJavaAssist.foo();}", ctClass); } public static final String foo() { return "foo"; } } -- 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

16 years

2
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 September 2009