[JBoss JIRA] (JBRULES-3556) Support mappings between trait and core class fields
by Davide Sottara (JIRA)
Davide Sottara created JBRULES-3556:
---------------------------------------
Summary: Support mappings between trait and core class fields
Key: JBRULES-3556
URL: https://issues.jboss.org/browse/JBRULES-3556
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-compiler, drools-core
Affects Versions: 5.4.0.Final
Reporter: Davide Sottara
Assignee: Davide Sottara
Priority: Minor
Fix For: 5.5.0.Beta1
Trait - Core field mapping requires the fields to have the same name and compatible types. Whenever the names cannot be the same, e.g. due to interface naming requirements, it could be desirable to define a custom mapping:
declare trait X
tfield : String @Alias("cField")
end
declare Y
cField : String
end
Here, tField should be mapped onto the hard field cField, even if the names are different
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (JBRULES-3521) accumulation function ignores conditions in 5.4.0.Final
by Radai Rosenblatt (JIRA)
Radai Rosenblatt created JBRULES-3521:
-----------------------------------------
Summary: accumulation function ignores conditions in 5.4.0.Final
Key: JBRULES-3521
URL: https://issues.jboss.org/browse/JBRULES-3521
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler (fusion)
Affects Versions: 5.4.0.Final
Environment: windows 7 x64, tested with jdk 6 and 7
Reporter: Radai Rosenblatt
Assignee: Mark Proctor
Attachments: accumulationBug.zip
given this drl:
package playground
import playground.datamodel.EventObject
declare EventObject
@role( event )
end
rule "new event under average"
when
$latestEvent : EventObject(level == "Full", status == "success", $size : size ) from entry-point "Event Stream"
Number($averageSize : doubleValue, doubleValue > ($size)) from accumulate( EventObject(level=="Full", this before $latestEvent, status == "success", $bSize : size ) over window:time( 5d ) from entry-point "Event Stream" , average($bSize))
then
System.err.println("new event under 5d average");
end
and the following sequence of 3 events:
{Full,success,100},{Whatever,fail,0},{Full,success,99}
the 3rd event should trigger a firing. the complete breakdown of events should be as follows:
1. 1st event is inserted, average is 0 because there are no previous events - no firing.
2. 2nd event is inserted - does not match the conditions and therefore should not be accumulated.
3. 3rd event is inserted - accumulation should only consider the 1st event, hence the avg. is 100. the event value is 99, which is below the avg - rule should fire.
this works with drools 5.1.1 but fails in 5.4.0.Final - in 5.4 the 2nd event is acounted by the average function and so the rule does not fire.
attached is a complete maven project to recreate this bug - simply unzip and run "mvn clean install" to recreate.
also in the mvn project attached, simply change the drools.version property in the pom.xml from 5.4.0.Final to 5.1.1 (already in there, just commented out) to verify this works in 5.1.1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (AS7-4854) Failures on clustered remote EJB invocations in event of server shutting down using DIST SYNC cache (NullPointerException: Null keys are not supported!)
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4854:
-----------------------------------
Summary: Failures on clustered remote EJB invocations in event of server shutting down using DIST SYNC cache (NullPointerException: Null keys are not supported!)
Key: AS7-4854
URL: https://issues.jboss.org/browse/AS7-4854
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.1.2.Final (EAP)
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.3.Final (EAP)
Remote client is up, but one server shuts down, results at first in
{noformat}
2012/05/21 12:09:33:112 EDT [WARN ][Runner - 177] SFCORE_LOG - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not lookup session bean.>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not lookup session bean.
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:157)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:58)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.naming.NamingException: Failed to create proxy [Root exception is java.lang.RuntimeException: java.io.IOException: Channel Channel ID 8907f2dd (outbound) of Remoting connection 7821f46a to perf18/10.16.90.54:4447 has been closed]
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:115)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:96)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:148)
... 4 more
Caused by: java.lang.RuntimeException: java.io.IOException: Channel Channel ID 8907f2dd (outbound) of Remoting connection 7821f46a to perf18/10.16.90.54:4447 has been closed
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:247)
at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:163)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:135)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:113)
... 7 more
Caused by: java.io.IOException: Channel Channel ID 8907f2dd (outbound) of Remoting connection 7821f46a to perf18/10.16.90.54:4447 has been closed
at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:111)
at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:103)
at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:517)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:382)
at org.jboss.remoting3.remote.RemoteConnectionHandler.receiveCloseRequest(RemoteConnectionHandler.java:205)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:106)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
{noformat}
and on later failures on NullPointerException: Null keys are not supported!
{noformat}
2012/05/21 12:11:41:077 EDT [WARN ][Runner - 7] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not lookup session bean.>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not lookup session bean.
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:157)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:58)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.naming.NamingException: Failed to create proxy [Root exception is java.lang.RuntimeException: java.lang.NullPointerException: Null keys are not supported!]
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:115)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:96)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:148)
... 4 more
Caused by: java.lang.RuntimeException: java.lang.NullPointerException: Null keys are not supported!
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:247)
at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:163)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:135)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:113)
... 7 more
Caused by: java.lang.NullPointerException: Null keys are not supported!
at org.infinispan.CacheImpl.assertKeyNotNull(CacheImpl.java:196)
at org.infinispan.CacheImpl.assertKeyValueNotNull(CacheImpl.java:201)
at org.infinispan.CacheImpl.put(CacheImpl.java:699)
at org.infinispan.DecoratedCache.put(DecoratedCache.java:319)
at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:308)
at org.jboss.as.clustering.ejb3.cache.backing.infinispan.InfinispanBackingCacheEntryStore$1.invoke(InfinispanBackingCacheEntryStore.java:173)
at org.jboss.as.clustering.ejb3.cache.backing.infinispan.InfinispanBackingCacheEntryStore$1.invoke(InfinispanBackingCacheEntryStore.java:170)
at org.jboss.as.clustering.infinispan.invoker.BatchOperation.invoke(BatchOperation.java:19)
at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:60)
at org.jboss.as.clustering.ejb3.cache.backing.infinispan.InfinispanBackingCacheEntryStore.invoke(InfinispanBackingCacheEntryStore.java:239)
at org.jboss.as.clustering.ejb3.cache.backing.infinispan.InfinispanBackingCacheEntryStore.insert(InfinispanBackingCacheEntryStore.java:177)
at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.insert(SerializationGroupMemberContainer.java:304)
at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.insert(SerializationGroupMemberContainer.java:51)
at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.create(PassivatingBackingCacheImpl.java:122)
at org.jboss.as.ejb3.cache.impl.GroupAwareCache.create(GroupAwareCache.java:67)
at org.jboss.as.ejb3.cache.impl.GroupAwareCache.create(GroupAwareCache.java:41)
at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:242)
at org.jboss.as.ejb3.remote.protocol.versionone.SessionOpenRequestHandler$SessionIDGeneratorTask.run(SessionOpenRequestHandler.java:148)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:99)
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:243)
... 10 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBRULES-2700) Allow setting globals for access by the scoring rules
by Wouter Horré (JIRA)
Allow setting globals for access by the scoring rules
-----------------------------------------------------
Key: JBRULES-2700
URL: https://jira.jboss.org/browse/JBRULES-2700
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-planner
Reporter: Wouter Horré
Assignee: Mark Proctor
Currently, it is not possible to set a global variable in the working memory used by the solver. If a scoring rule needs an external helper for calculating scores (e.g. a dependency injected with OSGi DS), a workaround using a static variable in some class accessible by the scoring rules is needed.
The easiest implementation is probably a new method in the Solver interface:
public WorkingMemory getWorkingMemory();
which provides access to the working memory used by the solver.
--
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
13 years, 8 months
[JBoss JIRA] (AS7-5072) value-type not set on ObjectTypeAttributeDefinition
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-5072:
--------------------------------
Summary: value-type not set on ObjectTypeAttributeDefinition
Key: AS7-5072
URL: https://issues.jboss.org/browse/AS7-5072
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Reporter: Jeff Mesnil
Assignee: Tomaz Cerar
I am not able to define an attribute properly and it seems there is a bug with setting value-type on an ObjectTypeAttributionDefinition.
I have a CoreAddressDefinition which defines a runtime read-only attribute "roles". This attribute is a LIST of OBJECT named "role". This OBJECT is composed of a STRING attribute "name" and many BOOLEAN attributes (from the SecurityRoleDefinition).
They are represented by:
private static final AttributeDefinition NAME = create("name", ModelType.STRING)
.build();
private static final ObjectTypeAttributeDefinition ROLE = ObjectTypeAttributeDefinition.Builder.of(CommonAttributes.ROLE, new AttributeDefinition[] { NAME }, SecurityRoleDefinition.ATTRIBUTES)
.build();
static final AttributeDefinition ROLES = ObjectListAttributeDefinition.Builder.of(CommonAttributes.ROLES_ATTR_NAME, ROLE)
.setFlags(AttributeAccess.Flag.STORAGE_RUNTIME)
.build();
After they are registered (using a DefaultResourceDescriptionProvider), the value-type of the OBJECT attribute is not set. I was expecting it to be the concatenation of the various valueTypes I passed to the ROLE attribute.
{
"description" => "A runtime-only resource representing a HornetQ \"address\". Zero or more queues can be bound to a single address. When a message is routed, it is routed to the set of queues bound to the message's address.",
"attributes" => {"roles" => {
"type" => LIST,
"description" => "A list of the security roles (name and permissions) associated with the address.",
"expressions-allowed" => false,
"nillable" => false,
"value-type" => {"role" => {
"type" => OBJECT,
"description" => "A security role associated with the address.",
"expressions-allowed" => false,
"nillable" => false
}}
}},
"operations" => undefined,
"children" => {}
}
I did a dew debugging and one thing that I don't understand is why in ObjectListAttributeDefinition, the 3 implementations of addValueTypeDescription are different and only 1 will check whether the value type corresponds to an OBJECT. Using a DefaultResourceDescriptionProvider I end up using ObjectListAttributeDefinition#addAttributeValueTypeDescription(final ModelNode node, final ResourceDescriptionResolver resolver, final Locale locale, final ResourceBundle bundle) which does *not* set the value-type.
To reproduce this failure, you can run mvn clean install -pl messaging from my branch, all the tests fail because of this one: https://github.com/jmesnil/jboss-as/tree/AS7-4790_ResourceDefinition_conv...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (JBRULES-3539) Error calling clone on object from map on RHS
by Joe Re (JIRA)
Joe Re created JBRULES-3539:
-------------------------------
Summary: Error calling clone on object from map on RHS
Key: JBRULES-3539
URL: https://issues.jboss.org/browse/JBRULES-3539
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Beta1
Environment: java 6. Windows
Reporter: Joe Re
Assignee: Mark Proctor
When calling clone on an object in the RHS of a rule the exception below is thrown. Git pull request with a MiscTest unit test to follow.
Unable to Analyse Expression System.out.println( $valOne.clone() );:
[Error: Failed to compileShared: 1 compilation error(s):
- (1,21) the referenced method is not accessible: java.lang.Object.clone() (scope: protected native; required: public]
[Near : {... System.out.println( $valOne.clone() ); ....}]
^
[Line: 5, Column: 0] : [Rule name='RHSClone']
Error importing : 'com.sample.DroolsTest.Message'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (AS7-4268) Create subsystem for JMS bridge
by Justin Bertram (JIRA)
Justin Bertram created AS7-4268:
-----------------------------------
Summary: Create subsystem for JMS bridge
Key: AS7-4268
URL: https://issues.jboss.org/browse/AS7-4268
Project: Application Server 7
Issue Type: Task
Components: JMS
Affects Versions: 7.1.1.Final
Reporter: Justin Bertram
Assignee: Jeff Mesnil
Currently there is no pre-defined way to deploy a JMS bridge (i.e. org.hornetq.jms.bridge.impl.JMSBridgeImpl) in AS7. In JBoss AS 6 and earlier you could deploy the bridge as an MBean or JBoss MC bean, but the current configuration schema in AS7 simply doesn't support it. The bridge is a nice feature so we need a way to deploy it.
It doesn't make sense to add the JMS bridge to a <hornetq-server> because the bridge can operate independently of a local HornetQ server. It really needs its own subsystem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (JBRULES-3537) JIT crash when throwing RuntimeException
by Willem van Asperen (JIRA)
Willem van Asperen created JBRULES-3537:
-------------------------------------------
Summary: JIT crash when throwing RuntimeException
Key: JBRULES-3537
URL: https://issues.jboss.org/browse/JBRULES-3537
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.4.0.Final
Environment: linux
java version "1.7.0_04-icedtea"
OpenJDK Runtime Environment (IcedTea7 2.2) (ArchLinux build 7.u4_2.2-1-x86_64)
OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode)
Reporter: Willem van Asperen
Assignee: Mark Proctor
There is probably something wrong with my rules. But I get a funny error (see trace below).
This seems to be because the ConditionAnalyzer wants to throw a RuntimeException (line 229):
if (accessor == null) {
throw new RuntimeException("Null accessor on node: " + node);
}
Then the toString of ASTNode node crashes with a NullPointerException at line 427:
public String toString() {
return isOperator() ? "<<" + DebugTools.getOperatorName(getOperator()) + ">>" :
(PCTX_STORED & fields) != 0 ? nameCache : new String(expr, start, offset);
}
This is because the variable expr is null.
Exception in thread "Thread-1" java.lang.NullPointerException
at java.lang.String.<init>(String.java:229)
at org.mvel2.ast.ASTNode.toString(ASTNode.java:426)
at java.lang.String.valueOf(String.java:2902)
at java.lang.StringBuilder.append(StringBuilder.java:128)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:229)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:126)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:102)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCombinedCondition(ConditionAnalyzer.java:133)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:94)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCombinedCondition(ConditionAnalyzer.java:133)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:94)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCombinedCondition(ConditionAnalyzer.java:133)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:94)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCombinedCondition(ConditionAnalyzer.java:133)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:94)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCombinedCondition(ConditionAnalyzer.java:133)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:94)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCombinedCondition(ConditionAnalyzer.java:133)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:94)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:73)
at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:214)
at org.drools.rule.constraint.MvelConstraint.access$000(MvelConstraint.java:41)
at org.drools.rule.constraint.MvelConstraint$1.run(MvelConstraint.java:201)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months