November 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2749) Various rules stop firing when adding more, totally unrelated rules to a knowledge base

by Ansgar Konermann (JIRA)

Various rules stop firing when adding more, totally unrelated rules to a knowledge base --------------------------------------------------------------------------------------- Key: JBRULES-2749 URL: https://jira.jboss.org/browse/JBRULES-2749 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert), drools-core (expert) Affects Versions: 5.1.1.FINAL Environment: Environment 1: Fedora Core 12 x86_64, Sun JVM 1.6.0_20 64-bit Server VM Environment 2: Windows XP Professional, Service Pack 3, 32 bit; Sun JVM 1.6.0_20 32-bit Server VM Reporter: Ansgar Konermann Assignee: Mark Proctor A certain rule suddenly stops firing when adding more and more rules to the knowledge base, which (not only?) on first sight have *nothing* to do with the rule in question. We created a few unit tests which show the faulty behaviour. What we observed so far: * when using declared functions plus declared data types, this error occurrs. * sometimes, one can work around this problem by renaming a package. We're not sure if this is a reliable workaround, i. e. works in all situations. * one can work around this problem by not using declared functions. We're not sure if this is a reliable workaround. Find attached a ZIPed git repository containing: * a Maven 2.1+ pom.xml suitable to trigger the unit tests via mvn test * Java source files for a TestNG-based unit test * example drools source files to illustrate the problem (used by the unit tests) Please have a look at java file RuleDoesNotFireIfUsingDeclaredFunctionAndTooManyPackages.java. This should make quite clear what we're expecting of the drools library and where it fails to fulfil these expectations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

5
16
0 / 0

[JBoss JIRA] Created: (JBASPECT-29) Aspects Security Unit Tests

by Anil Saldhana (JIRA)

Aspects Security Unit Tests --------------------------- Key: JBASPECT-29 URL: https://jira.jboss.org/jira/browse/JBASPECT-29 Project: JBoss Aspects Issue Type: Task Components: security Reporter: Anil Saldhana Assignee: Anil Saldhana Since aspects security has been given to me based on merit, I am jittery ever since we moved it out as an external project. The unit tests are in the AS test suite. There is a need to have some unit tests for aspects security such that a change happens in aspects security, other projects (ejb3, profile services etc) do not get affected, due to regression. -- 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, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated

by Galder Zamarreno (JIRA)

Discrepancies between removing a bean in cache vs bean passivated ----------------------------------------------------------------- Key: EJBTHREE-1500 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1500 Project: EJB 3.0 Issue Type: Sub-task Affects Versions: AS 4.2.3.GA, AS 5.0.0.CR1 Reporter: Galder Zamarreno Assignee: Galder Zamarreno There's a discrepancy between removing a bean from the cache after a timeout when bean is in cache compared to when bean is passivated: Example, when bean is in cache and has to be removed, this is called: if (now - centry.lastUsed >= removalTimeout * 1000) { synchronized (centry) { it.remove(); } } Now, when bean is passivated, this is called: if (now - centry.lastUsed >= removalTimeout * 1000) { get(centry.getId(), false); remove(centry.getId()); } And remove() method calls: if(log.isTraceEnabled()) { log.trace("Removing context " + key); } StatefulBeanContext ctx = null; synchronized (cacheMap) { ctx = (StatefulBeanContext) cacheMap.get(key); } if(ctx == null) throw new NoSuchEJBException("Could not find Stateful bean: " + key); if (!ctx.isRemoved()) container.destroy(ctx); ++removeCount; if (ctx.getCanRemoveFromCache()) { synchronized (cacheMap) { cacheMap.remove(key); } } What this means is that when a bean in cache is removed: 1.- removeCount is not updated 2.- container.destroy(ctx); is not executed and hence the @Remove method is not executed either. -- 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, 8 months

4
7
0 / 0

[JBoss JIRA] Created: (JGRP-855) java.lang.IllegalStateException: Could not flush the cluster and proceed with state retri eaval

by Clebert Suconic (JIRA)

java.lang.IllegalStateException: Could not flush the cluster and proceed with state retri eaval ------------------------------------------------------------------------------------------------ Key: JGRP-855 URL: https://jira.jboss.org/jira/browse/JGRP-855 Project: JGroups Issue Type: Bug Affects Versions: 2.6.5 Reporter: Clebert Suconic Assignee: Vladimir Blagojevic When getState is called right after the connect even with flush, eventually (intermitently) you will get this exception: SomeException: ... Caused by: java.lang.IllegalStateException: Could not flush the cluster and proceed with state retri eaval at org.jgroups.JChannel.getState(JChannel.java:1041) at org.jgroups.JChannel.getState(JChannel.java:973) at org.jgroups.JChannel.getState(JChannel.java:927) at org.jboss.messaging.core.impl.postoffice.GroupMember.start(GroupMember.java:152) ... Notice that this only started to happen only after this change: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/messaging/branches/Branch_1_4/... -- 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, 8 months

