May 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5381) Convert JBossCacheManager to use CacheManager

by Brian Stansberry (JIRA)

Convert JBossCacheManager to use CacheManager --------------------------------------------- Key: JBAS-5381 URL: http://jira.jboss.com/jira/browse/JBAS-5381 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 Configure JBossWebMetaData with JNDI name of CacheManager and name of cache config (hooks are already there). Find manager in JNDI instead of JMX; get the cache from the manager. Investigate a way to pass the manager directly instead of using JNDI. Perhaps as an attachment to JBossWebMetaData? ClusteringDefaultsDeployer will have two default config names -- one for replication-granularity FIELD and one for not. No more needing to start a whole separate set of servers to test FIELD. :-) -- 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, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5379) Bind cache manager in JNDI

by Brian Stansberry (JIRA)

Bind cache manager in JNDI -------------------------- Key: JBAS-5379 URL: http://jira.jboss.com/jira/browse/JBAS-5379 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 The Hibernate RegionFactory impl I plan to use by default for EJB3 looks for its CacheManager in JNDI. So, the AS cache manager needs to be in JNDI. Once there I will convert the other cache usages to either have the manager dependency injected or to get it via JNDI. No more JMX lookups. -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5500) Convert HAPartition to use CacheManager

by Brian Stansberry (JIRA)

Convert HAPartition to use CacheManager --------------------------------------- Key: JBAS-5500 URL: http://jira.jboss.com/jira/browse/JBAS-5500 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 Get the cache for DistributedState and HA-JNDI from the CacheManager. -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1443) retract of Fact Template leads to NPE

by greywind (JIRA)

retract of Fact Template leads to NPE ------------------------------------- Key: JBRULES-1443 URL: http://jira.jboss.com/jira/browse/JBRULES-1443 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: greywind If a Fact that is based on a template gets retracted the following NPE occurs java.lang.NullPointerException at org.drools.reteoo.Rete.retractObject(Rete.java:204) at org.drools.reteoo.ReteooRuleBase.retractObject(ReteooRuleBase.java:211) at org.drools.reteoo.ReteooWorkingMemory.doRetract(ReteooWorkingMemory.java:79) at org.drools.common.AbstractWorkingMemory.retract(AbstractWorkingMemory.java:1022) at org.drools.common.TruthMaintenanceSystem$LogicalRetractCallback.execute(TruthMaintenanceSystem.java:150) at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1315) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:914) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:881) at org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:81) at org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:75) at org.drools.entity.Rule_Check_Dups_0.consequence(Rule_Check_Dups_0.java:12) at org.drools.entity.Rule_Check_Dups_0ConsequenceInvoker.evaluate(Rule_Check_Dups_0ConsequenceInvoker.java:22) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433) at org.drools.entity.EntityTest.main(EntityTest.java:307) Exception in thread "main" org.drools.spi.ConsequenceException: java.lang.NullPointerException at org.drools.base.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:14) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:554) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433) at org.drools.entity.EntityTest.main(EntityTest.java:307) Caused by: java.lang.NullPointerException at org.drools.reteoo.Rete.retractObject(Rete.java:204) at org.drools.reteoo.ReteooRuleBase.retractObject(ReteooRuleBase.java:211) at org.drools.reteoo.ReteooWorkingMemory.doRetract(ReteooWorkingMemory.java:79) at org.drools.common.AbstractWorkingMemory.retract(AbstractWorkingMemory.java:1022) at org.drools.common.TruthMaintenanceSystem$LogicalRetractCallback.execute(TruthMaintenanceSystem.java:150) at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1315) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:914) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:881) at org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:81) at org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:75) at org.drools.entity.Rule_Check_Dups_0.consequence(Rule_Check_Dups_0.java:12) at org.drools.entity.Rule_Check_Dups_0ConsequenceInvoker.evaluate(Rule_Check_Dups_0ConsequenceInvoker.java:22) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550) ... 4 more -- 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, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1442) Cannot create template Fact in RHS

by greywind (JIRA)

