[JBoss JIRA] (JBRULES-3718) java.lang.NullPointerException at org.mvel2.ast.IntSub.getReducedValueAccelerated
by Michiel Vermandel (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3718?page=com.atlassian.jira.plug... ]
Michiel Vermandel commented on JBRULES-3718:
--------------------------------------------
The project is the base of a commercial implementation. I don't think I can publish that to the world.
I can send it to you personally though.
> java.lang.NullPointerException at org.mvel2.ast.IntSub.getReducedValueAccelerated
> ---------------------------------------------------------------------------------
>
> Key: JBRULES-3718
> URL: https://issues.jboss.org/browse/JBRULES-3718
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.5.0.Final
> Environment: Windows 7 64bit - Java 1.7.0
> Drools-planner 5.5.0.Final
> -> Drools-core 5.5.0.Final
> -> mvel2 2.1.3.Final
> Reporter: Michiel Vermandel
> Assignee: Mario Fusco
>
> When I run my planning I get now and then the stacktrace as mentioned below.
> It happens about 1 in 5 times during running a JUnit test on small amount of planning entities and problem facts.
> It started after adding my last rule:
> rule "tasksInSameCommunityMustBeChained"
> when
> $lead : Task(this==lead, period!=null, communityId!= null, $communityId : communityId)
> not ( Task(this==lead, communityId == $communityId, id != $lead.id, ($lead.startPeriodId-1) <= endPeriodId && ($lead.endPeriodId+1) >= startPeriodId ) )
> then
> insertLogical(new IntConstraintOccurrence("tasksInSameCommunityMustBeChained", ConstraintType.NEGATIVE_HARD, Importance.chainedPeriod, $communityId, $lead, $lead.getStartPeriodId()));
> end
> Stack trace:
> Exception in thread "Thread-1" java.lang.NullPointerException
> at org.mvel2.ast.IntSub.getReducedValueAccelerated(IntSub.java:17)
> at org.mvel2.compiler.ExecutableAccessor.getValue(ExecutableAccessor.java:38)
> at org.mvel2.ast.Substatement.getReducedValueAccelerated(Substatement.java:44)
> at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:108)
> at org.mvel2.ast.And.getReducedValueAccelerated(And.java:34)
> at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
> at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
> at org.mvel2.MVEL.executeExpression(MVEL.java:930)
> at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
> at org.drools.rule.constraint.MvelConditionEvaluator.ensureBranchEvaluation(MvelConditionEvaluator.java:117)
> at org.drools.rule.constraint.MvelConditionEvaluator.ensureCompleteEvaluation(MvelConditionEvaluator.java:102)
> at org.drools.rule.constraint.MvelConditionEvaluator.ensureCompleteEvaluation(MvelConditionEvaluator.java:90)
> at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:82)
> at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
> at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
> at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6352) CLI cursor marker position is not consistent
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/AS7-6352?page=com.atlassian.jira.plugin.s... ]
Kabir Khan commented on AS7-6352:
---------------------------------
This happens on OS X Lion - java version "1.6.0_37"
I've actually noticed it was weird for a while, it is only recently that I realised that the visual cursor position was wrong, while the cursor position under the hood is where expected. Without that realisation it becomes very weird to try to edit :-)
I see this also happens on a fresh line, I'll summarize here - [] means visul cursor position. Hopefully that might shed some light even if you can't reproduce.
Initially I enter:
/zob[] I move my cursor to 'b'
/zo[b] Now I hit backspace
/zb[] Now I hit backspace again
/b[] Now I hit backspace again
b[] Hitting backspace again has no effect since the cursor is actually at the beginning, to delete the 'b' I need to go to the right, so:
b [] Now backspace deletes the 'b' and I end up with
[]
Another example:
/zob[] I move my cursor to 'b' since I meant to start writing 'subsystem' and not 'zobsystem'
/zo[b] Now I hit backspace
/zb[] Now I hit backspace again
/b[] Now I enter 's'
/sb[] Now I enter 'u'
/sub[] Now I want to append 'system', so I enter 's'
/susb[] I realize the cursor was in a different place than what it looked like, so I hit backspace
/sub[] I now try to move the cursor one step to the right
/sub [] I enter 's'
/sub s[] So now it makes even less sense :-)
This only seems to affect deletions when I go back, if I delete from the end everything is fine, e.g.:
/zub[] delete
/zu[] delete
/z[] delete
/[] Press 's'
/s[] Press 'u'
/su[]
etc.
> CLI cursor marker position is not consistent
> --------------------------------------------
>
> Key: AS7-6352
> URL: https://issues.jboss.org/browse/AS7-6352
> Project: Application Server 7
> Issue Type: Feature Request
> Components: CLI
> Reporter: Kabir Khan
> Assignee: Alexey Loubyansky
> Fix For: 7.2.0.Alpha1
>
>
> To reproduce, execute
> /subsystem=jmx:read-resource
> Now press the up arrow, to get that command again so you see
> /subsystem=jmx:read-resource
> The cursor is at the end. Now I want to delete 'jmx' and put in 'ee', so I move the cursor to the ':'. I press backspace to delete the 'x' but the cursor marker jumps back to the end of the line, however when I press backspace again the 'm' gets deleted. This appears to be at the end of the line when I delete the 'j' and enter the 'ee'. So what happens under the hood is fine, but the marker appears to be in the wrong place after it has been moved and editing starts.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBRULES-3718) java.lang.NullPointerException at org.mvel2.ast.IntSub.getReducedValueAccelerated
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3718?page=com.atlassian.jira.plug... ]
Mario Fusco commented on JBRULES-3718:
--------------------------------------
The fact that the Exception doesn't have impact on your results is not odd. It is thrown when drools tries to compile a constraint converting it in a java class in order to run it in compiled mode (faster) instead of the interpreted one using mvel. Since in your particular case the compilation fails the compiled constrained is discarded and its evaluation continues in interpreted mode. It means that the evaluation of the constraint is always correct (just a bit slower than how it could be in compiled mode) and this is why you don't see any difference in the final result.
However I am not able to reproduce this issue at the moment, so it would be great if you could attach your project to this ticket together with some quick instruction on how to reproduce the problem.
> java.lang.NullPointerException at org.mvel2.ast.IntSub.getReducedValueAccelerated
> ---------------------------------------------------------------------------------
>
> Key: JBRULES-3718
> URL: https://issues.jboss.org/browse/JBRULES-3718
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.5.0.Final
> Environment: Windows 7 64bit - Java 1.7.0
> Drools-planner 5.5.0.Final
> -> Drools-core 5.5.0.Final
> -> mvel2 2.1.3.Final
> Reporter: Michiel Vermandel
> Assignee: Mario Fusco
>
> When I run my planning I get now and then the stacktrace as mentioned below.
> It happens about 1 in 5 times during running a JUnit test on small amount of planning entities and problem facts.
> It started after adding my last rule:
> rule "tasksInSameCommunityMustBeChained"
> when
> $lead : Task(this==lead, period!=null, communityId!= null, $communityId : communityId)
> not ( Task(this==lead, communityId == $communityId, id != $lead.id, ($lead.startPeriodId-1) <= endPeriodId && ($lead.endPeriodId+1) >= startPeriodId ) )
> then
> insertLogical(new IntConstraintOccurrence("tasksInSameCommunityMustBeChained", ConstraintType.NEGATIVE_HARD, Importance.chainedPeriod, $communityId, $lead, $lead.getStartPeriodId()));
> end
> Stack trace:
> Exception in thread "Thread-1" java.lang.NullPointerException
> at org.mvel2.ast.IntSub.getReducedValueAccelerated(IntSub.java:17)
> at org.mvel2.compiler.ExecutableAccessor.getValue(ExecutableAccessor.java:38)
> at org.mvel2.ast.Substatement.getReducedValueAccelerated(Substatement.java:44)
> at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:108)
> at org.mvel2.ast.And.getReducedValueAccelerated(And.java:34)
> at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
> at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
> at org.mvel2.MVEL.executeExpression(MVEL.java:930)
> at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
> at org.drools.rule.constraint.MvelConditionEvaluator.ensureBranchEvaluation(MvelConditionEvaluator.java:117)
> at org.drools.rule.constraint.MvelConditionEvaluator.ensureCompleteEvaluation(MvelConditionEvaluator.java:102)
> at org.drools.rule.constraint.MvelConditionEvaluator.ensureCompleteEvaluation(MvelConditionEvaluator.java:90)
> at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:82)
> at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
> at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
> at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6353) It's impossible to activate multiple resource adapters, pointing to the same module slot
by Vladimir Rastseluev (JIRA)
[ https://issues.jboss.org/browse/AS7-6353?page=com.atlassian.jira.plugin.s... ]
Vladimir Rastseluev updated AS7-6353:
-------------------------------------
Steps to Reproduce:
1)Merge tests from github AS repository https://github.com/vratsel/jboss-as/commits/AS7-5768T
2)build AS
3)execute tests:
./integration-tests.sh clean install -Dts.basic -Dts.noSmoke -Dtest=\*moduledeployment.\* -Dversion.surefire.plugin=2.11
Only first test passes. Another, using the same module slot, fail.
It's also illustrated by one-test:
./integration-tests.sh clean install -Dts.basic -Dts.noSmoke -Dtest=\*moduledeployment.TwoRa\* -Dversion.surefire.plugin=2.11
was:
1)Merge tests from github AS repository https://github.com/vratsel/jboss-as/commits/AS7-5768T
2)build AS
3)execute tests:
./integration-tests.sh clean install -Dts.basic -Dts.noSmoke -Dtest=\*moduledeployment.\* -Dversion.surefire.plugin=2.11
Only first test passes. Another, using the same module slot, fail.
It's also illustrated by one-test:
./integration-tests.sh clean install -Dts.basic -Dts.noSmoke -Dtest=*moduledeployment.TwoRa* -Dversion.surefire.plugin=2.11
> It's impossible to activate multiple resource adapters, pointing to the same module slot
> ----------------------------------------------------------------------------------------
>
> Key: AS7-6353
> URL: https://issues.jboss.org/browse/AS7-6353
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Reporter: Vladimir Rastseluev
> Assignee: Stefano Maestri
> Fix For: 7.2.0.Alpha1
>
>
> Resource adapter archive is deployed as module. If we add several activations to the resource-adapters subsystem configuration, pointing to the same module slot, only first one will be really activated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6353) It's impossible to activate multiple resource adapters, pointing to the same module slot
by Vladimir Rastseluev (JIRA)
[ https://issues.jboss.org/browse/AS7-6353?page=com.atlassian.jira.plugin.s... ]
Vladimir Rastseluev updated AS7-6353:
-------------------------------------
Steps to Reproduce:
1)Merge tests from github AS repository https://github.com/vratsel/jboss-as/commits/AS7-5768T
2)build AS
3)execute tests:
./integration-tests.sh clean install -Dts.basic -Dts.noSmoke -Dtest=\*moduledeployment.\* -Dversion.surefire.plugin=2.11
Only first test passes. Another, using the same module slot, fail.
It's also illustrated by one-test:
./integration-tests.sh clean install -Dts.basic -Dts.noSmoke -Dtest=*moduledeployment.TwoRa* -Dversion.surefire.plugin=2.11
was:
1)Merge tests from github AS repository https://github.com/vratsel/jboss-as/commits/AS7-5768T
2)build AS
3)execute tests:
./integration-tests.sh clean install -Dts.basic -Dts.noSmoke -Dtest=*moduledeployment.* -Dversion.surefire.plugin=2.11
Only first test passes. Another, using the same module slot, fail.
It's also illustrated by one-test:
./integration-tests.sh clean install -Dts.basic -Dts.noSmoke -Dtest=*moduledeployment.TwoRa* -Dversion.surefire.plugin=2.11
> It's impossible to activate multiple resource adapters, pointing to the same module slot
> ----------------------------------------------------------------------------------------
>
> Key: AS7-6353
> URL: https://issues.jboss.org/browse/AS7-6353
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Reporter: Vladimir Rastseluev
> Assignee: Stefano Maestri
> Fix For: 7.2.0.Alpha1
>
>
> Resource adapter archive is deployed as module. If we add several activations to the resource-adapters subsystem configuration, pointing to the same module slot, only first one will be really activated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6275) AS7/EAP6 @Stateless/mappedName behaviour could be made consistent with AS5/EAP5
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/AS7-6275?page=com.atlassian.jira.plugin.s... ]
jaikiran pai updated AS7-6275:
------------------------------
Component/s: EJB
> AS7/EAP6 @Stateless/mappedName behaviour could be made consistent with AS5/EAP5
> -------------------------------------------------------------------------------
>
> Key: AS7-6275
> URL: https://issues.jboss.org/browse/AS7-6275
> Project: Application Server 7
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Windows7
> Reporter: Baptiste MATHUS
> Labels: regression
>
> Though I agree mappedName was never meant to be standard, as reminded in the link below, at least it was something done within JBoss AS, and I wonder if something better for *JBoss* users&customers couldn't be made to help them.
> How difficult would it be for example to bind SLSB to the given mappedName (in addition to the standard portable jndi naming, sure)?
> I admit we've certainly been using it the wrong way in our shop, but that's how it is now, and today this change is currently being one of the biggest PITA for us to migrate between EAP5 and EAP6...
> By the way, even a special patch or workaround that could make that possible would be perfect.
> WDYT?
> Thanks!
> (Note: I already read carefully the following thread: http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002246.html I searched the jiras without finding one about that subject, so I eventually decided to create this entry for potential reference).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months