March 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1458) illegal access error in consequence

by Godmar Back (JIRA)

illegal access error in consequence ----------------------------------- Key: JBRULES-1458 URL: http://jira.jboss.com/jira/browse/JBRULES-1458 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.4 Reporter: Godmar Back This test: package test; import java.util.Collections; dialect "mvel" rule "Rule #1" when then insert(Collections.singletonMap("content", "hello")); end fails with: org.mvel.PropertyAccessException: unable to resolve property: drools.insert(Collections.singletonMap("content", "hello")) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:276) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:107) at org.mvel.ast.VariableDeepPropertyNode.getReducedValueAccelerated(VariableDeepPropertyNode.java:32) at org.mvel.ast.PropertyASTNode.initializePropertyNode(PropertyASTNode.java:71) at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:23) at org.mvel.MVELRuntime.execute(MVELRuntime.java:88) at org.mvel.CompiledExpression.getValue(CompiledExpression.java:107) at org.mvel.MVEL.executeExpression(MVEL.java:223) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:47) 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.libx.autodetect.DroolsDriver$Host.fireAllRules(DroolsDriver.java:63) at org.libx.autodetect.DroolsDriver.main(DroolsDriver.java:135) 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:597) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:588) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:257) ... 14 more Caused by: java.lang.IllegalAccessError: class org.drools.shadow.java.util.Collections$SingletonMapShadowProxy cannot access its superclass java.util.Collections$SingletonMap at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60) at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.drools.reteoo.Rete$ClassObjectTypeConf.loadOrGenerateProxy(Rete.java:547) at org.drools.reteoo.Rete$ClassObjectTypeConf.defineShadowProxyData(Rete.java:494) at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:461) at org.drools.reteoo.Rete.assertObject(Rete.java:152) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:192) at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:71) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:909) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:881) at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:67) at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:61) ... 20 more Exception in thread "main" org.drools.spi.ConsequenceException: org.mvel.PropertyAccessException: unable to resolve property: drools.insert(Collections.singletonMap("content", "hello")) 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.libx.autodetect.DroolsDriver$Host.fireAllRules(DroolsDriver.java:63) at org.libx.autodetect.DroolsDriver.main(DroolsDriver.java:135) Caused by: org.mvel.PropertyAccessException: unable to resolve property: drools.insert(Collections.singletonMap("content", "hello")) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:276) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:107) at org.mvel.ast.VariableDeepPropertyNode.getReducedValueAccelerated(VariableDeepPropertyNode.java:32) at org.mvel.ast.PropertyASTNode.initializePropertyNode(PropertyASTNode.java:71) at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:23) at org.mvel.MVELRuntime.execute(MVELRuntime.java:88) at org.mvel.CompiledExpression.getValue(CompiledExpression.java:107) at org.mvel.MVEL.executeExpression(MVEL.java:223) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:47) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550) ... 5 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:597) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:588) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:257) ... 14 more Caused by: java.lang.IllegalAccessError: class org.drools.shadow.java.util.Collections$SingletonMapShadowProxy cannot access its superclass java.util.Collections$SingletonMap at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60) at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.drools.reteoo.Rete$ClassObjectTypeConf.loadOrGenerateProxy(Rete.java:547) at org.drools.reteoo.Rete$ClassObjectTypeConf.defineShadowProxyData(Rete.java:494) at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:461) at org.drools.reteoo.Rete.assertObject(Rete.java:152) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:192) at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:71) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:909) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:881) at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:67) at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:61) ... 20 more --- I assume this is a bug, since this code works: package test; import java.util.Collections; import java.util.Map; import java.util.HashMap; dialect "mvel" rule "Rule #1" when then m = new HashMap(); m.put("content", "hello"); insert(m); end rule "Rule #2" when s : Map (this["content"] == "hello") then System.out.println("found it: " + s); end which outputs: found it: {content=hello} I note that java.util.Collections.singletonMap is public static. -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1212) Improve performance on JBMExecutor

