[JBoss JIRA] (AS7-6384) Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/AS7-6384?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen closed AS7-6384.
--------------------------------
Resolution: Rejected
Use the forum for questions - https://community.jboss.org/en/jbossas7
> Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception
> -----------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6384
> URL: https://issues.jboss.org/browse/AS7-6384
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.2.0.Alpha1
> Environment: Configuration:
> JDK-Version: 1.6.0_33
> Operating System: Windows 7 (32 Bit)
> JBoss Application Server jboss-as-7.2.0.Alpha1-SNAPSHOT (build Dec. 19th 2012)
> JDK-Version: 1.6.0_33
> Resource Adapter: BeanConnect 3.0 developed by our Company (Fujitsu)
> Reporter: Martin Keller
> Assignee: Jesper Pedersen
>
> Starting an application using our JCA 1.6 resource adapter fails with
> java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
> It works ok in the JBoss JCA 1.5 environment and on other application servers with JCA1.6 environment:
> GlassFish OS Edition 3, IBM WebSphere 8.0 and WebLogic 12.
> Questions:
> What could be the cause for this exception?
> Can we switch off the validation?
> What is missing to run the validation successful?
> Details:
> The full stack is:
> 15:04:02,128 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 64) MSC00001: Failed to start service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:177)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> ... 7 more
> Caused by: javax.resource.ResourceException: IJ000852: Validation exception
> at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:147)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:175)
> ... 8 more
> Caused by: javax.validation.ValidationException: Unable to find a default provider
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:264) [validation-api-1.0.0.GA.jar:]
> at org.jboss.jca.core.bv.BeanValidationUtil.createValidatorFactory(BeanValidationUtil.java:51)
> at org.jboss.jca.core.bv.BeanValidationUtil.createValidator(BeanValidationUtil.java:63)
> at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:135)
> ... 9 more
--
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-6262) Dynamically added JSF converter ignored in some cases since Mojarra 2.1.16 upgrade
by Marek Schmidt (JIRA)
[ https://issues.jboss.org/browse/AS7-6262?page=com.atlassian.jira.plugin.s... ]
Marek Schmidt updated AS7-6262:
-------------------------------
Attachment: reproducer-pure.tar.gz
reproducer-pure.war
(reproducer-pure with only JSF components)
> Dynamically added JSF converter ignored in some cases since Mojarra 2.1.16 upgrade
> ----------------------------------------------------------------------------------
>
> Key: AS7-6262
> URL: https://issues.jboss.org/browse/AS7-6262
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.1.4.Final (EAP)
> Environment: Current 7.1.4.Final-SNAPSHOT (2013-01-02 be583f5)
> Reporter: Marek Schmidt
> Assignee: Stan Silvert
> Fix For: 7.1.4.Final (EAP)
>
> Attachments: AS7-6262.tar.gz, AS7-6262.war, reproducer-pure.tar.gz, reproducer-pure.war, reproducer.tar.gz, reproducer.war
>
>
> Dynamically created converters seems to be ignored in some special cases, like the following.
> Having a form like this:
> {code}
> <h:form>
> <ul>
> <ui:repeat value="#{basket.items}" var="i">
> <li>Item #{i.number}
> <h:selectOneMenu value="#{i.color}">
> <test:selectColors />
> </h:selectOneMenu>
> </li>
> </ui:repeat>
> </ul>
> <div>
> <h:commandButton value="Add" action="#{basket.add}" />
> </div>
> <h:outputText value="#{basket.string}" />
> </h:form>
> {code}
> Where SelectColors is
> {code}
> @JsfComponent(description=@Description(displayName="org.jboss.seam.test.SelectColors",value="Creates a List<SelectItem> of colors."),
> family="javax.faces.SelectItems", type="org.jboss.seam.test.SelectColors",generate="org.jboss.seam.test.html.HtmlSelectColors",
> tag = @Tag(baseClass="javax.faces.webapp.UIComponentTagBase", name="selectColors"))
> public class SelectColors extends javax.faces.component.UISelectItems implements SystemEventListener {
> public SelectColors() {
> FacesContext context = FacesContext.getCurrentInstance();
> UIViewRoot root = context.getViewRoot();
> root.subscribeToViewEvent( PreRenderViewEvent.class, this );
> }
> @Override
> public Object getValue() {
> List<SelectItem> ret = new LinkedList<SelectItem> ();
> ret.add(new SelectItem("default", "Select color... (black by default)"));
> ret.add(new SelectItem("red", "Red"));
> ret.add(new SelectItem("white", "White"));
> ret.add(new SelectItem("blue", "Blue"));
> ret.add(new SelectItem("black", "Black"));
> return ret;
> }
> private void addSelectionConverter() {
> UIComponent parentComponent = getParent();
> if (parentComponent instanceof ValueHolder) {
> ValueHolder parentValueHolder = (ValueHolder) parentComponent;
> Converter parentConverter = parentValueHolder.getConverter();
> if (parentConverter == null) {
> parentValueHolder.setConverter(new DefaultColorConverter());
> }
> }
> }
> @Override
> public void processEvent(SystemEvent event) throws AbortProcessingException
> {
> if ( !FacesContext.getCurrentInstance().isPostback() ) {
> addSelectionConverter();
> }
> }
> @Override
> public boolean isListenerForSource(Object source)
> {
> return ( source instanceof UIViewRoot );
> }
> }
> {code}
> and the DefaultColorConverter being:
> {code}
> @FacesConverter(value="org.jboss.seam.test.DefaultColorConverter")
> public class DefaultColorConverter implements Converter
> {
> public static final String DEFAULT_COLOR = "black";
> public Object getAsObject(FacesContext context, UIComponent component, String value) throws ConverterException
> {
> if ("default".equals(value)) {
> return DEFAULT_COLOR;
> }
>
> return value;
> }
> public String getAsString(FacesContext context, UIComponent component, Object value) throws ConverterException
> {
> return value.toString();
> }
> }
> {code}
> In the pre-Mojarra 2.1.16 upgrade, clicking on the add button repeatedly creates "black" items. Post mojarra 2.1.16, it sets the color to "default", which should never happen, as the converter should convert the "default" value into "black".
--
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] (JGRP-1570) STABLE: desired_avg_gossip leads to long intervals between reception of STABILITY messages in large clusters
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1570?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1570:
--------------------------------
Or possibly have every node periodically send a STABLE message to the coordinator, and the coord multicasts a STABILITY message when a STABLE msg from everyone has been received. This would eliminate the need for the first multicast by the coord. The cost would be N unicasts every desired_avg_gossip seconds and an ensuing multicast by the coord.
> STABLE: desired_avg_gossip leads to long intervals between reception of STABILITY messages in large clusters
> ------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-1570
> URL: https://issues.jboss.org/browse/JGRP-1570
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> The time computed for the sending of STABLE is desired_avg_gossip * cluster-size *2. While this is OK for small clusters, it may be too big for large clusters.
> On the other hand, if every member simply multicasts a STABLE message every (say) 30 seconds on average, then the number of messages sent grows with increasing cluster size.
> Investigate a way to set a lower and upper limit for the making and delivery of *STABILITY* messages, e.g. the goal is to receive 1 stability message every 60s.
> Besides increased traffic, however, this requires everyone to have a TCP connection to everybody else in the cluster in case of a TCP transport.
> A better solution might be to have only a dedicated member (the coord) periodically multicast a STABLE message. Everyone replies with a (unicast) STABLE message and when the coord has received STABLE replies from everyone, it multicasts a STABILITY message. This would only require a multicast from the coord to everyone, establishing TCP connections from the coord to everyone (usually already exists because of the VIEW-CHANGE multicast), but everyone would reuse the same TCP connection to send the reply.
--
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] (JGRP-1570) STABLE: desired_avg_gossip leads to long intervals between reception of STABILITY messages in large clusters
by Bela Ban (JIRA)
Bela Ban created JGRP-1570:
------------------------------
Summary: STABLE: desired_avg_gossip leads to long intervals between reception of STABILITY messages in large clusters
Key: JGRP-1570
URL: https://issues.jboss.org/browse/JGRP-1570
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
The time computed for the sending of STABLE is desired_avg_gossip * cluster-size *2. While this is OK for small clusters, it may be too big for large clusters.
On the other hand, if every member simply multicasts a STABLE message every (say) 30 seconds on average, then the number of messages sent grows with increasing cluster size.
Investigate a way to set a lower and upper limit for the making and delivery of *STABILITY* messages, e.g. the goal is to receive 1 stability message every 60s.
Besides increased traffic, however, this requires everyone to have a TCP connection to everybody else in the cluster in case of a TCP transport.
A better solution might be to have only a dedicated member (the coord) periodically multicast a STABLE message. Everyone replies with a (unicast) STABLE message and when the coord has received STABLE replies from everyone, it multicasts a STABILITY message. This would only require a multicast from the coord to everyone, establishing TCP connections from the coord to everyone (usually already exists because of the VIEW-CHANGE multicast), but everyone would reuse the same TCP connection to send the reply.
--
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-6383) jboss-cli.sh terminates suddenly if we use wild card characters with deployment-info command
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/AS7-6383?page=com.atlassian.jira.plugin.s... ]
Alexey Loubyansky resolved AS7-6383.
------------------------------------
Resolution: Duplicate Issue
This was fixed as AS7-6335
> jboss-cli.sh terminates suddenly if we use wild card characters with deployment-info command
> ---------------------------------------------------------------------------------------------
>
> Key: AS7-6383
> URL: https://issues.jboss.org/browse/AS7-6383
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.1.3.Final (EAP)
> Environment: all OS
> Reporter: Jay Kumar SenSharma
> Assignee: Alexey Loubyansky
> Labels: eap6, jboss
>
> Incorrect exception handling in EAP6 jboss-cli utility.
> While using jboss-cli.sh to access the deployment-info of all the deployed applications like following:
> [standalone@apsrt0311:9999 /] deployment-info --name=*
> As soon as the above command is executed it "terminates" the CLI process with the following exception:
> [standalone@apsrt0311:9999 /] deployment-info --name=*
> java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getChild(ModelValue.java:108)
> at org.jboss.dmr.ModelNode.get(ModelNode.java:798)
> at org.jboss.as.cli.handlers.DeploymentInfoHandler.handleResponse(DeploymentInfoHandler.java:244)
> at org.jboss.as.cli.handlers.BaseOperationCommand.doHandle(BaseOperationCommand.java:213)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86)
> at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:529)
> at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:545)
> at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1114)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:243)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.modules.Module.run(Module.java:270)
> at org.jboss.modules.Main.main(Main.java:294)
>
--
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] (DROOLS-18) [Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-18?page=com.atlassian.jira.plugin.... ]
Geoffrey De Smet reassigned DROOLS-18:
--------------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> [Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-18
> URL: https://issues.jboss.org/browse/DROOLS-18
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Windows 7 64Bit
> Java 1.7.0
> Drools-core 5.5.0.Final
> Drools-compiler 5.5.0.Final
> Mvel2 2.1.3.Final
> Reporter: Michiel Vermandel
> Assignee: Mario Fusco
> Priority: Critical
>
> In about one out of ten JUnit runs, I get a crash with stack trace.
> The process terminates immediately.
> Unit test output is 100% the same on successful runs.
> Stack trace:
> [Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
> [Near : {... this == lead ....}]
> ^
> [Line: 1, Column: 1]
> at org.mvel2.ast.BinaryOperation.<init>(BinaryOperation.java:84)
> at org.mvel2.util.CompilerTools.finalizePayload(CompilerTools.java:118)
> at org.mvel2.compiler.ExpressionCompiler._compile(ExpressionCompiler.java:287)
> at org.mvel2.compiler.ExpressionCompiler.compile(ExpressionCompiler.java:62)
> at org.mvel2.MVEL.compileExpression(MVEL.java:810)
> at org.drools.base.mvel.MVELCompilationUnit.compile(MVELCompilationUnit.java:435)
> at org.drools.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
> at org.drools.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:206)
> at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:190)
> at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
> at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
> at org.drools.planner.core.score.director.drools.DroolsScoreDirector.afterEntityAdded(DroolsScoreDirector.java:103)
> at org.drools.planner.core.heuristic.selector.variable.PlanningVariableWalker.moveIterator(PlanningVariableWalker.java:145)
> at org.drools.planner.core.constructionheuristic.greedyFit.decider.DefaultGreedyDecider.decideNextStep(DefaultGreedyDecider.java:74)
> at org.drools.planner.core.constructionheuristic.greedyFit.DefaultGreedyFitSolverPhase.solve(DefaultGreedyFitSolverPhase.java:65)
> at org.drools.planner.core.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190)
> at org.drools.planner.core.solver.DefaultSolver.solve(DefaultSolver.java:155)
> at be.axi.planner.app.InspectionSchedule.solve(InspectionSchedule.java:192)
> at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:288)
> at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:298)
> at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:315)
> at be.axi.planner.TaskGroupingTest.communitySuccess02(TaskGroupingTest.java:289)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> 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:50)
> 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)
--
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] (DROOLS-18) [Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
by Michiel Vermandel (JIRA)
Michiel Vermandel created DROOLS-18:
---------------------------------------
Summary: [Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
Key: DROOLS-18
URL: https://issues.jboss.org/browse/DROOLS-18
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Windows 7 64Bit
Java 1.7.0
Drools-core 5.5.0.Final
Drools-compiler 5.5.0.Final
Mvel2 2.1.3.Final
Reporter: Michiel Vermandel
Assignee: Mark Proctor
Priority: Critical
In about one out of ten JUnit runs, I get a crash with stack trace.
The process terminates immediately.
Unit test output is 100% the same on successful runs.
Stack trace:
[Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
[Near : {... this == lead ....}]
^
[Line: 1, Column: 1]
at org.mvel2.ast.BinaryOperation.<init>(BinaryOperation.java:84)
at org.mvel2.util.CompilerTools.finalizePayload(CompilerTools.java:118)
at org.mvel2.compiler.ExpressionCompiler._compile(ExpressionCompiler.java:287)
at org.mvel2.compiler.ExpressionCompiler.compile(ExpressionCompiler.java:62)
at org.mvel2.MVEL.compileExpression(MVEL.java:810)
at org.drools.base.mvel.MVELCompilationUnit.compile(MVELCompilationUnit.java:435)
at org.drools.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
at org.drools.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:206)
at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:190)
at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
at org.drools.planner.core.score.director.drools.DroolsScoreDirector.afterEntityAdded(DroolsScoreDirector.java:103)
at org.drools.planner.core.heuristic.selector.variable.PlanningVariableWalker.moveIterator(PlanningVariableWalker.java:145)
at org.drools.planner.core.constructionheuristic.greedyFit.decider.DefaultGreedyDecider.decideNextStep(DefaultGreedyDecider.java:74)
at org.drools.planner.core.constructionheuristic.greedyFit.DefaultGreedyFitSolverPhase.solve(DefaultGreedyFitSolverPhase.java:65)
at org.drools.planner.core.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190)
at org.drools.planner.core.solver.DefaultSolver.solve(DefaultSolver.java:155)
at be.axi.planner.app.InspectionSchedule.solve(InspectionSchedule.java:192)
at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:288)
at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:298)
at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:315)
at be.axi.planner.TaskGroupingTest.communitySuccess02(TaskGroupingTest.java:289)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
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:50)
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)
--
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