[JBoss JIRA] (DROOLS-2792) [DMN Designer] Data-types: Grid: LiteralExpression
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2792?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2792:
----------------------------------------
Hi [~uxdlc] a {{ContextEntry}} is represented by a single row and so we need the name and data-type to be in the single cell - even if visually split across two lines of text. I guess the crux of my question is should we have a single editor for the single cell that supports changing the name and/or data-type (currently supported by the codebase) or whether we want to support different editors for different parts of the same cell (e.g. one editor for name and another for data-type; accessed by double clicking the applicable component of the cell).
The code-base currently only supports one editor for one cell for *one* parameter (which is the two header rows example in the document I originally attached); one editor for one cell for *both* parameters would be possible with a bit of change to the code-base whereas a different editor for different parts of a single cell is quite a lot of change. Therefore before I do much else I need to know what we need.. it'll impact what I do next and how long it takes.
As for your question about the drop-down used for selection of data-types; it's the same as used in the Properties Panel at the moment (and is https://silviomoreto.github.io/bootstrap-select/examples/#live-search). It is the same as we've been proposing from the beginning. If it is not what we should be using please create a JIRA and we'll change it to be as needed.
> [DMN Designer] Data-types: Grid: LiteralExpression
> --------------------------------------------------
>
> Key: DROOLS-2792
> URL: https://issues.jboss.org/browse/DROOLS-2792
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Attachments: DROOLS-2792.odt, Screen Shot 2018-08-01 at 10.11.48 AM.png, Screen Shot 2018-08-01 at 10.20.35 AM.png
>
>
> *_Literal Expression_*
> - (x) Grid header _could_ show Output Data Type
> - (/) Editing Output Data Type is possible via Properties panel
> - (x) Update header when Output Data Type is changed via Properties panel
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFCORE-3962) Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3962?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3962:
-------------------------------------
Component/s: Management
Scripts
> Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
> -------------------------------------------------------------------------------
>
> Key: WFCORE-3962
> URL: https://issues.jboss.org/browse/WFCORE-3962
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Modules, Scripts
> Affects Versions: 6.0.0.Alpha3
> Reporter: Matej Novotny
> Priority: Blocker
> Labels: Java11, blocker-WF14
>
> As per request, copying MODULES-372 to WFCORE as well.
> Starting WFLY with JDK 11 using {{standalone.sh}} yields:
> {code}
> org.jboss.modules.ModuleNotFoundException: java.se
> at org.jboss.modules.Module.addPaths(Module.java:1266)
> at org.jboss.modules.Module.link(Module.java:1622)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:437)
> {code}
> Output of {{java -version}}:
> {code}
> openjdk version "11-ea" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11-ea+21)
> OpenJDK 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10518) Connection to remote Artemis broker must not require the presence of a local Artemis broker
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-10518?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet reassigned WFLY-10518:
----------------------------------------
Assignee: ehsavoie Hugonnet (was: Jeff Mesnil)
> Connection to remote Artemis broker must not require the presence of a local Artemis broker
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-10518
> URL: https://issues.jboss.org/browse/WFLY-10518
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: ehsavoie Hugonnet
>
> Connections to remote Artemis-based broker (including A-MQ 7) are handled in WildFly by the pooled-connection-factory resource that is in the messaging-activemq subsystem: https://wildscribe.github.io/WildFly/13.0/subsystem/messaging-activemq/se...
> This pooled-connection-factory resource can be used to connect to the local Artemis server that "owns" it or to a remote Artemis broker.
> However, this pooled-connection-factory always require the presence of a local Artemis server even when it connects only to a remote Artemis broker.
> This use case will become more prevalent as EAP CD is used to connect to A-MQ 7 and will not embed a local Artemis server.
> The presence of a local Artemis server has impact on the memory and CPU footprint of EAP on OpenShift.
> This RFE will improve WildFly and EAP so that a connection with remote Artemis-based broker will no longer require the presence of a local instance of Artemis.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months