by Clebert Suconic (JIRA)

Improve performance on JBMExecutor ---------------------------------- Key: JBMESSAGING-1212 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1212 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.4.0.SP3 Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: Stable branch Because of JBMESSAGING-1200 we had to play with classLoader on the executor, and because of that we had to play with Security checks, for classLoader operations. It would be better to not do it on the executor... So I should investigate about setting the classLoader only on createProducer, createConsumer and its respective close methods. I will need to validate this against JCA and the TCK that was failing because of JBMESSAGING-1200 before. -- 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, 2 months

2
7
0 / 0

[JBoss JIRA] Created: (JGRP-709) FC.java was not handling view changes sent down from above

by Gray Watson (JIRA)

FC.java was not handling view changes sent down from above ---------------------------------------------------------- Key: JGRP-709 URL: http://jira.jboss.com/jira/browse/JGRP-709 Project: JGroups Issue Type: Bug Reporter: Gray Watson Assigned To: Bela Ban FC.java only handles view changes from below meaning that it will not work at all with GMS above it. We were worried about large view changes and wanted FC to be able to located below GMS. Ultimately, we wrote our own FC2 after we had additional problems with FC. -- 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, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (JGRP-714) MessageDispatcher log message needs more information

by Gray Watson (JIRA)

MessageDispatcher log message needs more information ---------------------------------------------------- Key: JGRP-714 URL: http://jira.jboss.com/jira/browse/JGRP-714 Project: JGroups Issue Type: Feature Request Affects Versions: 2.6.1 Reporter: Gray Watson Assigned To: Bela Ban Attachments: MessageDispatcher.java Small patch to improve a log message. -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1072) Ejb3TxPolicy does not rollback the transaction in case of an error

by Olaf Fricke (JIRA)

Ejb3TxPolicy does not rollback the transaction in case of an error ------------------------------------------------------------------ Key: EJBTHREE-1072 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1072 Project: EJB 3.0 Issue Type: Bug Affects Versions: HEAD Reporter: Olaf Fricke Priority: Blocker The class Ejb3TxPolicy is used to rollback the transaction in the case of exceptions. According to the ejb 3.0 spec, the transaction is rolled back in case of ApplicationException with rollback() evaluating to true, in case of RuntimeExceptions or in case of EjbException. All other exception will not lead to a rollback on the current transaction. Unfortunately, the same is true in case of errors. If, for example, an AssertionError (or a ClassDefNotFoundError etc.) occurs, the current transaction will be committed and not rolled back. This behaviour is wrong with respect to the ejb 3.0 spec (see for example table 14 on page 360 of ejbcore.pdf) A possible solution would be to wrap the error into a new RuntimeException after handling ApplicationException (in both methods handleExceptionInOurTx and handleInCallerTx): <code> if (t instanceof Error) { t = new RuntimeException(t); } if (!(t instanceof RuntimeException || t instanceof RemoteException)) { throw t; } </code> The wrapping is necessary, because both the EJBException and the EJBTransactionRolledbackException can only handle exceptions, but not errors. -- 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, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1278) Investigate why CacheStoreInterceptor doesn't store state in a cache loader when using Optimistic Locking

by Manik Surtani (JIRA)

Investigate why CacheStoreInterceptor doesn't store state in a cache loader when using Optimistic Locking --------------------------------------------------------------------------------------------------------- Key: JBCACHE-1278 URL: http://jira.jboss.com/jira/browse/JBCACHE-1278 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.0.CR3, 2.0.0.GA Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.CR4, 2.1.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, 2 months

2
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1406) Drools Eclipse plugin 4.0.2 - function causing syntax errors

by Keith Bennett (JIRA)

