July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1046) Business Object returns null due to Shadow Fact, unless declared final

by Arjun Dhar (JIRA)

Business Object returns null due to Shadow Fact, unless declared final ---------------------------------------------------------------------- Key: JBRULES-1046 URL: http://jira.jboss.com/jira/browse/JBRULES-1046 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 4.0.0.GA, 4.0.0.MR3 Environment: Windows, X86 based machine Reporter: Arjun Dhar Assigned To: Mark Proctor SCENARIO ----------------- Define an Object 'BooleanConfiguration' public class BooleanConfiguration extends BusinessObject { String paramName; //with setter and getter Boolean value; //with setter and getter Client client; //with setter and getter -- Client is an object that composes of String clientId; } *BusinessObject is just a generic Object that maintains a reference to the Assertion List from where it came (Ref. to the container object, Collection). Action(s): ------------- 1. initialize the object with a Parameter and Value (Hard code to test) -- Set 2. Execute against a Rule: When config: BooleanConfiguration(value==true) Then //Do something end EXECUTION NOTES: ------------------------------- 1. I asserted this object and the rule was not executing as I expected. 2. I put a break point in the object, and found that it set it correctly but whenenver the rule engine called the get method the vaue of the object was null. 3. I traced this the place where it creates shadows in Rete.java. I had observed a similar behaviour in version 3.1 or 3.6 (if there was a 3.6). it was more prolific then. 4. I made the class 'final' (This prevents a shadow from being created), and voila my rule worked as expected. Note: None of the other objects needed a final, but had comeplex associations. But this particular object does not run, unless declared final. -- 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
7
0 / 0

[JBoss JIRA] Created: (JBRULES-1050) Extra space between variable and field name in LHS causes crash

by Alexandre Gattiker (JIRA)

Extra space between variable and field name in LHS causes crash --------------------------------------------------------------- Key: JBRULES-1050 URL: http://jira.jboss.com/jira/browse/JBRULES-1050 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.0.GA Reporter: Alexandre Gattiker Assigned To: Mark Proctor Writing a condition as "$co:Item(attachment in ($c, $c. parent))" fails at runtime with an uninformative exception. Removing the extra space and writing "$c.parent" corrects the problem. Below is the rule file, sample code and exception trace. package com.sample import com.sample.DroolsTest.Child; import com.sample.DroolsTest.Parent; import com.sample.DroolsTest.Item; rule "My Rule" when $c:Child() $co:Item(attachment in ($c, $c. parent)) then System.out.println("wawa"); end 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; /** * This is a sample file to launch a rule package from a rule source file. */ public class DroolsTest { public static final void main(String[] args) { try { RuleBase ruleBase = readRule(); } catch (Throwable t) { t.printStackTrace(); } } private static RuleBase readRule() throws Exception { Reader source = new InputStreamReader(DroolsTest.class .getResourceAsStream("/Sample.drl")); PackageBuilder builder = new PackageBuilder(); builder.addPackageFromDrl(source); Package pkg = builder.getPackage(); RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage(pkg); return ruleBase; } public static class Parent { } public static class Child { private Parent parent; public Parent getParent() { return parent; } } public static class Item { private Object attachment; public Object getAttachment() { return attachment; } } } java.lang.NullPointerException at org.drools.reteoo.builder.PatternBuilder.createConstraints(PatternBuilder.java:128) at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:72) at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:54) at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:112) at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70) at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:136) at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:109) at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:116) at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:262) at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:333) at com.sample.DroolsTest.readRule(DroolsTest.java:33) at com.sample.DroolsTest.main(DroolsTest.java:20) -- 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: (JBCACHE-1020) Upgrade to JGroups 2.5.BETA2

by Manik Surtani (JIRA)

Upgrade to JGroups 2.5.BETA2 ---------------------------- Key: JBCACHE-1020 URL: http://jira.jboss.com/jira/browse/JBCACHE-1020 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Replication Affects Versions: 2.0.0.BETA2 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.CR1, 2.0.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

18 years, 12 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-886) Upgrading from JGroups 2.2.9.2 to JGroups 2.4

by Galder Zamarreno (JIRA)

Upgrading from JGroups 2.2.9.2 to JGroups 2.4 --------------------------------------------- Key: JBCACHE-886 URL: http://jira.jboss.com/jira/browse/JBCACHE-886 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 1.4.0.SP1 Reporter: Galder Zamarreno Assigned To: Manik Surtani Fix For: 1.4.1.GA, 2.0.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

18 years, 12 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-857) Upgrade to JBoss AOP 2.0.ALPHA2

by Ben Wang (JIRA)