Cannot create template Fact in RHS ---------------------------------- Key: JBRULES-1442 URL: http://jira.jboss.com/jira/browse/JBRULES-1442 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.4 Reporter: greywind The following drl should work if i'm not mistaken template DuplicateIdentifier Identifier identifier; end rule "" when then insert (new DuplicateIdentifier()); end but it leads to Error: Rule Compilation error DuplicateIdentifier cannot be resolved to a type Exception in thread "main" org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name=, agendaGroup=MAIN, salience=0, no-loop=false] org/drools/entity/Rule__0.java (8:294) : DuplicateIdentifier cannot be resolved to a type -- 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, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1438) FactTemplate Property Access leads to RuleBuilder Exception

by greywind (JIRA)

FactTemplate Property Access leads to RuleBuilder Exception ----------------------------------------------------------- Key: JBRULES-1438 URL: http://jira.jboss.com/jira/browse/JBRULES-1438 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.4 Reporter: greywind Attachments: EntityTest.drl The only thing I do is to add the attached drl to a Package and do get the following exception: Exception in thread "main" org.mvel.CompileException: problem encountered at node [19] 5{1012,1042}: unable to resolve property: could not access property at org.mvel.TemplateInterpreter.execute(TemplateInterpreter.java:554) at org.mvel.TemplateInterpreter.parse(TemplateInterpreter.java:338) at org.drools.rule.builder.dialect.java.AbstractJavaBuilder.generatTemplates(AbstractJavaBuilder.java:120) at org.drools.rule.builder.dialect.java.JavaConsequenceBuilder.build(JavaConsequenceBuilder.java:118) at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:67) at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:446) at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:304) at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:167) at org.drools.entity.EntityTest.main(EntityTest.java:48) Caused by: org.mvel.PropertyAccessException: unable to resolve property: could not access property at org.mvel.PropertyAccessor.get(PropertyAccessor.java:170) at org.mvel.PropertyAccessor.get(PropertyAccessor.java:128) at org.mvel.ASTNode.getReducedValue(ASTNode.java:247) at org.mvel.ast.PropertyASTNode.getReducedValue(PropertyASTNode.java:36) at org.mvel.MVELInterpretedRuntime.parseAndExecuteInterpreted(MVELInterpretedRuntime.java:115) at org.mvel.MVELInterpretedRuntime.parse(MVELInterpretedRuntime.java:63) at org.mvel.TemplateInterpreter.execute(TemplateInterpreter.java:409) ... 8 more Caused by: java.lang.reflect.InvocationTargetException 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.mvel.PropertyAccessor.getBeanProperty(PropertyAccessor.java:419) at org.mvel.PropertyAccessor.get(PropertyAccessor.java:153) ... 14 more Caused by: org.drools.RuntimeDroolsException: This is a bug. Please report to development team: org.drools.facttemplates.FactTemplateFieldExtractor.getValue(java.lang.Object) at org.drools.facttemplates.FactTemplateFieldExtractor.getNativeReadMethod(FactTemplateFieldExtractor.java:82) at org.drools.rule.Declaration.getNativeReadMethod(Declaration.java:291) ... 20 more Caused by: java.lang.NoSuchMethodException: org.drools.facttemplates.FactTemplateFieldExtractor.getValue(java.lang.Object) at java.lang.Class.getDeclaredMethod(Class.java:1909) at org.drools.facttemplates.FactTemplateFieldExtractor.getNativeReadMethod(FactTemplateFieldExtractor.java:79) ... 21 more When I select dialect 'mvel' it does work however! -- 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, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-1543) tests failing with JANINO

by Aleksandar Kostadinov (JIRA)

tests failing with JANINO ------------------------- Key: JBRULES-1543 URL: http://jira.jboss.com/jira/browse/JBRULES-1543 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Aleksandar Kostadinov Assigned To: Mark Proctor Test suite of http://anonsvn.labs.jboss.com/labs/jbossrules/tags/DROOLS_SOA_4_2_19342_CP1 is failing when run with JANINO (mvn install -Ddrools.dialect.java.compiler=JANINO). -- 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, 8 months

3
7
0 / 0

[JBoss JIRA] Created: (JBRULES-1351) Rules not firing in heavely threaded application

by paata lominadze (JIRA)

