[JBoss JIRA] (DROOLS-1686) NPE using drools accumulate function in fairness constraint (tennis example)
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1686?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet moved PLANNER-845 to DROOLS-1686:
--------------------------------------------------
Project: Drools (was: OptaPlanner)
Key: DROOLS-1686 (was: PLANNER-845)
Component/s: core engine
(was: optaplanner-examples)
Affects Version/s: 7.1.0.Final
(was: 7.1.0.Final)
> NPE using drools accumulate function in fairness constraint (tennis example)
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1686
> URL: https://issues.jboss.org/browse/DROOLS-1686
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.1.0.Final
> Environment: openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-b11)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
> Reporter: Markus Müller
> Assignee: Mario Fusco
> Attachments: TennisConstraintsTest.java
>
>
> Using the LoadBalanceAccumulateFunction found in tennis example for modelling fairness constraints leads to NPE in drools itself, in FromNodeLeftTuple.java:
> {code}
> Caused by: java.lang.NullPointerException
> at org.drools.core.reteoo.FromNodeLeftTuple.getAccumulatedObjects(FromNodeLeftTuple.java:98)
> {code}
> Full stacktrace:
> {code:java}
> Exception executing consequence for rule "fairAssignmentCountPerTeam" in org.optaplanner.examples.tennis.solver: java.lang.NullPointerException
> at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> at org.drools.core.common.DefaultAgenda.handleException(DefaultAgenda.java:1252)
> at org.drools.core.phreak.RuleExecutor.innerFireActivation(RuleExecutor.java:438)
> at org.drools.core.phreak.RuleExecutor.fireActivation(RuleExecutor.java:379)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:135)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:88)
> at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34)
> at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1068)
> at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1015)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1007)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:117)
> at org.optaplanner.test.impl.score.AbstractScoreVerifier.assertWeight(AbstractScoreVerifier.java:82)
> at org.optaplanner.test.impl.score.buildin.hardmediumsoft.HardMediumSoftScoreVerifier.assertSoftWeight(HardMediumSoftScoreVerifier.java:107)
> at org.optaplanner.test.impl.score.buildin.hardmediumsoft.HardMediumSoftScoreVerifier.assertSoftWeight(HardMediumSoftScoreVerifier.java:94)
> at org.optaplanner.examples.tennis.TennisConstraintsTest.fairAssignmentCountPerTeam(TennisConstraintsTest.java:40)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.NullPointerException
> at org.drools.core.reteoo.FromNodeLeftTuple.getAccumulatedObjects(FromNodeLeftTuple.java:98)
> at org.drools.core.common.AgendaItem.getObjectsDeep(AgendaItem.java:78)
> at org.drools.core.reteoo.RuleTerminalNodeLeftTuple.getObjectsDeep(RuleTerminalNodeLeftTuple.java:359)
> at org.optaplanner.core.api.score.holder.AbstractScoreHolder.extractJustificationList(AbstractScoreHolder.java:118)
> at org.optaplanner.core.api.score.holder.AbstractScoreHolder.registerConstraintMatch(AbstractScoreHolder.java:88)
> at org.optaplanner.core.api.score.buildin.hardmediumsoft.HardMediumSoftScoreHolder.addMediumConstraintMatch(HardMediumSoftScoreHolder.java:69)
> at org.optaplanner.examples.tennis.solver.Rule_fairAssignmentCountPerTeam1005511081.defaultConsequence(Rule_fairAssignmentCountPerTeam1005511081.java:21)
> at org.optaplanner.examples.tennis.solver.Rule_fairAssignmentCountPerTeam1005511081DefaultConsequenceInvokerGenerated.evaluate(Unknown
> Source)
> at org.optaplanner.examples.tennis.solver.Rule_fairAssignmentCountPerTeam1005511081DefaultConsequenceInvoker.evaluate(Unknown
> Source)
> at org.drools.core.phreak.RuleExecutor.innerFireActivation(RuleExecutor.java:431)
> ... 38 more
> {code}
> See also related discussion in: https://groups.google.com/forum/#!topic/optaplanner-dev/xA6IdGieDpU
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3127) standalone.bat script does not parse JAVA_OPTS containing '|' symbol properly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3127?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-3127:
-------------------------------------------------
Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1145185|https://bugzilla.redhat.com/show_bug.cgi?id=1145185] from ASSIGNED to POST
> standalone.bat script does not parse JAVA_OPTS containing '|' symbol properly
> -----------------------------------------------------------------------------
>
> Key: WFCORE-3127
> URL: https://issues.jboss.org/browse/WFCORE-3127
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 3.0.0.Beta30
> Reporter: Radovan Stancel
> Assignee: Radovan Stancel
> Labels: downstream_dependency
> Original Estimate: 1 day
> Time Spent: 3 hours
> Remaining Estimate: 5 hours
>
> ======================
> Scenario-1)
> ============ With the following line of JAVA_OPTS in "standalone.bat.conf" file
> set "JAVA_OPTS=%JAVA_OPTS% -Dhttp.nonProxyHosts=localhost|127.0.0.1|10.10.10.*"
> {code}
> Error while starting EAP 6.1.1
> C:\jboss-eap-6.1.1\bin>standalone.bat
> Calling "C:\jboss-eap-6.1.1\bin\standalone.conf.bat"
> Setting JAVA property to "C:\JDKs\jdk1.7.0_67\bin\java"
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> {code}
> Scenario-2)
> ============ In Windows "^" sign is the escape character so we tried altering the JAVA_OPTS as following in the "standalone.bat.conf" file:
> set "JAVA_OPTS=%JAVA_OPTS% -Dhttp.nonProxyHosts=localhost^|127.0.0.1^|10.10.10.*"
> Now EAP 6.1.1 server starts but still we see the following messages in windows console:
> {code}
> C:\jboss-eap-6.1.1\bin>standalone.bat
> Calling "C:\jboss-eap-6.1.1\bin\standalone.conf.bat"
> Setting JAVA property to "C:\JDKs\jdk1.7.0_67\bin\java"
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9155) [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory?
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/WFLY-9155?page=com.atlassian.jira.plugin.... ]
Jiri Ondrusek moved WFCORE-3131 to WFLY-9155:
---------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-9155 (was: WFCORE-3131)
Affects Version/s: 11.0.0.Beta1
(was: 3.0.0.Beta30)
> [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory?
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9155
> URL: https://issues.jboss.org/browse/WFLY-9155
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 11.0.0.Beta1
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
>
> In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password.
> Does it really make sense to require it?
> In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3131) [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory?
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3131?page=com.atlassian.jira.plugi... ]
Jiri Ondrusek moved JBEAP-12470 to WFCORE-3131:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3131 (was: JBEAP-12470)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: (was: Migration)
(was: Web (Undertow))
Affects Version/s: 3.0.0.Beta30
(was: 7.0.0.DR9)
> [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory?
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3131
> URL: https://issues.jboss.org/browse/WFCORE-3131
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 3.0.0.Beta30
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
>
> In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password.
> Does it really make sense to require it?
> In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3073) Handle TERM gracefully
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-3073:
-------------------------------------
+1 for the plan to add it as a proper attribute (even if later).
> Handle TERM gracefully
> ----------------------
>
> Key: WFCORE-3073
> URL: https://issues.jboss.org/browse/WFCORE-3073
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ben Parees
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Alpha1
>
>
> The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9126) Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-9126?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-9126:
----------------------------------
There is misconfiguration in deployment: *jboss-ejb3.xml* is ignored because EjbJarParsingDeploymentUnitProcessor search it only in WEB-INF directory, because it is WAR archive.
see https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
Deployment is successful if I move *jboss-ejb3.xml* into WEB-INF.
> Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9126
> URL: https://issues.jboss.org/browse/WFLY-9126
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security, Web (Undertow)
> Reporter: Josef Cacek
> Assignee: Jan Kalina
> Priority: Critical
>
> The WAR deployment fails when it contains EJBs and Servlets with security domains mapped under different names (application-security-domain). The underlying Elytron domain is the same for both subsystems.
> EJB subsystem tries to search also for the domain name which is used in {{jboss-web.xml}} and this lookup fails.
> Sample configuration:
> {code:xml|title=jboss-ejb3.xml}
> <jboss:ejb-jar>
> <assembly-descriptor><s:security>
> <ejb-name>*</ejb-name>
> <s:security-domain>seccontext-whoami</s:security-domain>
> </s:security></assembly-descriptor>
> </jboss:ejb-jar>
> {code}
> {code:xml|title=jboss-web.xml}
> <jboss-web>
> <security-domain>seccontext-web</security-domain>
> </jboss-web>
> {code}
> {code:title=application-security-domain-mapping.cli}
> /subsystem=ejb3/application-security-domain=seccontext-whoami:add( \
> security-domain=ApplicationDomain)
> /subsystem=undertow/application-security-domain=seccontext-web:add( \
> http-authentication-factory=application-http-authentication)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9126) Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-9126?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-9126:
--------------------------------
Assignee: Jan Kalina (was: Stuart Douglas)
> Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9126
> URL: https://issues.jboss.org/browse/WFLY-9126
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security, Web (Undertow)
> Reporter: Josef Cacek
> Assignee: Jan Kalina
> Priority: Critical
>
> The WAR deployment fails when it contains EJBs and Servlets with security domains mapped under different names (application-security-domain). The underlying Elytron domain is the same for both subsystems.
> EJB subsystem tries to search also for the domain name which is used in {{jboss-web.xml}} and this lookup fails.
> Sample configuration:
> {code:xml|title=jboss-ejb3.xml}
> <jboss:ejb-jar>
> <assembly-descriptor><s:security>
> <ejb-name>*</ejb-name>
> <s:security-domain>seccontext-whoami</s:security-domain>
> </s:security></assembly-descriptor>
> </jboss:ejb-jar>
> {code}
> {code:xml|title=jboss-web.xml}
> <jboss-web>
> <security-domain>seccontext-web</security-domain>
> </jboss-web>
> {code}
> {code:title=application-security-domain-mapping.cli}
> /subsystem=ejb3/application-security-domain=seccontext-whoami:add( \
> security-domain=ApplicationDomain)
> /subsystem=undertow/application-security-domain=seccontext-web:add( \
> http-authentication-factory=application-http-authentication)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9111) Some tests from manualmode is unable to start with node0 and node1 properties
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-9111?page=com.atlassian.jira.plugin.... ]
Richard Janík reopened WFLY-9111:
---------------------------------
Still partially present - only Dwm tests are affected, but they still reference only node0, not both as they should.
> Some tests from manualmode is unable to start with node0 and node1 properties
> -----------------------------------------------------------------------------
>
> Key: WFLY-9111
> URL: https://issues.jboss.org/browse/WFLY-9111
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Test Suite
> Reporter: Richard Janík
> Assignee: Richard Janík
> Fix For: 11.0.0.Beta1
>
>
> *Description of problem:*
> Some tests from manualmode is unable to start with node0 and node1 properties.
> It's caused by [these new containers in arquillian.xml|https://github.com/jbossas/jboss-eap7/pull/1935/files#diff...]
> These tests are affected by this issue:
> {noformat}
> org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase
> org.jboss.as.test.manualmode.ejb.client.outbound.connection.security.ElytronRemoteOutboundConnectionTestCase
> org.jboss.as.test.manualmode.ejb.client.reconnect.EJBClientReconnectionTestCase
> org.jboss.as.test.manualmode.jca.connectionlistener.ConnectionListenerTestCase
> org.jboss.as.test.manualmode.jca.workmanager.distributed.DwmAlwaysTestCase
> org.jboss.as.test.manualmode.jca.workmanager.distributed.DwmNeverTestCase
> org.jboss.as.test.manualmode.jca.workmanager.distributed.DwmWatermarkTestCase
> org.jboss.as.test.manualmode.layered.LayeredDistributionTestCase
> org.jboss.as.test.manualmode.messaging.ha.ReplicatedFailoverTestCase
> org.jboss.as.test.manualmode.messaging.ha.SharedStoreFailoverTestCase
> org.jboss.as.test.manualmode.security.OutboundLdapConnectionClientCertTestCase
> org.jboss.as.test.manualmode.security.OutboundLdapConnectionTestCase
> org.jboss.as.test.manualmode.security.SecuredDataSourceTestCase
> org.jboss.as.test.manualmode.security.VaultSystemPropertyOnServerStartTestCase
> org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase
> org.jboss.as.test.manualmode.web.ssl.CertificateRolesLoginModuleTestCase
> org.jboss.as.test.manualmode.web.ssl.DatabaseCertLoginModuleTestCase
> org.jboss.as.test.manualmode.web.ssl.HTTPSWebConnectorTestCase
> org.jboss.as.test.manualmode.weld.extension.BeforeShutdownJNDILookupTestCase
> org.jboss.as.test.manualmode.ws.ReloadRequiringChangesTestCase
> org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase
> {noformat}
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Djboss.dist=/home/mkopecky/playground/eap/7.1.0.ER2.2/jboss-eap-7.1 -DtestLogToFile=false -Dts.noSmoke -Dts.manualmode -Dtest=RemoteOutboundConnectionReconnectTestCase
> *StackTrace:*
> {noformat}
> Caused by: java.util.concurrent.TimeoutException: Managed server was not started within [60] s
> at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:161)
> ... 73 more
> {noformat}
> *Expected results:*
> No errors
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months