[JBoss JIRA] Created: (JBRULES-2481) Unable to reference globals in object constructors on RHS of rule
by Chris DeLashmutt (JIRA)
Unable to reference globals in object constructors on RHS of rule
-----------------------------------------------------------------
Key: JBRULES-2481
URL: https://jira.jboss.org/jira/browse/JBRULES-2481
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.1.0.M1, 5.0.1.FINAL
Environment: Windows 7, Sun JDK 1.6.0_17
Reporter: Chris DeLashmutt
Assignee: Mark Proctor
After migrating to Drools 5, it seems that you can't reference globals in object constructors on the RHS of a rule. Here is my DRL:
package test.rules
#list any import classes here.
import test.domain.Field;
#declare any global variables here
global test.service.CalendarManager calendarManager;
dialect "mvel"
rule "FieldRuleTest.todayField"
when
then
new Field("todayField",calendarManager.getToday())
end
After reading this DRL with PackageBuilder, creating a StatefulSession from the resulting rulebase, setting the global, and then executing fireAllRules, I get the following exception:
org.drools.runtime.rule.ConsequenceException: [Error: unable to access property (null parent): calendarManager]
[Near : {... Unknown ....}]
^
[Line: 1, Column: 0]
at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:23)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:980)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:917)
at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1126)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:697)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:663)
at test.MvelBindingProblemTest.mvelBindingTestFailure(MvelBindingProblemTest.java:40)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: [Error: unable to access property (null parent): calendarManager]
[Near : {... Unknown ....}]
^
[Line: 1, Column: 0]
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:860)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:584)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:312)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:138)
at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:133)
at org.mvel2.compiler.ExecutableAccessor.getValue(ExecutableAccessor.java:41)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileConstructor(ReflectiveAccessorOptimizer.java:1090)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeObjectCreation(ReflectiveAccessorOptimizer.java:1047)
at org.mvel2.ast.NewObjectNode.getReducedValueAccelerated(NewObjectNode.java:158)
at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:104)
at org.mvel2.MVEL.executeExpression(MVEL.java:995)
at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:87)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:971)
... 27 more
Attached is a project with a failing test case for this issue.
If I simply add a silly reference to the global to the DRL as follows, everything works:
rule "FieldRuleTest.todayField"
when
then
stupidLocalVariable = calendarManager
new Field("todayField",calendarManager.getToday())
end
--
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
14 years
[JBoss JIRA] Created: (EJBTHREE-2094) Unmarshalling of param fails with ClassNotFoundException during invocation on a Singleton bean packaged in an isolated deployment
by jaikiran pai (JIRA)
Unmarshalling of param fails with ClassNotFoundException during invocation on a Singleton bean packaged in an isolated deployment
---------------------------------------------------------------------------------------------------------------------------------
Key: EJBTHREE-2094
URL: https://jira.jboss.org/browse/EJBTHREE-2094
Project: EJB 3.0
Issue Type: Bug
Components: singleton
Affects Versions: EJB3_1 1.0.7
Reporter: jaikiran pai
Assignee: jaikiran pai
Invocation on a simple singleton bean:
public class SomeSingletonBean
{
public void doSomething(SomeCustomClass param)
{
...
}
}
fails with ClassNotFoundException for SomeCustomClass like below:
java.lang.RuntimeException: java.lang.ClassNotFoundException: de.xxx.persistence.entity.core.Company (no security manager: RMI class loader disabled)
at org.jboss.aop.joinpoint.MethodInvocation.getArguments(MethodInvocation.java:318)
at org.jboss.ejb3.singleton.aop.impl.AOPBasedSingletonContainer.dynamicInvoke(AOPBasedSingletonContainer.java:331)
at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897)
at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:768)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:721)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:548)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234)
Caused by: java.lang.ClassNotFoundException: de.xxx.persistence.entity.core.Company (no security manager: RMI class loader disabled)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:375)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
at org.jboss.system.JBossRMIClassLoader.loadClass(JBossRMIClassLoader.java:91)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at java.rmi.MarshalledObject.get(MarshalledObject.java:142)
at org.jboss.aop.joinpoint.MethodInvocation.getArguments(MethodInvocation.java:309)
at org.jboss.ejb3.singleton.aop.impl.AOPBasedSingletonContainer.dynamicInvoke(AOPBasedSingletonContainer.java:331)
at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897)
at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:768)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:721)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:548)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:213)
at org.jboss.remoting.Client.invoke(Client.java:1927)
at org.jboss.remoting.Client.invoke(Client.java:770)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
at $Proxy6.invoke(Unknown Source)
at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:188)
at $Proxy5.get(Unknown Source)
at de.xxx.test.CoreServicesRemoteTest.testCompanyCreate(CoreServicesRemoteTest.java:39)
at de.xxx.test.CoreServicesRemoteTest.main(CoreServicesRemoteTest.java:50)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
at $Proxy6.invoke(Unknown Source)
at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:188)
at $Proxy5.get(Unknown Source)
at de.xxx.test.CoreServicesRemoteTest.testCompanyCreate(CoreServicesRemoteTest.java:39)
at de.xxx.test.CoreServicesRemoteTest.main(CoreServicesRemoteTest.java:50)
This is because, during unmarshalling, the AOPSingletonBasedContainer.dynamicInvoke does not use the container's classloader.
See the referenced forum thread for details.
--
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
14 years
[JBoss JIRA] Created: (JBAS-8032) EJB dependency on another EJB from the same EJB-JAR
by Alexey Loubyansky (JIRA)
EJB dependency on another EJB from the same EJB-JAR
---------------------------------------------------
Key: JBAS-8032
URL: https://jira.jboss.org/browse/JBAS-8032
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB2
Affects Versions: 6.0.0.M3, JBossAS-5.1.0.GA
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Fix For: 6.0.0.M4
The following is failing to deploy
<jboss>
<enterprise-beans>
<session>
<ejb-name>MySession</ejb-name>
<depends>jboss.j2ee:jndiName=MySession2,service=EJB</depends>
</session>
<session>
<ejb-name>MySession2</ejb-name>
<depends>jboss.j2ee:jndiName=MySession3,service=EJB</depends>
</session>
</enterprise-beans>
</jboss>
with the exception
21:09:14,425 WARN [org.jboss.deployment.MainDeployer] Failed to deploy: file:/XXXX/jbossas/trunk/testsuite/output/lib/ejbdepe
nds.ear: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
DEPLOYMENTS MISSING DEPENDENCIES:
Deployment "jboss.j2ee:ear="ejbdepends.ear",module="ejbdepends1.jar",service=EjbModule" is missing the following dependencies:
Dependency "jboss.j2ee:jndiName=MySession2,service=EJB" (should be in state "Create", but is actually in state "** NOT FOUND Depends on 'jboss.j2e
e:jndiName=MySession2,service=EJB' **")
DEPLOYMENTS IN ERROR:
Deployment "jboss.j2ee:jndiName=MySession2,service=EJB" is in error due to the following reason(s): ** NOT FOUND Depends on 'jboss.j2ee:jndiName=MyS
ession2,service=EJB' **
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1395) [:2.2.0.Alpha4]
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1341) [:2.2.0.Alpha4]
at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:968) [:2.2.0.Alpha4]
at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:957) [:2.2.0.Alpha4]
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) [:6.0.0-SNAPSHOT]
at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:277) [:6.0.0-SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_13]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_13]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_13]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_13]
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.Beta5]
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.Beta5]
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.Beta5]
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.Beta5]
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.Beta5]
at org.jboss.system.server.jmx.MBeanServerWrapper.invoke(MBeanServerWrapper.java:138) [:6.0.0-SNAPSHOT (Build SVNTag:JBoss_6.0.0-SNAPSHOT date
: 20100517)]
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1426) [:1.6.0_13]
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) [:1.6.0_13]
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1264) [:1.6.0_13]
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1359) [:1.6.0_13]
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) [:1.6.0_13]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_13]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_13]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_13]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_13]
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) [:1.6.0_13]
at sun.rmi.transport.Transport$1.run(Transport.java:159) [:1.6.0_13]
at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_13]
at sun.rmi.transport.Transport.serviceCall(Transport.java:155) [:1.6.0_13]
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) [:1.6.0_13]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) [:1.6.0_13]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) [:1.6.0_13]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_13]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_13]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_13]
--
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
14 years
[JBoss JIRA] Created: (JBRULES-2512) MatchesConstraint and NotMatchesConstraint create inverse verifier rules.
by Esteban Aliverti (JIRA)
MatchesConstraint and NotMatchesConstraint create inverse verifier rules.
-------------------------------------------------------------------------
Key: JBRULES-2512
URL: https://jira.jboss.org/browse/JBRULES-2512
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Esteban Aliverti
Assignee: Mark Proctor
Priority: Minor
When creating a MatchesConstraint for a Field, verifier should fails when the Fails doesn't match the pattern. Right now it is working in the opposite way.
Same happens with NotMatchesConstraint.
i.e. Here is a part of the verifier rule Generated by NotMatchesConstraint when I defined a Constraint dictating: 'Person's name should not matches "^[A-Z].*$"'
$restriction :LiteralRestriction(
fieldPath == $field.path,
valueAsString not matches "^[A-Z].*$"
)
Because I want verifier to fail when the name doesn't matches "^[A-Z].*$", the generated verifier rule should be: valueAsString matches "^[A-Z].*$"
--
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
14 years