Drools Eclipse plugin 4.0.2 - function causing syntax errors ------------------------------------------------------------ Key: JBRULES-1406 URL: http://jira.jboss.com/jira/browse/JBRULES-1406 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Eclipse IDE Affects Versions: 4.0.2 Environment: Eclipse 3.2.2, Drools IDE 4.0.2, JRE 1.4 Reporter: Keith Bennett When I try to include functions in any .drl file, I get syntax errors. For example, the following simple .drl file can be referenced: #created on: Jan 4, 2008 package test #list any import classes here. import java.util.Collection; function void yourFunction(String arg) { /* code goes here*/ } rule "Your First Rule" when #conditions then #actions end rule "Your Second Rule" #include attributes such as "salience" here... when #conditions then #actions end For this .drl file, I get the following errors highlighted on each rule in the IDE: The import test.YourFunction.yourFunction cannot be resolved Syntax error, static imports are only available if source level is 5.0 When I remove the function, these errors go away. I have developed .drl files much more complex than this in the past and have incorporated functions using the same syntax. I can't figure out what is wrong after scouring the forums and searching for anyone who has experienced the same thing. -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1427) Can't call static method in 'in' compound restriction

by Alexandre Gattiker (JIRA)

Can't call static method in 'in' compound restriction ----------------------------------------------------- Key: JBRULES-1427 URL: http://jira.jboss.com/jira/browse/JBRULES-1427 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.4 Reporter: Alexandre Gattiker java.lang.UnsupportedOperationException: does not support method call isAllowed(Object object, InternalWorkingMemory workingMemoiry) at org.drools.rule.ReturnValueRestriction.isAllowed(ReturnValueRestriction.java:181) at org.drools.rule.OrCompositeRestriction.isAllowed(OrCompositeRestriction.java:20) at org.drools.rule.MultiRestrictionFieldConstraint.isAllowed(MultiRestrictionFieldConstraint.java:70) at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:132) at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:153) at org.drools.reteoo.Rete.assertObject(Rete.java:175) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:192) at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:71) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:909) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:881) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:682) at com.sample.DroolsTest.main(DroolsTest.java:28) Steps to reproduce: - Create a sample rule project in Eclipse - Add the following rule to Sample.drl: rule "rule1" when $p1:Message( message in ( (new String("A")), (new String("B")) ) ) then System.out.println("foo"); end Same when calling a static method instead of a constructor. -- 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, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1215) InvocationContext.getMethod must return null for lifecycle callback interceptor methods

by Carlo de Wolf (JIRA)

InvocationContext.getMethod must return null for lifecycle callback interceptor methods --------------------------------------------------------------------------------------- Key: EJBTHREE-1215 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1215 Project: EJB 3.0 Issue Type: Bug Components: interceptors Reporter: Carlo de Wolf -- 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, 2 months

1
4
0 / 0

[JBoss JIRA] Commented: (JBCACHE-70) Make JBossCache an XAResource

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-70?page=comments#action_12402418 ] Manik Surtani commented on JBCACHE-70: -------------------------------------- The main driver for making it an XA resource is for us to not have the current workaround, which is to actually commit state in the cache in the afterCompletion() callback. This is actually incorrect since the transaction should have committed at this stage, and this callback is only used to free up resources. So the options are either: 1) Make JBC an XA resource Easy, just implement XA interfaces and leave beforeCompletion() as is, but do afterCompletion() stuff in separate commit() and rollback() callbacks. Also deal with proper lock cleanup if recover() is called (map it to rollback()?) 2) Or try and work on a better 2PC system with Synchronizations? * In beforeCompletion(), do the prepares AND commits, but HOLD ON to the locks. * In afterCompletion() broadcast a cleanup call to release locks. * Need to think about this because if afterCompletion() this fails we may end up with stale locks. The "usual" reason for wanting to make something an XA resource - i.e., to handle recovery - doesn't apply to JBC since the state can never be recovered as the cache is in memory. The best that can be done is for the state to be removed, i.e., cleaned up. > Make JBossCache an XAResource > ----------------------------- > > Key: JBCACHE-70 > URL: http://jira.jboss.com/jira/browse/JBCACHE-70 > Project: JBoss Cache > Issue Type: Feature Request > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 3.2.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, 2 months

1
0
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 March 2008