April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5685) Register management resources for deployment-specific caches

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-5685?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-5685: ------------------------------- Issue Type: Bug (was: Feature Request) > Register management resources for deployment-specific caches > ------------------------------------------------------------ > > Key: WFLY-5685 > URL: https://issues.jboss.org/browse/WFLY-5685 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3727) [DMN Designer] Quick Silver: Minimal standalone preparation

by Roger Martinez (Jira)

[ https://issues.jboss.org/browse/DROOLS-3727?page=com.atlassian.jira.plugi... ] Roger Martinez edited comment on DROOLS-3727 at 4/2/19 9:11 PM: ---------------------------------------------------------------- Ok great, thanks [~manstis] for the great and fast feedback! :-) Soo trying to summarize what being commented til this point, here are some resulting actions I see: * From my side (BPMN) ** First trying to achieve the BPMN standalone webapp work as the DMN one ** At this point, as I'll have better knowledge on this stuff, I'll be moving to reduce the dependencies as much as possible and identify other next steps, let's keep in touch * From our side (BPMN/DMN) ** What about creating a new branch in [kie-wb-common|https://github.com/kiegroup/kie-wb-common/] for us? (eg: _submarine_, _stunner-submarine_) For now there is no need even to compile it in Jenkins, as some of the dependencies will be still not available, but will be our shared code where both can be commiting and sharing progress. WDYT? Also if the idea is to keep 7.x / 8.x support, I understand we should be manually rebasing this branch with master, right? ** Also yeah would be nice being able to have the complete picture, by being able to deploy locally our editors into VSCode or Che (depends on next point) * From [~porcelli] 's side - PLEASE [~porcelli] can you provide us feedback (code, links...) about how you customize and run the standalone DMN webapp in VSCode, as you shown in last week's presentation? Thanks in advance guys! was (Author: roger600): Ok great, thanks [~manstis] for the great and fast feedback! :-) Soo trying to summarize what being commented til this point, here are some resulting actions I see: * From my side (BPMN) ** First trying to achieve the BPMN standalone webapp work as the DMN one ** At this point, as I'll have better knowledge on this stuff, I'll be moving to reduce the dependencies as much as possible and identify other next steps * From our side (BPMN/DMN) ** What about creating a new branch in [kie-wb-common|https://github.com/kiegroup/kie-wb-common/] for us? (eg: _submarine_, _stunner-submarine_) For now there is no need even to compile it in Jenkins, as some of the dependencies will be still not available, but will be our shared code where both can be commiting and sharing progress. WDYT? Also if the idea is to keep 7.x / 8.x support, I understand we should be manually rebasing this branch with master, right? ** Also yeah would be nice being able to have the complete picture, by being able to deploy locally our editors into VSCode or Che (depends on next point) * From [~porcelli] 's side - PLEASE [~porcelli] can you provide us feedback (code, links...) about how you customize and run the standalone DMN webapp in VSCode, as you shown in last week's presentation? Thanks in advance guys! > [DMN Designer] Quick Silver: Minimal standalone preparation > ----------------------------------------------------------- > > Key: DROOLS-3727 > URL: https://issues.jboss.org/browse/DROOLS-3727 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > Labels: Stunner, drools-tools, submarine > Fix For: 8.0.0.Final > > > Prepare a minimal DMN Designer standalone WAR that only supports _standalone_ mode. > No Home Page, no Library, No preferences, no other editors. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3727) [DMN Designer] Quick Silver: Minimal standalone preparation

by Roger Martinez (Jira)

[ https://issues.jboss.org/browse/DROOLS-3727?page=com.atlassian.jira.plugi... ] Roger Martinez commented on DROOLS-3727: ---------------------------------------- Ok great, thanks [~manstis] for the great and fast feedback! :-) Soo trying to summarize what being commented til this point, here are some resulting actions I see: * From my side (BPMN) ** First trying to achieve the BPMN standalone webapp work as the DMN one ** At this point, as I'll have better knowledge on this stuff, I'll be moving to reduce the dependencies as much as possible and identify other next steps * From our side (BPMN/DMN) ** What about creating a new branch in [kie-wb-common|https://github.com/kiegroup/kie-wb-common/] for us? (eg: _submarine_, _stunner-submarine_) For now there is no need even to compile it in Jenkins, as some of the dependencies will be still not available, but will be our shared code where both can be commiting and sharing progress. WDYT? Also if the idea is to keep 7.x / 8.x support, I understand we should be manually rebasing this branch with master, right? ** Also yeah would be nice being able to have the complete picture, by being able to deploy locally our editors into VSCode or Che (depends on next point) * From [~porcelli] 's side - PLEASE [~porcelli] can you provide us feedback (code, links...) about how you customize and run the standalone DMN webapp in VSCode, as you shown in last week's presentation? Thanks in advance guys! > [DMN Designer] Quick Silver: Minimal standalone preparation > ----------------------------------------------------------- > > Key: DROOLS-3727 > URL: https://issues.jboss.org/browse/DROOLS-3727 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > Labels: Stunner, drools-tools, submarine > Fix For: 8.0.0.Final > > > Prepare a minimal DMN Designer standalone WAR that only supports _standalone_ mode. > No Home Page, no Library, No preferences, no other editors. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[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)

6 years, 7 months

1
0
0 / 0

[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)

6 years, 7 months

1
0
0 / 0

[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)

6 years, 7 months

1
0
0 / 0

[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)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11920) A degraded mode cache cannot be made available again

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11920?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-11920: -------------------------------- Description: Needs new runtime operation that calls AdvancedCache.setAvailabilityMode(...) for a specific cache. (was: Operation should call AdvancedCache.setAvailabilityMode(...) for a specific cache.) > A degraded mode cache cannot be made available again > ---------------------------------------------------- > > Key: WFLY-11920 > URL: https://issues.jboss.org/browse/WFLY-11920 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 16.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Needs new runtime operation that calls AdvancedCache.setAvailabilityMode(...) for a specific cache. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11920) A degraded mode cache cannot be made available again

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11920?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-11920: -------------------------------- Summary: A degraded mode cache cannot be made available again (was: Add management operation for setting availability mode of a cache) > A degraded mode cache cannot be made available again > ---------------------------------------------------- > > Key: WFLY-11920 > URL: https://issues.jboss.org/browse/WFLY-11920 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 16.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Operation should call AdvancedCache.setAvailabilityMode(...) for a specific cache. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11920) Add management operation for setting availability mode of a cache

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11920?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-11920: -------------------------------- Issue Type: Bug (was: Feature Request) > Add management operation for setting availability mode of a cache > ----------------------------------------------------------------- > > Key: WFLY-11920 > URL: https://issues.jboss.org/browse/WFLY-11920 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 16.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Operation should call AdvancedCache.setAvailabilityMode(...) for a specific cache. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2019