5
11
0 / 0

[JBoss JIRA] Created: (JBLOGGING-45) Support automatic log file compression in FileHandler (for compressing all files in real time) and PeriodicRotatingFileHandler (for compressing upon rotation)

by Aleksander Adamowski (JIRA)

Support automatic log file compression in FileHandler (for compressing all files in real time) and PeriodicRotatingFileHandler (for compressing upon rotation) -------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBLOGGING-45 URL: https://jira.jboss.org/jira/browse/JBLOGGING-45 Project: JBoss Logging Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Aleksander Adamowski Assignee: David Lloyd This is a follow up to JBAS-6917. It would be nice to have an automatic compression of log files similar to the one implemented in Log4j extras: http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4... "TimeBasedRollingPolicy supports automatic file compression. This feature is enabled if the value of the FileNamePattern option ends with .gz or .zip." In JBoss Logging, I suppose this could be implemented on 2 levels: 1) In the FileHandler (http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk/src/main/jav...) so that, with proper configuration, each log file is compressed in real time, and it exists only in compressed form from the moment of its creation. 2) In the PeriodicRotatingFileHandler (http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk/src/main/jav...) so that with proper configuration, archival log files can be compressed the moment they are rotated (e.g. server.log.2010-05-06.gz is created instead of server.log.2010-05-06), but the current log file should be plain text. In PeriodicRotatingFileHandler, the implementation must take into account that compression of rotated log files may take considerable time and should be performed in the background - the handler should be able to process log records at any time, particularly during rotation, without losing any. -- 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, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBWEB-72) html page and jsp are not display with in a Context defined in server.xml.

by Jean-Frederic Clere (JIRA)

html page and jsp are not display with in a Context defined in server.xml. -------------------------------------------------------------------------- Key: JBWEB-72 URL: http://jira.jboss.com/jira/browse/JBWEB-72 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Affects Versions: JBoss Web Server 1.0.1 GA Environment: any Reporter: Jean-Frederic Clere Assigned To: Jean-Frederic Clere Priority: Minor When using a Context definition in server.xml like: <Context path="/test" docBase="/home/jfclere/TMP/MYAPP" /> The jsp and html pages of /home/jfclere/TMP/MYAPP are not displayed (404 is returned). That is because the conf/web.xml is not used to set the defaults when the <Context/> is processed. DefaultWebXml is set in TomcatDeployer and that is after the <Context/> needs it. The default value is used but it is set to "web.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

12 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2533) Update Eclipse Compiler dependency

by Fabian Lange (JIRA)

Update Eclipse Compiler dependency ---------------------------------- Key: JBRULES-2533 URL: https://jira.jboss.org/browse/JBRULES-2533 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.1.0.M2 Reporter: Fabian Lange Assignee: Mark Proctor drools-compiler pom includes a reference to eclipse JDT. in 5.0.1 this was a 4 MB core_whatever.jar Because I wanted to improve compiler performance I tried out a never eclipse compiler package. Finding it was not very easy, because eclipse seems to change group and artifact ids every day. I found a module which only contains the compiler part from eclipse 3.5.1, which works in all my tests ok. Another nice benefit was that the size of my war shrunk by 3 Megabytes, as this module is only 1.7 megs. It even helped for performance of compilation process by the way. Not that this is a main bottleneck, but we have files that take seconds to compile. My tests on my windows box with java 6 gave 5-10% improvement using the 3.5.1 jdt compiler. Here the part for the pom: {code} <dependency> <groupId>org.eclipse.jdt.core.compiler</groupId> <artifactId>ecj</artifactId> <version>3.5.1</version> </dependency> {code} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-8470) SocketBinding.createMulticastSocket() not safe across platforms

by Brian Stansberry (JIRA)

SocketBinding.createMulticastSocket() not safe across platforms --------------------------------------------------------------- Key: JBAS-8470 URL: https://jira.jboss.org/browse/JBAS-8470 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Brian Stansberry Fix For: 7.0.0.M2 The usage of java.net.MulticastSocket is one of the areas where the JDK does a poor job of abstracting away the underlying OS. Patterns of MulticastSocket construction that work well on BSD-based OSs don't work on Windows and vice versa. SocketBinding.createMulticastSocket() should adapt the code used in JGroups for dealing with this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
8
0 / 0

[JBoss JIRA] Created: (JBRULES-1917) JBRMS does not support business rules with non ascii characters

by Gregory Chazalon (JIRA)