Rules not firing in heavely threaded application ------------------------------------------------ Key: JBRULES-1351 URL: http://jira.jboss.com/jira/browse/JBRULES-1351 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3, 4.0.2 Reporter: paata lominadze Server application loads precompiled rule package into memory then it creates as many rulebases as much threads are there. (every thread has its own rulebase and stateless session) application receives messages, then it dispatches it to one of the threads. thread itself executes rules on its own stateless session. rules are written such a way so that at least one rule should fire. but sometimes rules don't fire. in such situations we are passing same facts to rules engine second time, on the same rulebase, using same stateless session. this time one rule is selected. facts are not modified during two runs. they also dont change from rules. this makes us to think that the bug is in rules engine, not in the application rule design logic. going from stateless to stateful session didnot solve this problem fact shadowing is disabled rules have unique salience. all rules belong to same activation group. we had one rulebase for all the threads and were creating one stateless session per thread. but "misfiring" did happen much often this way. giving each thread its own rulebase reduced "misfirings" dramatically this bug started to appear after upgrading from 3.0.5 to 4.0.x, currently we are using 4.0.3 i think this problem has same roots as this bug: http://jira.jboss.org/jira/browse/JBRULES-1330 -- 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, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-1512) UnsupportedOperationException when calling addPackage on rulebase

by Mattias Nilsson (JIRA)

UnsupportedOperationException when calling addPackage on rulebase ----------------------------------------------------------------- Key: JBRULES-1512 URL: http://jira.jboss.com/jira/browse/JBRULES-1512 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.4 Reporter: Mattias Nilsson Assigned To: Mark Proctor Priority: Minor Attachments: global-test.zip While migrating from Drools 3.0.6 to 4.0.4 a customer of ours found a bug. If you load two DRL files with same package declaration using two package builders into one rulebase, and only the second DRL file contains globals, the rulebase will throw an exception when loading the second package. This used to work in 3.0.6 but fails in 4.0.4. The following exception is thrown: java.lang.UnsupportedOperationException at java.util.AbstractMap.put(AbstractMap.java:228) at java.util.AbstractMap.putAll(AbstractMap.java:317) at org.drools.common.AbstractRuleBase.mergePackage(AbstractRuleBase.java:495) at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:399) I will upload an example that reproduces 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

17 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-867) Can't load classes from expanded class dir on windows

by Dan Lipofsky (JIRA)

Can't load classes from expanded class dir on windows ----------------------------------------------------- Key: JBRULES-867 URL: http://jira.jboss.com/jira/browse/JBRULES-867 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.0.6 Environment: Windows XP SP2 (problem not reproducable on Linux), JDK 1.5.0_11-b03, Ant 1.7.0, Eclipse 3.2.2 Reporter: Dan Lipofsky Assigned To: Mark Proctor Priority: Minor When running some JUnit tests of our rules from an Ant task or from Eclipse, we got the following rule compile errors: org.drools.rule.InvalidRulePackage: Rule Compilation error The import com.bricsnet.core.util.constants cannot be resolved UserGroup cannot be resolved The same rules compile perfectly on the server. On the server the class is question is only available from a JAR file. In Eclipse it in an expanded class dir. In the Ant task both the expanded class dir and the JAR file were in the classpath, but the expanded class dir was first. Putting the JAR first on the classpath solved the problem for the ant task (but this is not possible for eclipse since the JAR is not available). Therefore we believe the problem is specifically related to loading from an expanded class dir. The problem seems to occur on Windows but not Linux. Finally the problem only seems to occur for some classes. All 3 of the classes in the sample rule file below are in the same boat, but for some reason only UserGroup is a problem (it might be the Example 1 (fails): package com.foobar.rules; import com.foobar.core.util.constants.UserGroup; import com.foobar.core.util.security.principal.UserPrincipal; import com.foobar.core.util.security.auth.RuleAuthorization; rule "test_rule" when r: RuleAuthorization() u: UserPrincipal() eval(u.hasGroup(123)) then r.setLevel(RuleAuthorization.READ); end Example 2 (works): package com.foobar.rules; import com.foobar.core.util.security.principal.UserPrincipal; import com.foobar.core.util.security.auth.RuleAuthorization; rule "test_rule" when r: RuleAuthorization() u: UserPrincipal() eval(u.hasGroup(123)) then r.setLevel(RuleAuthorization.READ); end -- 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, 8 months

5
6
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 May 2008