February 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4739) Support Camel integration test with the executable model

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4739?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-4739: -------------------------------------- Story Points: 4 > Support Camel integration test with the executable model > -------------------------------------------------------- > > Key: DROOLS-4739 > URL: https://issues.redhat.com/browse/DROOLS-4739 > Project: Drools > Issue Type: Enhancement > Reporter: Luca Molteni > Assignee: Toshiya Kobayashi > Priority: Major > Labels: good-first-issue > > AbstractRemoteIntegrationTest > in drools-jbpm-integration > Still doesn't support the executable model -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2317) FEEL Syntax error on function(bkm) containing `for` keyword

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-2317?page=com.atlassian.jira.plug... ] Matteo Mortari edited comment on DROOLS-2317 at 2/12/20 6:28 PM: ----------------------------------------------------------------- [~lukasz.hanik] The symptoms are the same, but I can confirm is actually a different issue. The problem in your uploaded DMN model, is that for the Decision {{Encapsulated input}} the type {{Any}} is specified, hence when later invoking the FEEL qualified expression {code} Encapsulated input. (...) {code} no assumption can be made if {{Input for user}} is a property of the parent or not, given it's indeed specified as of type {{Any}}. Now, because it contains a (potentially) reserved keyword, the keyword "for", the parser cannot go beyond the DMN spec hence throws the error. I can confirm once you properly annotate type, the error disappears, as expected. I notice you are using the Trisotech editor, creating the types based on the current design of the model can be achieved with the "Create Output Data type" menu entry, if I do so indeed as confirmed the error is disappeared as I would expect. Further, I am led to believe the model will just work as expected, example: !screenshot-1.png! and for the records these are the types I believe correct based on the fact the InputData is of type FEEL string: !screenshot-3.png! which are assigned to the "Encapsulated input" decision which was the one lacking proper type annotation: !screenshot-2.png! Please notice this is only required because dynamic inference cannot go against the spec (in this case keyword "for" is used as part of a name in a property, but the specified type was "Any"), but indeed once properly annotating the type, it will work just fine. Can you confirm this will solve your issue? Also for the next time, please try to avoid commenting on an months old jira, it would be best to just open a new one and cross-link if desired; I appreciate you did the research, I'm just trying to avoid comments which might go lost if put on a Resolved months old issue ;) Please let us know was (Author: tari_manga): [~lukasz.hanik] The symptoms are the same, but I can confirm is actually a different issue. The problem in your uploaded DMN model, is that for the Decision {{Encapsulated input}} the type {{Any}} is specified, hence when later invoking the FEEL qualified expression {code} Encapsulated input. (...) {code} no assumption can be made if {{Input for user}} is a property of the parent or not, given it's indeed specified as of type {{Any}}. Now, because it contains a (potentially) reserved keyword, the keyword "for", the parser cannot go beyond the DMN spec hence throws the error. I can confirm once you properly annotate type, the error disappears, as expected. I notice you are using the Trisotech editor, creating the types based on the current design of the model can be achieved with the "Create Output Data type" menu entry, if I do so indeed as confirmed the error is disappeared as I would expect. Further, I am led to believe the model will just work as expected, example: !screenshot-1.png! and for the records these are the types I believe correct based on the fact the InputData is of type FEEL string: !screenshot-3.png! which are assigned to the "Encapsulated input" decision which was the one lacking proper type annotation: !screenshot-2.png! Please notice this is only required because dynamic inference cannot go against the spec, but indeed once properly annotating the type, it will work just fine. Can you confirm this will solve your issue? Also for the next time, please try to avoid commenting on an months old jira, it would be best to just open a new one and cross-link if desired; I appreciate you did the research, I'm just trying to avoid comments which might go lost if put on a Resolved months old issue ;) Please let us know > FEEL Syntax error on function(bkm) containing `for` keyword > ----------------------------------------------------------- > > Key: DROOLS-2317 > URL: https://issues.redhat.com/browse/DROOLS-2317 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Fedor Gavrilov > Priority: Major > Attachments: DROOLS-2317.dmn, Dynamic composition.dmn, screenshot-1.png, screenshot-2.png, screenshot-3.png > > > Attached model > {code:java} > Error compiling FEEL expression 'for item in Order.items return Federal Tax for Item( item )' for name 'Calculate Federal Taxes' on node 'Calculate Federal Taxes': syntax error near 'for' > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2317) FEEL Syntax error on function(bkm) containing `for` keyword

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-2317?page=com.atlassian.jira.plug... ] Matteo Mortari commented on DROOLS-2317: ---------------------------------------- [~lukasz.hanik] The symptoms are the same, but I can confirm is actually a different issue. The problem in your uploaded DMN model, is that for the Decision {{Encapsulated input}} the type {{Any}} is specified, hence when later invoking the FEEL qualified expression {code} Encapsulated input. (...) {code} no assumption can be made if {{Input for user}} is a property of the parent or not, given it's indeed specified as of type {{Any}}. Now, because it contains a (potentially) reserved keyword, the keyword "for", the parser cannot go beyond the DMN spec hence throws the error. I can confirm once you properly annotate type, the error disappears, as expected. I notice you are using the Trisotech editor, creating the types based on the current design of the model can be achieved with the "Create Output Data type" menu entry, if I do so indeed as confirmed the error is disappeared as I would expect. Further, I am led to believe the model will just work as expected, example: !screenshot-1.png! and for the records these are the types I believe correct based on the fact the InputData is of type FEEL string: !screenshot-3.png! which are assigned to the "Encapsulated input" decision which was the one lacking proper type annotation: !screenshot-2.png! Please notice this is only required because dynamic inference cannot go against the spec, but indeed once properly annotating the type, it will work just fine. Can you confirm this will solve your issue? Also for the next time, please try to avoid commenting on an months old jira, it would be best to just open a new one and cross-link if desired; I appreciate you did the research, I'm just trying to avoid comments which might go lost if put on a Resolved months old issue ;) Please let us know > FEEL Syntax error on function(bkm) containing `for` keyword > ----------------------------------------------------------- > > Key: DROOLS-2317 > URL: https://issues.redhat.com/browse/DROOLS-2317 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Fedor Gavrilov > Priority: Major > Attachments: DROOLS-2317.dmn, Dynamic composition.dmn, screenshot-1.png, screenshot-2.png, screenshot-3.png > > > Attached model > {code:java} > Error compiling FEEL expression 'for item in Order.items return Federal Tax for Item( item )' for name 'Calculate Federal Taxes' on node 'Calculate Federal Taxes': syntax error near 'for' > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2317) FEEL Syntax error on function(bkm) containing `for` keyword

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-2317?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-2317: ----------------------------------- Attachment: screenshot-3.png > FEEL Syntax error on function(bkm) containing `for` keyword > ----------------------------------------------------------- > > Key: DROOLS-2317 > URL: https://issues.redhat.com/browse/DROOLS-2317 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Fedor Gavrilov > Priority: Major > Attachments: DROOLS-2317.dmn, Dynamic composition.dmn, screenshot-1.png, screenshot-2.png, screenshot-3.png > > > Attached model > {code:java} > Error compiling FEEL expression 'for item in Order.items return Federal Tax for Item( item )' for name 'Calculate Federal Taxes' on node 'Calculate Federal Taxes': syntax error near 'for' > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2317) FEEL Syntax error on function(bkm) containing `for` keyword

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-2317?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-2317: ----------------------------------- Attachment: screenshot-2.png > FEEL Syntax error on function(bkm) containing `for` keyword > ----------------------------------------------------------- > > Key: DROOLS-2317 > URL: https://issues.redhat.com/browse/DROOLS-2317 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Fedor Gavrilov > Priority: Major > Attachments: DROOLS-2317.dmn, Dynamic composition.dmn, screenshot-1.png, screenshot-2.png > > > Attached model > {code:java} > Error compiling FEEL expression 'for item in Order.items return Federal Tax for Item( item )' for name 'Calculate Federal Taxes' on node 'Calculate Federal Taxes': syntax error near 'for' > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2317) FEEL Syntax error on function(bkm) containing `for` keyword

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-2317?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-2317: ----------------------------------- Attachment: screenshot-1.png > FEEL Syntax error on function(bkm) containing `for` keyword > ----------------------------------------------------------- > > Key: DROOLS-2317 > URL: https://issues.redhat.com/browse/DROOLS-2317 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Fedor Gavrilov > Priority: Major > Attachments: DROOLS-2317.dmn, Dynamic composition.dmn, screenshot-1.png > > > Attached model > {code:java} > Error compiling FEEL expression 'for item in Order.items return Federal Tax for Item( item )' for name 'Calculate Federal Taxes' on node 'Calculate Federal Taxes': syntax error near 'for' > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4845) Allow Remote Debug Connections on Java 9+ With StandaloneCommandBuilder

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-4845?page=com.atlassian.jira.plug... ] James Perkins reassigned WFCORE-4845: ------------------------------------- Assignee: (was: Jeff Mesnil) > Allow Remote Debug Connections on Java 9+ With StandaloneCommandBuilder > ----------------------------------------------------------------------- > > Key: WFCORE-4845 > URL: https://issues.redhat.com/browse/WFCORE-4845 > Project: WildFly Core > Issue Type: Enhancement > Components: Launcher > Reporter: Josh Fisher > Priority: Minor > > When using StandaloneCommandBuilder#setDebug method to set the debug VM argument it will use this format: > -agentlib:jdwp=transport=dt_socket,server=y,suspend=$suspend,address=$debugPort > On Java 9+, this will only accept connections from the localhost, while in Java 8 this will accept connections from any host. It is possible to support remote connections on Java 9+ by configuring the argument in the Java options list instead of using setDebug as a workaround. > While debug connections from remote hosts are not especially common, there are some use cases where it may be desired. For consistency between Java versions, we should consider using the wildcard "*" host so the debug argument format is: > -agentlib:jdwp=transport=dt_socket,server=y,suspend=$suspend,address=*:$debugPort > > I believe one way this could be achieved is by modifying the DEBUG_FORMAT to: > DEBUG_FORMAT = "-agentlib:jdwp=transport=dt_socket,server=y,suspend=%s,address=%s" > then in setDebug check the environment VM and format the address accordingly. > {code:java} > public StandaloneCommandBuilder setDebug(boolean suspend, int port) { > final String address; > if (environment.getJvm().isModular()){ > address = "*:" + port; > } else { > address = String.valueOf(port); > } > debugArg = String.format(DEBUG_FORMAT, (suspend ? "y" : "n"), address); > return this; > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4846) The KernelServices test controller returns empty capabilities on multiple runs against the same instance

