[JBoss JIRA] (WFLY-11261) CLI unable to refer jberet resources after run PurgeBatchlet
by Norito Agetsuma (Jira)
[ https://issues.jboss.org/browse/WFLY-11261?page=com.atlassian.jira.plugin... ]
Norito Agetsuma moved JBEAP-15751 to WFLY-11261:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-11261 (was: JBEAP-15751)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Batch
(was: Batch)
Affects Version/s: 14.0.0.Final
(was: 7.1.4.GA)
> CLI unable to refer jberet resources after run PurgeBatchlet
> ------------------------------------------------------------
>
> Key: WFLY-11261
> URL: https://issues.jboss.org/browse/WFLY-11261
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 14.0.0.Final
> Reporter: Norito Agetsuma
> Assignee: Cheng Fang
> Priority: Major
> Attachments: jberet-sample.zip
>
>
> It's not possible to refer jberet runtime resource after execute org.jberet.repository.PurgeBatchlet with batch property "purgeJobsByNames".
> {code:title=jboss-cli output before execute PurgeBatchlet}
> [standalone@localhost:9990 /] /deployment=jberet-sample.war/subsystem=batch-jberet/job=dummy-job:read-resource(include-runtime=true,recursive=true)
> {
> "outcome" => "success",
> "result" => {
> "instance-count" => 1,
> "job-xml-names" => ["dummy-job.xml"],
> "running-executions" => 0,
> "execution" => {"1" => {
> "batch-status" => "COMPLETED",
> "create-time" => "2018-10-31T14:54:27.297+0900",
> "end-time" => "2018-10-31T14:54:27.343+0900",
> "exit-status" => "COMPLETED",
> "instance-id" => 1L,
> "last-updated-time" => "2018-10-31T14:54:27.343+0900",
> "start-time" => "2018-10-31T14:54:27.306+0900"
> }}
> }
> }
> {code}
> {code:title=jboss-cli output after PurgeBatchlet}
> /deployment=jberet-sample.war/subsystem=batch-jberet/job=dummy-job:read-resource(include-runtime=true,recursive=true)
> {
> "outcome" => "failed",
> "rolled-back" => true
> }
> {code}
> Then output following server.log
> {code}
> 14:55:23,104 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "jberet-sample.war"),
> ("subsystem" => "batch-jberet"),
> ("job" => "dummy-job"),
> ("execution" => "1")
> ]): javax.batch.operations.NoSuchJobExecutionException: JBERET000604: No job execution with id 1
> at org.jberet.operations.AbstractJobOperator.getJobExecutionImpl(AbstractJobOperator.java:354)
> at org.jberet.operations.AbstractJobOperator.getJobInstance(AbstractJobOperator.java:310)
> at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobInstance(JobOperatorService.java:281)
> at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobExecution(JobOperatorService.java:308)
> at org.wildfly.extension.batch.jberet.deployment.BatchJobExecutionResourceDefinition$JobExecutionOperationStepHandler.updateModel(BatchJobExecutionResourceDefinition.java:200)
> at org.wildfly.extension.batch.jberet.deployment.JobOperationReadOnlyStepHandler.execute(JobOperationReadOnlyStepHandler.java:47)
> at org.wildfly.extension.batch.jberet.deployment.JobOperationStepHandler.executeRuntime(JobOperationStepHandler.java:74)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Even though delete JobExecution in JobRepository, JobExecution id "1" still show by JBoss CLI.
> {code:title=jboss-cli output}
> [standalone@localhost:9990 /] /deployment=jberet-sample.war/subsystem=batch-jberet/job=dummy-job:read-resource
> {
> "outcome" => "success",
> "result" => {"execution" => {"1" => undefined}}
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3193) UX to support selection of multiple data/domain object instances
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3193?page=com.atlassian.jira.plugi... ]
Klara Kufova edited comment on DROOLS-3193 at 10/31/18 4:57 AM:
----------------------------------------------------------------
[~uxdlc], it is currently not possible to reorder columns or rows once they are created, and as far as I know, such feature is not even planned in the future (but I may be wrong). It is however possible to insert a column or a row basically anywhere in the table, which is, in my opinion, sufficient. Do you agree?
Columns are not numbered, but rows are.
Regarding the last image you posted, in the current implementation, it is not possible to achieve it (all columns whose instance type is {{Dispute}} would get merged together, so there would be only one header row called {{Dispute}} and the header row below would be divided into six columns as in the image). You need to introduce an alias to create this structure (such as {{First dispute}}, {{Second dispute}}, {{Third dispute}}). But otherwise, it is a valid grid.
was (Author: kkufova):
[~uxdlc], it is currently not possible to reorder columns or rows once they are created, and I don't think such feature is even planned in the future. It is however possible to insert a column or a row basically anywhere in the table, which is, in my opinion, sufficient. Do you agree? As far as I know,
Columns are not numbered, but rows are.
Regarding the last image you posted, in the current implementation, it is not possible to achieve it (all columns whose instance type is {{Dispute}} would get merged together, so there would be only one header row called {{Dispute}} and the header row below would be divided into six columns as in the image). You need to introduce an alias to create this structure (such as {{First dispute}}, {{Second dispute}}, {{Third dispute}}). But otherwise, it is a valid grid.
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-3193
> URL: https://issues.jboss.org/browse/DROOLS-3193
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2018-10-30 at 10.50.55 AM.png
>
>
> As user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3193) UX to support selection of multiple data/domain object instances
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3193?page=com.atlassian.jira.plugi... ]
Klara Kufova commented on DROOLS-3193:
--------------------------------------
[~uxdlc], it is currently not possible to reorder columns or rows once they are created, and I don't think such feature is even planned in the future. It is however possible to insert a column or a row basically anywhere in the table, which is, in my opinion, sufficient. Do you agree? As far as I know,
Columns are not numbered, but rows are.
Regarding the last image you posted, in the current implementation, it is not possible to achieve it (all columns whose instance type is {{Dispute}} would get merged together, so there would be only one header row called {{Dispute}} and the header row below would be divided into six columns as in the image). You need to introduce an alias to create this structure (such as {{First dispute}}, {{Second dispute}}, {{Third dispute}}). But otherwise, it is a valid grid.
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-3193
> URL: https://issues.jboss.org/browse/DROOLS-3193
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2018-10-30 at 10.50.55 AM.png
>
>
> As user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3209) Datasource Management Errors after changing Wildfly management to HTTPS and 9993
by Marijan Cavar (Jira)
Marijan Cavar created DROOLS-3209:
-------------------------------------
Summary: Datasource Management Errors after changing Wildfly management to HTTPS and 9993
Key: DROOLS-3209
URL: https://issues.jboss.org/browse/DROOLS-3209
Project: Drools
Issue Type: Bug
Affects Versions: 7.12.0.Final
Environment: RHEL 7.5, Wildfly 11.0.0.Final, Drools 7.12.0.Final.
Reporter: Marijan Cavar
Assignee: Mario Fusco
I have enabled HTTPS on Drools application and Wildfly Management port. Seems to work everything fine if I connect to Wildfly management port (9993) and application port 8443. But after the application comes up, app is throwing errors about reaching datasource, and that is management address and port of an Application server. I have changed the configuration in WEB-INF/classes/datasource-management.properties of WAR file to:
datasource.management.wildfly.host=10.20.30.237
datasource.management.wildfly.port=9993
Error I am getting in the server.log:
[org.kie.workbench.common.screens.datasource.management.backend.integration.wildfly.WildflyBaseClient] (pool-7-thread-1) It was not possible to open connection to Wildfly/EAP server.: java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to http-remoting://10.20.30.237:9993. The connection failed.
It seems to me that the problem is related with the "http-remoting" that app is still using. How to change this to "https-remoting"?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3038) [DMN Designer] Added type can not be resolved
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3038?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-3038:
-------------------------------------
[~manstis] [~dadossan] [~karreiro] Hi, the creation of new file in our designer works fine now, however if I import DMN model from Trisotech, move some element and save, there appears errors about non resolvable data type. Is this something we want to fix, or this is something we won't support.
- DMN-1.1 [^Loan Pre-Qualification (1).dmn]
- DMN-1.2 [^Loan Pre-Qualification (2).dmn]
> [DMN Designer] Added type can not be resolved
> ---------------------------------------------
>
> Key: DROOLS-3038
> URL: https://issues.jboss.org/browse/DROOLS-3038
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Blocker
> Labels: drools-tools
> Attachments: DROOLS-3038.dmn, Loan Pre-Qualification (1).dmn, Loan Pre-Qualification (2).dmn, Screenshot from 2018-09-26 12-57-20.png, Screenshot from 2018-09-26 12-58-02.png, Screenshot from 2018-09-26 12-58-12.png, a_dmn.dmn
>
>
> {{12:53:34,884 ERROR [org.kie.dmn.core.compiler.DMNCompilerImpl] (EJB default - 3) Unable to resolve type reference 'tNum' on node 'Decision-1'}} is error shown to user after reopening DMN model with used new defined item definition.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3038) [DMN Designer] Added type can not be resolved
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3038?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3038:
--------------------------------
Attachment: Loan Pre-Qualification (2).dmn
Loan Pre-Qualification (1).dmn
> [DMN Designer] Added type can not be resolved
> ---------------------------------------------
>
> Key: DROOLS-3038
> URL: https://issues.jboss.org/browse/DROOLS-3038
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Blocker
> Labels: drools-tools
> Attachments: DROOLS-3038.dmn, Loan Pre-Qualification (1).dmn, Loan Pre-Qualification (2).dmn, Screenshot from 2018-09-26 12-57-20.png, Screenshot from 2018-09-26 12-58-02.png, Screenshot from 2018-09-26 12-58-12.png, a_dmn.dmn
>
>
> {{12:53:34,884 ERROR [org.kie.dmn.core.compiler.DMNCompilerImpl] (EJB default - 3) Unable to resolve type reference 'tNum' on node 'Decision-1'}} is error shown to user after reopening DMN model with used new defined item definition.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months