[JBoss JIRA] (SECURITY-849) LdapExtLoginModule fails when role* options not specified
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-849?page=com.atlassian.jira.plug... ]
Darran Lofthouse moved WFLY-3665 to SECURITY-849:
-------------------------------------------------
Project: PicketBox (was: WildFly)
Key: SECURITY-849 (was: WFLY-3665)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Affects Version/s: PicketBox_4_0_19.SP5
(was: 8.0.0.Final)
Component/s: PicketBox
(was: Security)
Security: Public (was: Public)
> LdapExtLoginModule fails when role* options not specified
> ---------------------------------------------------------
>
> Key: SECURITY-849
> URL: https://issues.jboss.org/browse/SECURITY-849
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: PicketBox
> Affects Versions: PicketBox_4_0_19.SP5
> Reporter: Jess Holle
> Assignee: Darran Lofthouse
>
> If one does not specify role* options on this login module (i.e. does not specify rolesCtxDN, roleFilter, roleAttributeID, etc), then this module fails.
> There are 2 issues with this.
> First and foremost, it is readily apparent in this case that no roles search should be performed in this case -- as no input data was provided to allow for such a search. Tomcat's JNDIRealm simply does no role search in such a case, for instance. Instead LdapExtLoginModule stubbornly insists on doing a search which is guaranteed to fail. LdapExtLoginModule should simply not perform the search. In my case I've specified a default role and that's all I want -- I don't even want the overhead of any further role searches, much less a failure.
> To add insult to injury, when this failure occurs the error messaging is horribly misleading, stating "Bad password for username xxx". The password was absolutely fine. The issue here is the role search, which clearly never even should have been attempted. In the case that the role search should have been attempted and failed, the error messaging should clearly state this -- not claim the password was incorrect when that's absolutely untrue.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (SECURITY-849) LdapExtLoginModule fails when role* options not specified
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-849?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated SECURITY-849:
--------------------------------------
Assignee: Stefan Guilhen (was: Darran Lofthouse)
> LdapExtLoginModule fails when role* options not specified
> ---------------------------------------------------------
>
> Key: SECURITY-849
> URL: https://issues.jboss.org/browse/SECURITY-849
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: PicketBox
> Affects Versions: PicketBox_4_0_19.SP5
> Reporter: Jess Holle
> Assignee: Stefan Guilhen
>
> If one does not specify role* options on this login module (i.e. does not specify rolesCtxDN, roleFilter, roleAttributeID, etc), then this module fails.
> There are 2 issues with this.
> First and foremost, it is readily apparent in this case that no roles search should be performed in this case -- as no input data was provided to allow for such a search. Tomcat's JNDIRealm simply does no role search in such a case, for instance. Instead LdapExtLoginModule stubbornly insists on doing a search which is guaranteed to fail. LdapExtLoginModule should simply not perform the search. In my case I've specified a default role and that's all I want -- I don't even want the overhead of any further role searches, much less a failure.
> To add insult to injury, when this failure occurs the error messaging is horribly misleading, stating "Bad password for username xxx". The password was absolutely fine. The issue here is the role search, which clearly never even should have been attempted. In the case that the role search should have been attempted and failed, the error messaging should clearly state this -- not claim the password was incorrect when that's absolutely untrue.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3665) LdapExtLoginModule fails when role* options not specified
by Jess Holle (JIRA)
Jess Holle created WFLY-3665:
--------------------------------
Summary: LdapExtLoginModule fails when role* options not specified
Key: WFLY-3665
URL: https://issues.jboss.org/browse/WFLY-3665
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 8.0.0.Final
Reporter: Jess Holle
Assignee: Darran Lofthouse
If one does not specify role* options on this login module (i.e. does not specify rolesCtxDN, roleFilter, roleAttributeID, etc), then this module fails.
There are 2 issues with this.
First and foremost, it is readily apparent in this case that no roles search should be performed in this case -- as no input data was provided to allow for such a search. Tomcat's JNDIRealm simply does no role search in such a case, for instance. Instead LdapExtLoginModule stubbornly insists on doing a search which is guaranteed to fail. LdapExtLoginModule should simply not perform the search. In my case I've specified a default role and that's all I want -- I don't even want the overhead of any further role searches, much less a failure.
To add insult to injury, when this failure occurs the error messaging is horribly misleading, stating "Bad password for username xxx". The password was absolutely fine. The issue here is the role search, which clearly never even should have been attempted. In the case that the role search should have been attempted and failed, the error messaging should clearly state this -- not claim the password was incorrect when that's absolutely untrue.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (DROOLS-562) Can't install migration tool
by Skip Skip (JIRA)
[ https://issues.jboss.org/browse/DROOLS-562?page=com.atlassian.jira.plugin... ]
Skip Skip commented on DROOLS-562:
----------------------------------
Thank you Petr!
I will give that a try.
On Thu, Jul 24, 2014 at 11:43 AM, Petr Široký (JIRA) <issues(a)jboss.org>
> Can't install migration tool
> ----------------------------
>
> Key: DROOLS-562
> URL: https://issues.jboss.org/browse/DROOLS-562
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Windows 7 Enterprise
> Reporter: Skip Skip
> Assignee: Petr Široký
> Priority: Blocker
>
> We are migrating some DROOLs from DROOLs 5.0 to the latest version, and moving our applications to JBoss AS 7.
> Looking into how to migrate these DROOLs, I found it recommended to use the migration tool that is located here drools-wb/drools-wb-jcr2vfs-migration at master · droolsjbpm/drools-wb · GitHub which is a sub-project of https://github.com/droolsjbpm/drools-wb
>
> When I try to build drools-wb with maven (mvn install), I keep dying here: Failure to find org.kie:kie-parent-with-dependencies:pom:6.2.0-SNAPSHOT
> When I try to just make the migration tool, I get this error:
> Unresolveable build extension: Plugin org.jboss.maven.plugins:maven-jdocbook-plugin:2.3.8 or one of its dependencies could not be resolved: The following artifacts could not be resolved: net.sf.docbook:docbook-xsl-ns:jar:1.74.0, net.socialchange.doctype:doctype-changer:jar:1.1: Could not find artifact net.sf.docbook:docbook-xsl-ns:jar:1.74.0 in gtrepositories
> Is the package 6.2.0-SNAPSHOT available anywhere publicly? If I don't have access to that code, is there a way for me to just get the migration utility?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3385) when using jsp:include the jsp:param being encoded at the included jsp
by Gael Marziou (JIRA)
[ https://issues.jboss.org/browse/WFLY-3385?page=com.atlassian.jira.plugin.... ]
Gael Marziou commented on WFLY-3385:
------------------------------------
We are also experiencing this bug, thanks for the proposed workaround we will test it and we'd be glad to hear from other users too.
Is there a way to mark this issue as not resolved for WildFly 8, it might help some users.
Is there a way to know if JBoss EAP includes this fix?
> when using jsp:include the jsp:param being encoded at the included jsp
> ----------------------------------------------------------------------
>
> Key: WFLY-3385
> URL: https://issues.jboss.org/browse/WFLY-3385
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: roy mizrachi
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> I have JSP A that includes JSP B like this:
> <jsp:include page="../anotherFolder/B.jsp">
> <jsp:param name="pathToRootContext" value='../' />
> </jsp:include>
> In JSP B i have the following:
> String pathToRootContext = request.getParameter("pathToRootContext");
> The value i get in the pathToRootContext is "..%2f"
> I tried the following but it didn't help:
> <servlet-container name="default" default-encoding="UTF-8">
> <jsp-config development="true" java-encoding="UTF-8"/>
> </servlet-container>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JBRULES-1751) Issue in Drools 4.0.7 when run in Multithreaded environment
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/JBRULES-1751?page=com.atlassian.jira.plug... ]
Vlastimil Eliáš reopened JBRULES-1751:
--------------------------------------
> Issue in Drools 4.0.7 when run in Multithreaded environment
> -----------------------------------------------------------
>
> Key: JBRULES-1751
> URL: https://issues.jboss.org/browse/JBRULES-1751
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.0.7
> Environment: OS AIX 1.5
> Reporter: Sitaraman Balaraman
> Assignee: Edson Tirelli
> Fix For: 5.0.1.FINAL
>
>
> Hi
> We have a batch program(Informatica mapping) which uses Jars taken from an application which uses JBoss Drools 4.0.7 and MVEL 1.3.7. The informatica Integration service runs in AIX Machine with JRE Version 1.5. The batch program process millions of records which in turn calls the Drools API. To improve the performance, we tried running our informatica process in a multi threaded environment(4 threads). While running we got the following exception for every record that we process(across all the threads).
> : Exception executing predicate eval( $terDate.before(ExtDateTimeUtils.getDate("01/01/1900")) )
> at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:216)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:162)
> 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:911)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:883)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:684)
> at org.drools.reteoo.ReteooStatelessSession.execute(ReteooStatelessSession.java:160)
> at com.wellpoint.eps.epds.business.framework.rules.jbrules.JBRulesExecutor.fireAllRules(JBRulesExecutor.java:85)
> at com.wellpoint.eps.epds.business.framework.validation.BaseHandlerImpl.validateInternal(BaseHandlerImpl.java:141)
> at com.wellpoint.eps.epds.business.framework.validation.BaseHandlerImpl.validateInternal(BaseHandlerImpl.java:75)
> at com.wellpoint.eps.epds.business.framework.validation.AbstractBusinessRuleHandler.validate(AbstractBusinessRuleHandler.java:43)
> at com.wellpoint.eps.epds.business.application.validation.ProviderContractBusinessRuleHandler.validate(ProviderContractBusinessRuleHandler.java:43)
> at com.wellpoint.eps.epds.business.framework.service.DefaultRuleValidationServiceImpl.applyBusinessRules(DefaultRuleValidationServiceImpl.java:284)
> at com.eps.epds.api.validation.ValidationServiceDeligator$DefaultValidationServiceImpl.validate(ValidationServiceDeligator.java:181)
> at com.informatica.powercenter.server.jtx.JTXPartitionDriverImplGen.inputTransaction(JTXPartitionDriverImplGen.java:1414)
> Caused by: org.mvel.CompileException: cannot invoke method
> at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:54)
> at org.mvel.optimizers.impl.refl.VariableAccessor.getValue(VariableAccessor.java:39)
> at org.mvel.ast.VariableDeepPropertyNode.getReducedValueAccelerated(VariableDeepPropertyNode.java:22)
> at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:21)
> at org.mvel.MVELRuntime.execute(MVELRuntime.java:90)
> at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111)
> at org.mvel.MVEL.executeExpression(MVEL.java:235)
> at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:45)
> at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:209)
> ... 20 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:46)
> ... 28 more
> Caused by: java.lang.NullPointerException
> at java.util.Date.getMillisOf(Date.java:953)
> at java.util.Date.before(Date.java:912)
> ... 32 more
> ].
> Could you please let me know if this is a known issue or is there any workaround for this problem?
> Thanks
> Sitaraman
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JBRULES-1751) Issue in Drools 4.0.7 when run in Multithreaded environment
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/JBRULES-1751?page=com.atlassian.jira.plug... ]
Vlastimil Eliáš updated JBRULES-1751:
-------------------------------------
Description:
Hi
We have a batch program(Informatica mapping) which uses Jars taken from an application which uses JBoss Drools 4.0.7 and MVEL 1.3.7. The informatica Integration service runs in AIX Machine with JRE Version 1.5. The batch program process millions of records which in turn calls the Drools API. To improve the performance, we tried running our informatica process in a multi threaded environment(4 threads). While running we got the following exception for every record that we process(across all the threads).
: Exception executing predicate eval( $terDate.before(ExtDateTimeUtils.getDate("01/01/1900")) )
at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:216)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:162)
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:911)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:883)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:684)
at org.drools.reteoo.ReteooStatelessSession.execute(ReteooStatelessSession.java:160)
...
Caused by: org.mvel.CompileException: cannot invoke method
at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:54)
at org.mvel.optimizers.impl.refl.VariableAccessor.getValue(VariableAccessor.java:39)
at org.mvel.ast.VariableDeepPropertyNode.getReducedValueAccelerated(VariableDeepPropertyNode.java:22)
at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:21)
at org.mvel.MVELRuntime.execute(MVELRuntime.java:90)
at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111)
at org.mvel.MVEL.executeExpression(MVEL.java:235)
at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:45)
at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:209)
... 20 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:46)
... 28 more
Caused by: java.lang.NullPointerException
at java.util.Date.getMillisOf(Date.java:953)
at java.util.Date.before(Date.java:912)
... 32 more
].
Could you please let me know if this is a known issue or is there any workaround for this problem?
Thanks
Sitaraman
was:
Hi
We have a batch program(Informatica mapping) which uses Jars taken from an application which uses JBoss Drools 4.0.7 and MVEL 1.3.7. The informatica Integration service runs in AIX Machine with JRE Version 1.5. The batch program process millions of records which in turn calls the Drools API. To improve the performance, we tried running our informatica process in a multi threaded environment(4 threads). While running we got the following exception for every record that we process(across all the threads).
: Exception executing predicate eval( $terDate.before(ExtDateTimeUtils.getDate("01/01/1900")) )
at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:216)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:162)
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:911)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:883)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:684)
at org.drools.reteoo.ReteooStatelessSession.execute(ReteooStatelessSession.java:160)
at com.wellpoint.eps.epds.business.framework.rules.jbrules.JBRulesExecutor.fireAllRules(JBRulesExecutor.java:85)
at com.wellpoint.eps.epds.business.framework.validation.BaseHandlerImpl.validateInternal(BaseHandlerImpl.java:141)
at com.wellpoint.eps.epds.business.framework.validation.BaseHandlerImpl.validateInternal(BaseHandlerImpl.java:75)
at com.wellpoint.eps.epds.business.framework.validation.AbstractBusinessRuleHandler.validate(AbstractBusinessRuleHandler.java:43)
at com.wellpoint.eps.epds.business.application.validation.ProviderContractBusinessRuleHandler.validate(ProviderContractBusinessRuleHandler.java:43)
at com.wellpoint.eps.epds.business.framework.service.DefaultRuleValidationServiceImpl.applyBusinessRules(DefaultRuleValidationServiceImpl.java:284)
at com.eps.epds.api.validation.ValidationServiceDeligator$DefaultValidationServiceImpl.validate(ValidationServiceDeligator.java:181)
at com.informatica.powercenter.server.jtx.JTXPartitionDriverImplGen.inputTransaction(JTXPartitionDriverImplGen.java:1414)
Caused by: org.mvel.CompileException: cannot invoke method
at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:54)
at org.mvel.optimizers.impl.refl.VariableAccessor.getValue(VariableAccessor.java:39)
at org.mvel.ast.VariableDeepPropertyNode.getReducedValueAccelerated(VariableDeepPropertyNode.java:22)
at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:21)
at org.mvel.MVELRuntime.execute(MVELRuntime.java:90)
at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111)
at org.mvel.MVEL.executeExpression(MVEL.java:235)
at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:45)
at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:209)
... 20 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:46)
... 28 more
Caused by: java.lang.NullPointerException
at java.util.Date.getMillisOf(Date.java:953)
at java.util.Date.before(Date.java:912)
... 32 more
].
Could you please let me know if this is a known issue or is there any workaround for this problem?
Thanks
Sitaraman
> Issue in Drools 4.0.7 when run in Multithreaded environment
> -----------------------------------------------------------
>
> Key: JBRULES-1751
> URL: https://issues.jboss.org/browse/JBRULES-1751
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.0.7
> Environment: OS AIX 1.5
> Reporter: Sitaraman Balaraman
> Assignee: Edson Tirelli
> Fix For: 5.0.1.FINAL
>
>
> Hi
> We have a batch program(Informatica mapping) which uses Jars taken from an application which uses JBoss Drools 4.0.7 and MVEL 1.3.7. The informatica Integration service runs in AIX Machine with JRE Version 1.5. The batch program process millions of records which in turn calls the Drools API. To improve the performance, we tried running our informatica process in a multi threaded environment(4 threads). While running we got the following exception for every record that we process(across all the threads).
> : Exception executing predicate eval( $terDate.before(ExtDateTimeUtils.getDate("01/01/1900")) )
> at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:216)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:162)
> 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:911)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:883)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:684)
> at org.drools.reteoo.ReteooStatelessSession.execute(ReteooStatelessSession.java:160)
> ...
> Caused by: org.mvel.CompileException: cannot invoke method
> at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:54)
> at org.mvel.optimizers.impl.refl.VariableAccessor.getValue(VariableAccessor.java:39)
> at org.mvel.ast.VariableDeepPropertyNode.getReducedValueAccelerated(VariableDeepPropertyNode.java:22)
> at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:21)
> at org.mvel.MVELRuntime.execute(MVELRuntime.java:90)
> at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111)
> at org.mvel.MVEL.executeExpression(MVEL.java:235)
> at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:45)
> at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:209)
> ... 20 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:46)
> ... 28 more
> Caused by: java.lang.NullPointerException
> at java.util.Date.getMillisOf(Date.java:953)
> at java.util.Date.before(Date.java:912)
> ... 32 more
> ].
> Could you please let me know if this is a known issue or is there any workaround for this problem?
> Thanks
> Sitaraman
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months