[JBoss JIRA] (DROOLS-3702) [Stunner] Arrows are incorrectly positioned when save-open diagram
by Roger Martinez (Jira)
[ https://issues.jboss.org/browse/DROOLS-3702?page=com.atlassian.jira.plugi... ]
Roger Martinez commented on DROOLS-3702:
----------------------------------------
Hey [~kgaevski] yep good point, on the BPMN side it works (in the "main" canvas), but not for DMN... so Ì also think the bug is on the DMN side.
[~manstis] [~dadossan] Looking at the (wrong) behavior this is what I think it happens:
* Once creating a connection between two nodes, from the contextual menu (toolbox), it creates both source/target connections by using the "auto-magnet" strategy (see [MagnetConnection#auto|https://github.com/kiegroup/kie-wb-common/blob/mast...] field). It means that while changing the locations for the shapes, the connection is automatically being updated and attached to the "closest" magnet. See the "auto-magnet" behavior:
!auto-magnets.gif!
* On the other hand, not sure about DMN, but the BPMN spec does not considers these magnet strategies that Stunner uses, it means that once marshalling/unmarshalling there is no supported attribute for keeping this info in the source XML file. So our BPMN marshallers are actually taking this into account and creating/consuming some custom attribute for it (see [here|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-...])
* Saying this, I understand that DMN marshallers are not supporting this "auto-magnet" strategy, is that correct? I think this is the reason why once opening a DMN diagram, instead of using the "auto-magnet" strategy as it defaults on the UI, it's using the "fixed-magnet" one, so the connections are always attached to the same magnet. See the "fixed-magnet" behavior, which is the one you get once loading a DMN diagram:
!fixed-magnets.gif!
Sooo if the comments above make sense for you guys, I would say you've *two possible solutions*:
* Either adding support on the DMN marshallers for the auto-magnet and center-magnet strategies as well as we did on the BPMN ones
* Either dropping the support for auto-magnet and center-magnet only for DMN - which has some implications on the code as well as actually we don't support different strategies by domain, we should improve this stuff a bit for doing so
PS: There exist *3 connection/magnet strategies* in Stunner:
* *Fixed* magnet - The connection is attached to a certain magnet, it does never change automatically. It happens when a user drops a connection to some of the magnets attached into the shape's border
* *Auto* magnet - The connection is not really attached to any magnet... depending the source/target node locations the magnet being used is automatically calculated. It happens when a user drops a connection over a shape, not to any concrete magnet
* *Center* magnet - The connection is not really attached to any magnet neither... it just "follows" the shape's border, depending on the source/target node locations. It happens when a user drops a connection to the CENTER magnet of a shape
> [Stunner] Arrows are incorrectly positioned when save-open diagram
> ------------------------------------------------------------------
>
> Key: DROOLS-3702
> URL: https://issues.jboss.org/browse/DROOLS-3702
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Daniel José dos Santos
> Assignee: Michael Anstis
> Priority: Major
> Labels: Stunner
> Attachments: auto-magnets.gif, fixed-magnets.gif, process-designer-connectors-magnets-issues.png, weird_arrow.gif
>
>
> 1. Add a `Decision Node`
> 2. Add a `Input Data Node` bellow `Decision Node`
> 3. Connect `Input Data Node` to `Decision Node`
> 4. Save
> 5. Close
> 6. Open againThe arrow from `Input Data Node` to `Decision Node` will be at right of the `Decision Node` and if you move the `Input Data Node`, the arrow is not repositioned.
> I noticed this in DMN Showcase and in drools-wb.
> And if you add a new `Decision Node` and a new `Input Data Node`, without save and close, it behaves as expected.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3702) [Stunner] Arrows are incorrectly positioned when save-open diagram
by Roger Martinez (Jira)
[ https://issues.jboss.org/browse/DROOLS-3702?page=com.atlassian.jira.plugi... ]
Roger Martinez updated DROOLS-3702:
-----------------------------------
Attachment: fixed-magnets.gif
> [Stunner] Arrows are incorrectly positioned when save-open diagram
> ------------------------------------------------------------------
>
> Key: DROOLS-3702
> URL: https://issues.jboss.org/browse/DROOLS-3702
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Daniel José dos Santos
> Assignee: Michael Anstis
> Priority: Major
> Labels: Stunner
> Attachments: auto-magnets.gif, fixed-magnets.gif, process-designer-connectors-magnets-issues.png, weird_arrow.gif
>
>
> 1. Add a `Decision Node`
> 2. Add a `Input Data Node` bellow `Decision Node`
> 3. Connect `Input Data Node` to `Decision Node`
> 4. Save
> 5. Close
> 6. Open againThe arrow from `Input Data Node` to `Decision Node` will be at right of the `Decision Node` and if you move the `Input Data Node`, the arrow is not repositioned.
> I noticed this in DMN Showcase and in drools-wb.
> And if you add a new `Decision Node` and a new `Input Data Node`, without save and close, it behaves as expected.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3702) [Stunner] Arrows are incorrectly positioned when save-open diagram
by Roger Martinez (Jira)
[ https://issues.jboss.org/browse/DROOLS-3702?page=com.atlassian.jira.plugi... ]
Roger Martinez updated DROOLS-3702:
-----------------------------------
Attachment: auto-magnets.gif
> [Stunner] Arrows are incorrectly positioned when save-open diagram
> ------------------------------------------------------------------
>
> Key: DROOLS-3702
> URL: https://issues.jboss.org/browse/DROOLS-3702
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Daniel José dos Santos
> Assignee: Michael Anstis
> Priority: Major
> Labels: Stunner
> Attachments: auto-magnets.gif, fixed-magnets.gif, process-designer-connectors-magnets-issues.png, weird_arrow.gif
>
>
> 1. Add a `Decision Node`
> 2. Add a `Input Data Node` bellow `Decision Node`
> 3. Connect `Input Data Node` to `Decision Node`
> 4. Save
> 5. Close
> 6. Open againThe arrow from `Input Data Node` to `Decision Node` will be at right of the `Decision Node` and if you move the `Input Data Node`, the arrow is not repositioned.
> I noticed this in DMN Showcase and in drools-wb.
> And if you add a new `Decision Node` and a new `Input Data Node`, without save and close, it behaves as expected.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4398) WorkerResourceDefinition.WorkerWriteAttributeHandler implementations incorrectly handle undefined values
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-4398:
----------------------------------------
Summary: WorkerResourceDefinition.WorkerWriteAttributeHandler implementations incorrectly handle undefined values
Key: WFCORE-4398
URL: https://issues.jboss.org/browse/WFCORE-4398
Project: WildFly Core
Issue Type: Bug
Components: IO
Affects Versions: 9.0.0.Beta1, 8.0.0.Final, 7.0.0.Final, 6.0.2.Final
Reporter: Brian Stansberry
Assignee: Flavia Rainone
The WorkerResourceDefinition.WorkerWriteAttributeHandler implementations are not checking for undefined values before attempting type conversions:
{code}
10:12:28,243 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("undefine-attribute") failed - address: ([
("subsystem" => "io"),
("worker" => "default")
]): java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asInt(ModelValue.java:61)
at org.jboss.dmr.ModelNode.asInt(ModelNode.java:288)
at org.wildfly.extension.io.WorkerResourceDefinition$5.setValue(WorkerResourceDefinition.java:201)
at org.wildfly.extension.io.WorkerResourceDefinition$WorkerWriteAttributeHandler.applyUpdateToRuntime(WorkerResourceDefinition.java:262)
at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
{code}
That stack trace maps to WildFly 14 / WildFly Core 6 code.
It should be fine for the attributes that have default values, as there the default value would be passed in instead of undefined. But for the others some sort of handling is needed.
I believe that special handling should be to pass in the default value used in the XNIO code.
_*Any change to add any default value to the IO subsystem management API should be done via a separate JIRA. Do not mix this bug fix with an API change.*_
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11935) Remove unused commons-cli, commons-lang and commons-lang3 modules
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-11935:
---------------------------------------
Summary: Remove unused commons-cli, commons-lang and commons-lang3 modules
Key: WFLY-11935
URL: https://issues.jboss.org/browse/WFLY-11935
Project: WildFly
Issue Type: Task
Components: JSF, Server
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 17.0.0.Beta1
Currently WildFly includes 3 JBoss Modules modules that are not used in our runtime. I would like to remove these in WildFly 17:
org.apache.commons.cli
org.apache.commons.lang[1]
org.apache.commons.lang3
All three have the "jboss.api" = "private" property set in their module.xml, meaning they are marked for internal use only and we are free to remove them. End user applications should not have referenced these modules, and if they do we log a WARN on boot advising not to do that.
However, other projects that extend WildFly (i.e. write their own subsystems) may be using these modules, so I sent out a notification that these may be going away:
http://lists.jboss.org/pipermail/wildfly-dev/2019-April/006829.html
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month