by James Perkins (Jira)

James Perkins created WFCORE-4846: ------------------------------------- Summary: The KernelServices test controller returns empty capabilities on multiple runs against the same instance Key: WFCORE-4846 URL: https://issues.redhat.com/browse/WFCORE-4846 Project: WildFly Core Issue Type: Bug Components: Test Suite Reporter: James Perkins Using the JUnit {{@Parmaterized}} test runner on the same {{KernelServices}} seems to return an empty collection of capabilities in the controller. If the tests are run individually or the {{KernelServices}} is initialized for each test run there are no issues. In some cases however it may be desirable to share a single instance of the container. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4841) Logging subsystem capabilities do not work correctly

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-4841?page=com.atlassian.jira.plug... ] James Perkins commented on WFCORE-4841: --------------------------------------- I've filed WFCORE-4846 as a follow up. When I get a chance I'll attach an example test which shows the behavior. > Logging subsystem capabilities do not work correctly > ---------------------------------------------------- > > Key: WFCORE-4841 > URL: https://issues.redhat.com/browse/WFCORE-4841 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > > With WFCORE-3337 the logging subsystem introduced capabilities. While looking at WFCORE-966 I determined the capabilities were not correctly implemented. In some cases invalid capabilities are allowed to be add in admin-only mode. In other cases they're allowed to be assigned even when invalid and running a full server. > The tests are also incorrect. They seemed correct as they checked for failed operations. However the result of the failure was not checked and some of the operations were failing, but not for the reasons expected. This was all a poor design on my part. > New tests need to be added. One thing I did notice was these tests don't seem to work in a static {{KernelServices}} test controller. For some reason when running against a logging profile the capability recorder seems to be empty. However using a manual mode test works fine. I believe this is just a flaw in the unit test controller. This will require the tests to be moved to manual mode tests so they can be test against an admin-only booted server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5060) [DMN Designer] Editor allows node with prefix/trailing space

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5060: -------------------------------------- Summary: [DMN Designer] Editor allows node with prefix/trailing space Key: DROOLS-5060 URL: https://issues.redhat.com/browse/DROOLS-5060 Project: Drools Issue Type: Bug Components: DMN Editor Reporter: Matteo Mortari Assignee: Michael Anstis I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine. But, imho, an UX point is not being considered, where is necessary instead. By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc. The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO. Further, I consider is just the Analyst which slipped a space. In my perspective, the editor should just strip away the prefix/trailing space: * while Importing a DMN model from file Upload * while editing a DRGElement and hitting OK to save its name For your consideration, thanks. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2020