[JBoss JIRA] (DROOLS-1167) Comparison operation error
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1167?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1167:
-------------------------------------
Sorry, but it's impossible to debug your issue without a complete reproducer. Can you provide one, or at least send the source code of your domain objects?
> Comparison operation error
> --------------------------
>
> Key: DROOLS-1167
> URL: https://issues.jboss.org/browse/DROOLS-1167
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.4.0.Final
> Environment: OracleLinux 6, Java 7/8
> Reporter: Pierangelo Repetti
> Assignee: Mario Fusco
> Attachments: failing_rule.drl
>
>
> I migrated a set of rules from version 5.4 to 6.3. All rules are "Technical rules".
> After migration, I get the following error
> _Unable to Analyse Expression value != 0: [Error: Comparison operation requires compatible types. Found class org.mvel2.util.MethodStub and class java.lang.Integer] [Near : {... value != 0 ....}] ^ [Line: 29, Column: 9]
> _
> on the following line of a rule
> _$imponibile : RuleElement(label=="IMPONIBILE", value != 0, imponibile : value, imponibile_artmap : artmap);_
> RuleElement is a model class (loaded as a dependency) and declares a value attribute like
> _private Double value;_
> The same rule compiled without problems in 5.4.
> Thanks
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1167) Comparison operation error
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1167?page=com.atlassian.jira.plugi... ]
Mario Fusco reassigned DROOLS-1167:
-----------------------------------
Assignee: Mario Fusco
> Comparison operation error
> --------------------------
>
> Key: DROOLS-1167
> URL: https://issues.jboss.org/browse/DROOLS-1167
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.4.0.Final
> Environment: OracleLinux 6, Java 7/8
> Reporter: Pierangelo Repetti
> Assignee: Mario Fusco
> Attachments: failing_rule.drl
>
>
> I migrated a set of rules from version 5.4 to 6.3. All rules are "Technical rules".
> After migration, I get the following error
> _Unable to Analyse Expression value != 0: [Error: Comparison operation requires compatible types. Found class org.mvel2.util.MethodStub and class java.lang.Integer] [Near : {... value != 0 ....}] ^ [Line: 29, Column: 9]
> _
> on the following line of a rule
> _$imponibile : RuleElement(label=="IMPONIBILE", value != 0, imponibile : value, imponibile_artmap : artmap);_
> RuleElement is a model class (loaded as a dependency) and declares a value attribute like
> _private Double value;_
> The same rule compiled without problems in 5.4.
> Thanks
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1223) java.lang.NullPointerException druing Condition Evaluation
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1223?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1223:
-------------------------------------
It seems that you're evaluating a constraint with a null value. Probably the first round sets that value to null and during the second one the evaluation of a constraint trying to dereference that value throws the NPE? If my guess is correct this is the normal behaviour since Drools doesn't catch/manage exceptions thrown during user's constraint evaluation, mainly for performance reason. However it's impossible for me to figure out what's going on there without a reproducer of your problem. Can you please attach one to this ticket or send a pull request to drools project?
> java.lang.NullPointerException druing Condition Evaluation
> ----------------------------------------------------------
>
> Key: DROOLS-1223
> URL: https://issues.jboss.org/browse/DROOLS-1223
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Rodrigo Doria Medina
> Assignee: Mario Fusco
>
> {panel:title=Code}
> Caused by: java.lang.NullPointerException
> at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
> at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
> at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> {panel}
> This happens when running more than once the same piece of data. (It happens from the second time).
> I have no clue what could that be. When running the first time everything computes as expected.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1223) java.lang.NullPointerException druing Condition Evaluation
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1223?page=com.atlassian.jira.plugi... ]
Mario Fusco reassigned DROOLS-1223:
-----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> java.lang.NullPointerException druing Condition Evaluation
> ----------------------------------------------------------
>
> Key: DROOLS-1223
> URL: https://issues.jboss.org/browse/DROOLS-1223
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Rodrigo Doria Medina
> Assignee: Mario Fusco
>
> {panel:title=Code}
> Caused by: java.lang.NullPointerException
> at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
> at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
> at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> {panel}
> This happens when running more than once the same piece of data. (It happens from the second time).
> I have no clue what could that be. When running the first time everything computes as expected.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6698) Do not flag migrate operations as runtime-only
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6698?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil closed WFLY-6698.
-----------------------------
Resolution: Rejected
> Do not flag migrate operations as runtime-only
> ----------------------------------------------
>
> Key: WFLY-6698
> URL: https://issues.jboss.org/browse/WFLY-6698
> Project: WildFly
> Issue Type: Bug
> Components: IIOP, JMS, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> The :migrate operation for the legacy subsystems (messaging, web, iiop) are erroneously flagged as runtime-only.
> They impact the management model and do not require any runtime (they are not running if the server is not in admin-only mode).
> This is harmless for the time being but when WFCORE-1586 will be fixed, these operations would no longer be registered in the profiles if they remain flagged with runtime-only
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1635) Write attribute on a new deployment scanner fails in batch
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1635?page=com.atlassian.jira.plugi... ]
Chao Wang updated WFCORE-1635:
------------------------------
Component/s: Domain Management
> Write attribute on a new deployment scanner fails in batch
> ----------------------------------------------------------
>
> Key: WFCORE-1635
> URL: https://issues.jboss.org/browse/WFCORE-1635
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Affects Versions: 3.0.0.Alpha3
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> Creating a new deployment-scanner and altering it's attribute fails if done in single batch. Running the commands without batch or running batch on CLI embed-server works fine.
> *reproduce*
> {noformat}
> batch
> /subsystem=deployment-scanner/scanner=scan:add(path=log, relative-to="jboss.server.base.dir", auto-deploy-exploded=false, scan-enabled=false)
> /subsystem=deployment-scanner/scanner=scan:write-attribute(name=scan-interval, value=6000)
> run-batch
> {noformat}
> fails with
> {noformat}
> 08:09:19,076 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "deployment-scanner"),
> ("scanner" => "scan")
> ]): java.lang.IllegalStateException
> at org.jboss.as.server.deployment.scanner.DeploymentScannerService.getValue(DeploymentScannerService.java:234)
> at org.jboss.as.server.deployment.scanner.DeploymentScannerService.getValue(DeploymentScannerService.java:62)
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
> at org.jboss.as.controller.OperationContextImpl$OperationContextServiceController.getValue(OperationContextImpl.java:2282)
> at org.jboss.as.server.deployment.scanner.AbstractWriteAttributeHandler.applyUpdateToRuntime(AbstractWriteAttributeHandler.java:58)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(AccessController.java:686)
> at javax.security.auth.Subject.doAs(Subject.java:569)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> using the embed server works
> {noformat}
> embed-server
> batch
> /subsystem=deployment-scanner/scanner=scan:add(path=log, relative-to="jboss.server.base.dir", auto-deploy-exploded=false, scan-enabled=false)
> /subsystem=deployment-scanner/scanner=scan:write-attribute(name=scan-interval, value=6000)
> run-batch
> {noformat}
> Setting only as minor as there is no real use case behind this (scan-interval can be set while adding a new scanner) - run into it quite accidentally. No regression against previous release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1635) Write attribute on a new deployment scanner fails in batch
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1635?page=com.atlassian.jira.plugi... ]
Chao Wang commented on WFCORE-1635:
-----------------------------------
In the batch circumstance, sometimes IllegalStateException happens because the new deployment service is not up yet when it tries to update scanners.
Here are two existing solutions:
1. Add same [waitForService() | https://github.com/wildfly/wildfly/blob/9de9217e0106da10c7d05228bcf0559c8...] method before controller.getValue(); But it's marked nasty workaround.
2. In case that new deployment scanner service is not up yet, return true to put the server in a reload-required state.
> Write attribute on a new deployment scanner fails in batch
> ----------------------------------------------------------
>
> Key: WFCORE-1635
> URL: https://issues.jboss.org/browse/WFCORE-1635
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner
> Affects Versions: 3.0.0.Alpha3
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> Creating a new deployment-scanner and altering it's attribute fails if done in single batch. Running the commands without batch or running batch on CLI embed-server works fine.
> *reproduce*
> {noformat}
> batch
> /subsystem=deployment-scanner/scanner=scan:add(path=log, relative-to="jboss.server.base.dir", auto-deploy-exploded=false, scan-enabled=false)
> /subsystem=deployment-scanner/scanner=scan:write-attribute(name=scan-interval, value=6000)
> run-batch
> {noformat}
> fails with
> {noformat}
> 08:09:19,076 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "deployment-scanner"),
> ("scanner" => "scan")
> ]): java.lang.IllegalStateException
> at org.jboss.as.server.deployment.scanner.DeploymentScannerService.getValue(DeploymentScannerService.java:234)
> at org.jboss.as.server.deployment.scanner.DeploymentScannerService.getValue(DeploymentScannerService.java:62)
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
> at org.jboss.as.controller.OperationContextImpl$OperationContextServiceController.getValue(OperationContextImpl.java:2282)
> at org.jboss.as.server.deployment.scanner.AbstractWriteAttributeHandler.applyUpdateToRuntime(AbstractWriteAttributeHandler.java:58)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(AccessController.java:686)
> at javax.security.auth.Subject.doAs(Subject.java:569)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> using the embed server works
> {noformat}
> embed-server
> batch
> /subsystem=deployment-scanner/scanner=scan:add(path=log, relative-to="jboss.server.base.dir", auto-deploy-exploded=false, scan-enabled=false)
> /subsystem=deployment-scanner/scanner=scan:write-attribute(name=scan-interval, value=6000)
> run-batch
> {noformat}
> Setting only as minor as there is no real use case behind this (scan-interval can be set while adding a new scanner) - run into it quite accidentally. No regression against previous release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1635) Write attribute on a new deployment scanner fails in batch
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1635?page=com.atlassian.jira.plugi... ]
Chao Wang moved JBEAP-5156 to WFCORE-1635:
------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1635 (was: JBEAP-5156)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Deployment Scanner
(was: Deployment Scanner)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 3.0.0.Alpha3
(was: 7.0.1.CR1)
> Write attribute on a new deployment scanner fails in batch
> ----------------------------------------------------------
>
> Key: WFCORE-1635
> URL: https://issues.jboss.org/browse/WFCORE-1635
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner
> Affects Versions: 3.0.0.Alpha3
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> Creating a new deployment-scanner and altering it's attribute fails if done in single batch. Running the commands without batch or running batch on CLI embed-server works fine.
> *reproduce*
> {noformat}
> batch
> /subsystem=deployment-scanner/scanner=scan:add(path=log, relative-to="jboss.server.base.dir", auto-deploy-exploded=false, scan-enabled=false)
> /subsystem=deployment-scanner/scanner=scan:write-attribute(name=scan-interval, value=6000)
> run-batch
> {noformat}
> fails with
> {noformat}
> 08:09:19,076 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "deployment-scanner"),
> ("scanner" => "scan")
> ]): java.lang.IllegalStateException
> at org.jboss.as.server.deployment.scanner.DeploymentScannerService.getValue(DeploymentScannerService.java:234)
> at org.jboss.as.server.deployment.scanner.DeploymentScannerService.getValue(DeploymentScannerService.java:62)
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
> at org.jboss.as.controller.OperationContextImpl$OperationContextServiceController.getValue(OperationContextImpl.java:2282)
> at org.jboss.as.server.deployment.scanner.AbstractWriteAttributeHandler.applyUpdateToRuntime(AbstractWriteAttributeHandler.java:58)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(AccessController.java:686)
> at javax.security.auth.Subject.doAs(Subject.java:569)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> using the embed server works
> {noformat}
> embed-server
> batch
> /subsystem=deployment-scanner/scanner=scan:add(path=log, relative-to="jboss.server.base.dir", auto-deploy-exploded=false, scan-enabled=false)
> /subsystem=deployment-scanner/scanner=scan:write-attribute(name=scan-interval, value=6000)
> run-batch
> {noformat}
> Setting only as minor as there is no real use case behind this (scan-interval can be set while adding a new scanner) - run into it quite accidentally. No regression against previous release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-777) Erroneous Error message (should actually be a warning, and reworded)
by Alex Oliveira (JIRA)
[ https://issues.jboss.org/browse/WFLY-777?page=com.atlassian.jira.plugin.s... ]
Alex Oliveira commented on WFLY-777:
------------------------------------
Same for me. AnyCertVerifier - smartcard auth, JBoss EAP 6.4.0.
> Erroneous Error message (should actually be a warning, and reworded)
> --------------------------------------------------------------------
>
> Key: WFLY-777
> URL: https://issues.jboss.org/browse/WFLY-777
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jess Sightler
> Assignee: Anil Saldanha
>
> When no security domain is specified for BaseCertLoginModule, this log message is printed to the console:
> "The JSSE security domain other is not valid. All authentication using this login module will fail!"
> I believe that whether this is actually the case ultimately depends on the verifier. In the case of AnyCertVerifier (or any customer Verifier), the security domain will not be necessary. This means that the login module will actually work, despite the above message to the contrary.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months