Upgrade to JBoss AOP 2.0.ALPHA2 ------------------------------- Key: JBCACHE-857 URL: http://jira.jboss.com/jira/browse/JBCACHE-857 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0.GA Temporarily upgrade to 2.0.ALPHA2 for the alpha release such tat we can continue integration into AS5.0 -- 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, 12 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-884) Upgrade to JGroups 2.5

by Manik Surtani (JIRA)

Upgrade to JGroups 2.5 ---------------------- Key: JBCACHE-884 URL: http://jira.jboss.com/jira/browse/JBCACHE-884 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Replication Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 1.4.1.GA, 2.0.0.ALPHA2, 2.0.0.GA As a part of this, rely on JGroups ANYCAST (JBCACHE-813) properly, and yank out JBCACHE-813 kludge. -- 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, 12 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-967) Upgrade to JGroups 2.4.SP1

by Manik Surtani (JIRA)

Upgrade to JGroups 2.4.SP1 -------------------------- Key: JBCACHE-967 URL: http://jira.jboss.com/jira/browse/JBCACHE-967 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Replication Affects Versions: 2.0.0.BETA1 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.BETA2, 2.0.0.GA This fixes MUX/State transfer test failures present with 2.4.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

18 years, 12 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-853) CacheJmxWrapper should implement NotificationBroadcaster

by Brian Stansberry (JIRA)

CacheJmxWrapper should implement NotificationBroadcaster -------------------------------------------------------- Key: JBCACHE-853 URL: http://jira.jboss.com/jira/browse/JBCACHE-853 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.0.0.GA We need to clarify responsibility for this between the top level JMX wrapper beans and CacheMgmtInterceptor. -- 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, 12 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1149) FIFOPolicy is adding a visited node to the evictionqueue

by Maddulety Vankadara (JIRA)

FIFOPolicy is adding a visited node to the evictionqueue -------------------------------------------------------- Key: JBCACHE-1149 URL: http://jira.jboss.com/jira/browse/JBCACHE-1149 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 2.0.0.CR2 Environment: OS: WIn XP SP2; JBOSS AS: 4.0.3; Cache : 2.0.0CR2 Reporter: Maddulety Vankadara Assigned To: Manik Surtani Created Eviction Policy with the following config: <attribute name="EvictionPolicyConfig"> <config> <attribute name="wakeUpIntervalSeconds">30</attribute> <attribute name="eventQueueSize">200000</attribute>  <region name="/_default_" policyClass="org.jboss.cache.eviction.FIFOPolicy"> <attribute name="maxNodes">500</attribute> </region> </config> </attribute> And then created a region programmatically and assigned FIFOPolicy to that region. FIFOConfiguration evictionConfig = new FIFOConfiguration(); evictionConfig.setMaxNodes(CacheConstants.60); Region rn = getCache().getRegion(Fqn.fromString("\a\b\c"), true); rn.setEvictionPolicy(evictionConfig); Add some nodes under "/a/b/c". All nodes are added to the evictionqueue properly. But when I traverse the region /a/b/c, This node is also added to the evictionqueue and when the queue reaches the limit "MAXNodes"( which is 60 here), the node /a/b/c is evicted from cache. I think a visted node should not be evicted in a FIFO policy. After going through the code, I noticed that VISIT_NODE_EVENT is not ignored in the FIFOPolicy class. Overriding the bemow method in org.jboss.cache.eviction.FIFOPolicy will fix the issue: public boolean canIgnoreEvent(Fqn fqn, NodeEventType eventType) { return (eventType == NodeEventType.VISIT_NODE_EVENT); } -- 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, 12 months

2
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails

by Ben Wang (JIRA)

CacheLoader passivation/activation produces recursive exception when loader.remove fails ---------------------------------------------------------------------------------------- Key: JBCACHE-710 URL: http://jira.jboss.com/jira/browse/JBCACHE-710 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0 Reporter: Ben Wang Assigned To: Manik Surtani Priority: Critical Fix For: 2.0.0 I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened: In ActivationInterceptor.java, we have: if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) { if (n.hasChildren()) { if (allInitialized(n)) { log.debug("children all initialized"); remove(fqn); } } else if (loaderNoChildren(fqn)) { log.debug("no children " + n); remove(fqn); } } } } return retval; } private void remove(Fqn fqn) throws Exception { loader.remove(fqn); cache.notifyNodeActivate(fqn, false); if (cache.getUseInterceptorMbeans()&& statsEnabled) m_activations++; } problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve the node value, e.g., cache.get(fqn, key) to process some logic, then get(fqn, key) will come back to ActivationInterceptor and attempt another .remove() and therefore the recursion. A proposed fix is we should throw exception when removing the node fails in CacheLoader (I am using FileCacheLoader), e.g., DataNotRemovedException. That way, ActivationInterceptor can catch it here and skip event notification (since it won't be valid anyway). -- 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, 12 months

4
10
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 July 2007