JBRMS does not support business rules with non ascii characters --------------------------------------------------------------- Key: JBRULES-1917 URL: https://jira.jboss.org/jira/browse/JBRULES-1917 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.7 Reporter: Gregory Chazalon Assignee: Mark Proctor A very simple rule containing some Latin1 characters (e.g. 'é', 'à'..), is not compiled correctly when using the JBRMS web app. The exact same rule defined in a DRL file, and compiled with the drools compiler API is well handled (no characters mismatch). Actually, the rule defined both ways is : {code} rule "latin_message" when Let information message then information message containing latin characters léger problème à résoudre hôpital end {/code} I strongly suspect a poor character encoding scheme inside the JBRMS code, but I haven't been able to identify it. The problem is illustrated by the LatinMessageTest test case, bundled inside the small eclipse project provided. It has two test methods, one building the rule using the drools compiler API, and the other using a binary package built with JBRMS. The second one fails as of the poor character encoding suspected inside JBRMS web app. Any help is appreciated. -- 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, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1602) The order of RHS statements shouldn't affect behavior (insertLogical)

by Patrick Gras (JIRA)

The order of RHS statements shouldn't affect behavior (insertLogical) --------------------------------------------------------------------- Key: JBRULES-1602 URL: http://jira.jboss.com/jira/browse/JBRULES-1602 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Environment: Drools 4.0.7 & 4.0.4, Java5, eclipse compiler, windows XP. Reporter: Patrick Gras Assigned To: Mark Proctor I have a class 'Cat' that is dynamic (JavaBean with PropertyChangeSupport ) with only a 'name' attribute. Then I have the following rule: rule "test" when $cat:Cat( name == "tom" ) then $cat.setName("cat"); insertLogical(new String("test")); end When I test the rule against a Cat named tom, the logical inserted fact is not retracted. (So the fact is inserted because the rule matches, but is not retracted even if the rule is no more matching at the end.) If I change the order of the RHS, it works fine. The fact is inserted and then retracted. rule "test" when $cat:Cat( name == "tom" ) then insertLogical(new String("test")); $cat.setName("cat"); end So the behavior depends on the ordering of the RHS statements. Here is a complete example to show the problem: public class Cat { private String name; protected PropertyChangeSupport changes = new PropertyChangeSupport(this); public Cat(String name) { super(); this.name = name; } public String getName() { return this.name; } public void setName(String name) { final String oldName = this.name; this.name = name; this.changes.firePropertyChange("name", oldName, name); } public void addPropertyChangeListener(final PropertyChangeListener listener) { this.changes.addPropertyChangeListener(listener); } public void removePropertyChangeListener( final PropertyChangeListener listener) { this.changes.removePropertyChangeListener(listener); } } public class RHSOrderingTest { private static final String PACKAGE = "package ch.generali.pgr.rule "; private static final String IMPORT = "import ch.generali.pgr.rules.Cat "; private static final String WHEN = "rule \"test ok\" when $cat:Cat( name == \"tom\" ) "; private static final String THEN_OK = "then insertLogical(Integer.valueOf(1)); $cat.setName(\"cat\"); end"; private static final String THEN_KO = "then $cat.setName(\"cat\"); insertLogical(Integer.valueOf(1)); end"; private static final String RULE_OK = PACKAGE + IMPORT + WHEN + THEN_OK; private static final String RULE_KO = PACKAGE + IMPORT + WHEN + THEN_KO; private static final String QUERY = "query \"My test Integer\" integer : Integer( intValue == 1 ) end"; public static void main(String[] args) { boolean ok_1 = testWithRule(RULE_OK); boolean ok_2 = testWithRule(RULE_KO); System.out.println((ok_1 ? "SUCCESS: " : "FAILED: ") + THEN_OK); System.out.println((ok_2 ? "SUCCESS: " : "FAILED: ") + THEN_KO); } private static boolean testWithRule(String rule) { Cat tom = new Cat("tom"); RuleBase rb = createRuleBase(rule + "\n" + QUERY); WorkingMemory wm = rb.newStatefulSession(); wm.insert(tom, true); wm.fireAllRules(); QueryResults results = wm.getQueryResults("My test Integer"); return results.size() == 0; } private static RuleBase createRuleBase(String rules) { try { RuleBase ruleBase = RuleBaseFactory.newRuleBase(); PackageBuilderConfiguration conf = new PackageBuilderConfiguration(); PackageBuilder packageBuilder = new PackageBuilder(conf); Reader source = new StringReader(rules); packageBuilder.addPackageFromDrl(source); Package pkg = packageBuilder.getPackage(); ruleBase.addPackage(pkg); return ruleBase; } catch (Exception e) { throw new RuntimeException(e); } } } -- 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, 9 months

7
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 November 2010