[JBoss JIRA] (WFWIP-304) AutoClosable behaviour from MP Config spec is not implemented
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFWIP-304?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFWIP-304:
-----------------------------------
> Jeff Mesnil Based on "Release Notes for MicroProfile Config 1.4", new 1.4 version handles this issue 265. This issue suggests that users use getConfig() (and similar methods) in deployments.
Calling resolver.getConfig() from a deployment is fine (this is intended if CDI injection is not used).
However calling releaseConfig will lead to inconsistencies and unexpected behaviours. The ConfigProviderResolver interface is in the SPI package and is meant for integration, not for user code.
The Config API/SPI is not properly split. We have to take that into consideration when something is technically doable but should not be recommended.
> AutoClosable behaviour from MP Config spec is not implemented
> -------------------------------------------------------------
>
> Key: WFWIP-304
> URL: https://issues.redhat.com/browse/WFWIP-304
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Marek Kopecky
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Current implementation MP Config 1.4 doesn t implement AutoCloseable behaviour on ConfigSource and Converter classes. Developers create [MP issue|https://github.com/eclipse/microprofile-config/issues/136], because these specification requirements seems confusing and unclear to them. [This issue|https://github.com/eclipse/microprofile-config/issues/136] is not approved as a bug from MP community.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-304) AutoClosable behaviour from MP Config spec is not implemented
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFWIP-304?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFWIP-304:
-----------------------------------
What's the point of this use case?
This is incorrect:
{code}
Config config = resolver.getConfig();
response.append(config.getValue("test", String.class));
resolver.releaseConfig(config);
{code}
By releasing the config here, you have release it for the *whole* deployment.
What would happen if another endpoint is using this Config object? Would its configsources and converters be closed?
The lifecycle of a ConfigSource is underspecified. Closing a config source or a converter when a config is released *without* a clear specification of the Config lifecycle and resource ownership will lead to inconsistent behaviour.
> AutoClosable behaviour from MP Config spec is not implemented
> -------------------------------------------------------------
>
> Key: WFWIP-304
> URL: https://issues.redhat.com/browse/WFWIP-304
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Marek Kopecky
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Current implementation MP Config 1.4 doesn t implement AutoCloseable behaviour on ConfigSource and Converter classes. Developers create [MP issue|https://github.com/eclipse/microprofile-config/issues/136], because these specification requirements seems confusing and unclear to them. [This issue|https://github.com/eclipse/microprofile-config/issues/136] is not approved as a bug from MP community.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5080) [DMN Designer] Automatically create InputClause supporting Decisions
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5080?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5080:
-----------------------------------
Description:
I am working on reproducing the use cases from the DMN Method and Style book, and while following their methodology was unable to create the same behavior documented from Trisotech tooling, the so called "Decisions first". In this methodology the practitioner starts from the DRD definition of decisions, inputs and types; and then follows to create the decision tables and calculations from top to bottom.
While creating the decision table that requires an input and a defined output of a "supporting decision", the decision table generated when selecting the expression type of the decision comes with no reference to the required supported decision.
More clarity in this mojo: https://mojo.redhat.com/docs/DOC-1215621#jive_content_id_DRD_Supporting_d...
and in the steps to reproduce.
*_Acceptance criteria_*
- Create a new DMN model
- Add an {{InputData}}
- Add a {{Decision}}, called {{A}}
- Add another {{Decision}}, called {{B}}
- Link the {{InputData}} to {{A}}
- Link the {{B}} to {{A}}
- Edit {{A}} and set its expression to {{DecisionTable}}
- It should have input columns for the {{InputData}} and {{B}}.
- You should be able to use _built in types_ and custom types (including structures).
was:
I am working on reproducing the use cases from the DMN Method and Style book, and while following their methodology was unable to create the same behavior documented from Trisotech tooling, the so called "Decisions first". In this methodology the practitioner starts from the DRD definition of decisions, inputs and types; and then follows to create the decision tables and calculations from top to bottom.
While creating the decision table that requires an input and a defined output of a "supporting decision", the decision table generated when selecting the expression type of the decision comes with no reference to the required supported decision.
More clarity in this mojo: https://mojo.redhat.com/docs/DOC-1215621#jive_content_id_DRD_Supporting_d...
and in the steps to reproduce.
> [DMN Designer] Automatically create InputClause supporting Decisions
> --------------------------------------------------------------------
>
> Key: DROOLS-5080
> URL: https://issues.redhat.com/browse/DROOLS-5080
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2020-02-18 19-06-44.png, Screenshot from 2020-02-18 19-07-07.png
>
>
> I am working on reproducing the use cases from the DMN Method and Style book, and while following their methodology was unable to create the same behavior documented from Trisotech tooling, the so called "Decisions first". In this methodology the practitioner starts from the DRD definition of decisions, inputs and types; and then follows to create the decision tables and calculations from top to bottom.
> While creating the decision table that requires an input and a defined output of a "supporting decision", the decision table generated when selecting the expression type of the decision comes with no reference to the required supported decision.
> More clarity in this mojo: https://mojo.redhat.com/docs/DOC-1215621#jive_content_id_DRD_Supporting_d...
> and in the steps to reproduce.
> *_Acceptance criteria_*
> - Create a new DMN model
> - Add an {{InputData}}
> - Add a {{Decision}}, called {{A}}
> - Add another {{Decision}}, called {{B}}
> - Link the {{InputData}} to {{A}}
> - Link the {{B}} to {{A}}
> - Edit {{A}} and set its expression to {{DecisionTable}}
> - It should have input columns for the {{InputData}} and {{B}}.
> - You should be able to use _built in types_ and custom types (including structures).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-304) AutoClosable behaviour from MP Config spec is not implemented
by Marek Kopecky (Jira)
[ https://issues.redhat.com/browse/WFWIP-304?page=com.atlassian.jira.plugin... ]
Marek Kopecky commented on WFWIP-304:
-------------------------------------
{quote}
In WildFly, the Config object is released when a deployment is undeployed and it would only affect ConfigSource/Converters that needs to deallocate any resources they hold between the undeployment and a server shutdown.
As the MicroProfile Expansion Pack is meant to support only single deployment, this window does not exist.
{quote}
[~jmesnil] Based on "Release Notes for MicroProfile Config 1.4", new 1.4 version handles [this issue 265|https://github.com/eclipse/microprofile-config/issues/265]. This issue suggests that users use getConfig() etc. in deployments etc.
Anyway, please consider use cases like this. Config object is release during end-point call:
{code:java}
@Path("/resolver")
public class ResolverEndPoint {
@GET
public String doGet() {
// prepare response
StringBuilder response = new StringBuilder();
// get resolver
ConfigProviderResolver resolver = ConfigProviderResolver.instance();
// handle original config
Config config = resolver.getConfig();
response.append(config.getValue("test", String.class));
resolver.releaseConfig(config);
// prepare, register and release new config
ConfigBuilder builder = resolver.getBuilder();
Config specificConfig = builder.addDefaultSources().withSources(new ResolverConfigSource()).build();
resolver.registerConfig(specificConfig, ResolverEndPoint.class.getClassLoader());
config = resolver.getConfig();
response.append(config.getValue("test", String.class));
resolver.releaseConfig(config);
// get default config
config = resolver.getConfig();
response.append(config.getValue("test", String.class));
return response.toString();
}
}
{code}
> AutoClosable behaviour from MP Config spec is not implemented
> -------------------------------------------------------------
>
> Key: WFWIP-304
> URL: https://issues.redhat.com/browse/WFWIP-304
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Marek Kopecky
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Current implementation MP Config 1.4 doesn t implement AutoCloseable behaviour on ConfigSource and Converter classes. Developers create [MP issue|https://github.com/eclipse/microprofile-config/issues/136], because these specification requirements seems confusing and unclear to them. [This issue|https://github.com/eclipse/microprofile-config/issues/136] is not approved as a bug from MP community.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-304) AutoClosable behaviour from MP Config spec is not implemented
by Marek Kopecky (Jira)
[ https://issues.redhat.com/browse/WFWIP-304?page=com.atlassian.jira.plugin... ]
Marek Kopecky edited comment on WFWIP-304 at 2/19/20 7:20 AM:
--------------------------------------------------------------
{quote}
In WildFly, the Config object is released when a deployment is undeployed and it would only affect ConfigSource/Converters that needs to deallocate any resources they hold between the undeployment and a server shutdown.
As the MicroProfile Expansion Pack is meant to support only single deployment, this window does not exist.
{quote}
[~jmesnil] Based on "Release Notes for MicroProfile Config 1.4", new 1.4 version handles [this issue 265|https://github.com/eclipse/microprofile-config/issues/265]. This issue suggests that users use getConfig() (and similar methods) in deployments.
Anyway, please consider use cases like this. Config object is release during end-point call:
{code:java}
@Path("/resolver")
public class ResolverEndPoint {
@GET
public String doGet() {
// prepare response
StringBuilder response = new StringBuilder();
// get resolver
ConfigProviderResolver resolver = ConfigProviderResolver.instance();
// handle original config
Config config = resolver.getConfig();
response.append(config.getValue("test", String.class));
resolver.releaseConfig(config);
// prepare, register and release new config
ConfigBuilder builder = resolver.getBuilder();
Config specificConfig = builder.addDefaultSources().withSources(new ResolverConfigSource()).build();
resolver.registerConfig(specificConfig, ResolverEndPoint.class.getClassLoader());
config = resolver.getConfig();
response.append(config.getValue("test", String.class));
resolver.releaseConfig(config);
// get default config
config = resolver.getConfig();
response.append(config.getValue("test", String.class));
return response.toString();
}
}
{code}
was (Author: mkopecky):
{quote}
In WildFly, the Config object is released when a deployment is undeployed and it would only affect ConfigSource/Converters that needs to deallocate any resources they hold between the undeployment and a server shutdown.
As the MicroProfile Expansion Pack is meant to support only single deployment, this window does not exist.
{quote}
[~jmesnil] Based on "Release Notes for MicroProfile Config 1.4", new 1.4 version handles [this issue 265|https://github.com/eclipse/microprofile-config/issues/265]. This issue suggests that users use getConfig() etc. in deployments etc.
Anyway, please consider use cases like this. Config object is release during end-point call:
{code:java}
@Path("/resolver")
public class ResolverEndPoint {
@GET
public String doGet() {
// prepare response
StringBuilder response = new StringBuilder();
// get resolver
ConfigProviderResolver resolver = ConfigProviderResolver.instance();
// handle original config
Config config = resolver.getConfig();
response.append(config.getValue("test", String.class));
resolver.releaseConfig(config);
// prepare, register and release new config
ConfigBuilder builder = resolver.getBuilder();
Config specificConfig = builder.addDefaultSources().withSources(new ResolverConfigSource()).build();
resolver.registerConfig(specificConfig, ResolverEndPoint.class.getClassLoader());
config = resolver.getConfig();
response.append(config.getValue("test", String.class));
resolver.releaseConfig(config);
// get default config
config = resolver.getConfig();
response.append(config.getValue("test", String.class));
return response.toString();
}
}
{code}
> AutoClosable behaviour from MP Config spec is not implemented
> -------------------------------------------------------------
>
> Key: WFWIP-304
> URL: https://issues.redhat.com/browse/WFWIP-304
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Marek Kopecky
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Current implementation MP Config 1.4 doesn t implement AutoCloseable behaviour on ConfigSource and Converter classes. Developers create [MP issue|https://github.com/eclipse/microprofile-config/issues/136], because these specification requirements seems confusing and unclear to them. [This issue|https://github.com/eclipse/microprofile-config/issues/136] is not approved as a bug from MP community.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13127) NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13127?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13127:
-----------------------------------------
Ah, but https://github.com/wildfly/wildfly/pull/12965/files is moving smallrye config to 1.6.1 so this may be fine.
> NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
> --------------------------------------------------------------------
>
> Key: WFLY-13127
> URL: https://issues.redhat.com/browse/WFLY-13127
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenAPI, MP OpenTracing
> Affects Versions: 19.0.0.Beta2
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Critical
>
> I tried running the microprofile-tck/opentracing tests against a config that included the OpenAPI subsystem. It failed with an NPE:
> {code}
> 2020-02-18 16:36:53,302 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /Users/bstansberry/dev/wildfly/wildfly/testsuite/integration/microprofile-tck/opentracing/target/wildfly/standalone/data/content/85/48e223eb8bfcd73f66458e14a0bbc425998a70/content
> 2020-02-18 16:36:53,313 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "opentracing.war" (runtime-name: "opentracing.war")
> 2020-02-18 16:36:54,020 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment opentracing.war
> 2020-02-18 16:36:54,114 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-7) HV000001: Hibernate Validator 6.0.18.Final
> 2020-02-18 16:36:54,330 INFO [org.jboss.weld.Version] (MSC service thread 1-8) WELD-000900: 3.1.3 (Final)
> 2020-02-18 16:36:54,576 INFO [io.smallrye.metrics] (MSC service thread 1-5) MicroProfile: Metrics activated (SmallRye Metrics version: 2.4.0)
> 2020-02-18 16:36:54,992 WARN [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0101: Duplicate servlet mapping /rest/* found
> 2020-02-18 16:36:55,173 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.undertow.host.default-server.default-host./openapi: org.jboss.msc.service.StartException in service org.wildfly.undertow.host.default-server.default-host./openapi: java.lang.NullPointerException
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:66)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.createResponseFromJaxRsMethod(OpenApiAnnotationScanner.java:934)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsMethod(OpenApiAnnotationScanner.java:688)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.lambda$processJaxRsResourceClass$0(OpenApiAnnotationScanner.java:422)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1556)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:420)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.scan(OpenApiAnnotationScanner.java:221)
> at io.smallrye.openapi.runtime.OpenApiProcessor.modelFromAnnotations(OpenApiProcessor.java:72)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:173)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:94)
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:63)
> ... 8 more
> {code}
> I hit this when working on WFLY-13099. I was using a standalone.xml variant equivalent to what Galleon would generate using the cloud-server, h2-default-datasource, microprofile-fault-tolerance, microprofile-jwt and microprofile-openapi layers. It wasn't a slimmed server though.
> OpenApiAnnotationScanner L934 seems to assume 'schema' will not be null. But the 'SchemaFactory.typeToSchema' method seems like it's written such that returning null is a possibility; e.g. L362 in the final 'else' block is doing a null check on the 'schema' var whose value is ultimately returned. (I don't see how else the NPE would happen other than SchemaFactory.typeToSchema returning null.)
>
> I put Critical severity on this because I don't know anything about opentracing.war; i.e. whether it's written in a way that would be a real corner case for OpenAPI. I'm being conservative and assigning a high priority.
> [~ehugonnet] FYI.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5080) [DMN Designer] Automatically create InputClause supporting Decisions
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5080?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5080:
-----------------------------------
Labels: drools-tools (was: )
> [DMN Designer] Automatically create InputClause supporting Decisions
> --------------------------------------------------------------------
>
> Key: DROOLS-5080
> URL: https://issues.redhat.com/browse/DROOLS-5080
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2020-02-18 19-06-44.png, Screenshot from 2020-02-18 19-07-07.png
>
>
> I am working on reproducing the use cases from the DMN Method and Style book, and while following their methodology was unable to create the same behavior documented from Trisotech tooling, the so called "Decisions first". In this methodology the practitioner starts from the DRD definition of decisions, inputs and types; and then follows to create the decision tables and calculations from top to bottom.
> While creating the decision table that requires an input and a defined output of a "supporting decision", the decision table generated when selecting the expression type of the decision comes with no reference to the required supported decision.
> More clarity in this mojo: https://mojo.redhat.com/docs/DOC-1215621#jive_content_id_DRD_Supporting_d...
> and in the steps to reproduce.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5080) [DMN Designer] Automatically create InputClause supporting Decisions
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5080?page=com.atlassian.jira.plug... ]
Michael Anstis moved RHDM-1254 to DROOLS-5080:
----------------------------------------------
Project: Drools (was: Red Hat Decision Manager)
Key: DROOLS-5080 (was: RHDM-1254)
Issue Type: Enhancement (was: Bug)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: DMN Editor
(was: Decision Central)
(was: DMN)
Environment: (was: RHDM 7.6.0)
Steps to Reproduce: (was: 1. Create a DRD
2. Create a Decision node (1)
3. Create a data input and associate to the decision node (1)
4. Create a Decision node (2)
5. Create 2 data inputs and associate to the decision node (2)
6. Associate Decision 2 to Decision 1.
7. Edit decision 1 and set Decision Table as the expression type
Expected to see 2 columns: Data Input 1 and Decision 2; with output Decision 1.
Actual: Only Data Input 1 is available.)
Affects Version/s: 7.33.0.Final
(was: 7.6.0.GA)
QE Status: NEW
> [DMN Designer] Automatically create InputClause supporting Decisions
> --------------------------------------------------------------------
>
> Key: DROOLS-5080
> URL: https://issues.redhat.com/browse/DROOLS-5080
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2020-02-18 19-06-44.png, Screenshot from 2020-02-18 19-07-07.png
>
>
> I am working on reproducing the use cases from the DMN Method and Style book, and while following their methodology was unable to create the same behavior documented from Trisotech tooling, the so called "Decisions first". In this methodology the practitioner starts from the DRD definition of decisions, inputs and types; and then follows to create the decision tables and calculations from top to bottom.
> While creating the decision table that requires an input and a defined output of a "supporting decision", the decision table generated when selecting the expression type of the decision comes with no reference to the required supported decision.
> More clarity in this mojo: https://mojo.redhat.com/docs/DOC-1215621#jive_content_id_DRD_Supporting_d...
> and in the steps to reproduce.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5080) [DMN Designer] Automatically create InputClause supporting Decisions
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5080?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5080:
-----------------------------------
Tester: Jozef Marko
Story Points: 3
Sprint: 2020 Week 07-09 (from Feb 10)
> [DMN Designer] Automatically create InputClause supporting Decisions
> --------------------------------------------------------------------
>
> Key: DROOLS-5080
> URL: https://issues.redhat.com/browse/DROOLS-5080
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2020-02-18 19-06-44.png, Screenshot from 2020-02-18 19-07-07.png
>
>
> I am working on reproducing the use cases from the DMN Method and Style book, and while following their methodology was unable to create the same behavior documented from Trisotech tooling, the so called "Decisions first". In this methodology the practitioner starts from the DRD definition of decisions, inputs and types; and then follows to create the decision tables and calculations from top to bottom.
> While creating the decision table that requires an input and a defined output of a "supporting decision", the decision table generated when selecting the expression type of the decision comes with no reference to the required supported decision.
> More clarity in this mojo: https://mojo.redhat.com/docs/DOC-1215621#jive_content_id_DRD_Supporting_d...
> and in the steps to reproduce.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months