[JBoss JIRA] (DROOLS-1964) [DMN Editor] Input Data typeRef
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1964?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-1964:
--------------------------------
Description:
The Input Data nodes specifies the datatype via _typeRef_ attribute. Allowed are simple datatypes, enumerations of allowed values and complex data types like Person.
During work on this were added *typeRef* selection widgets for three DMN nodes: BKM, Decision, and Input. These selection widgets offer [BuiltInType|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-..., data types of project, editor for allowed values (enumerations).
h2. Acceptance test
- Load dmn from other tool, check data types recognized appropriately, can be edited, saved, reopened
- Create new dmn, define different data types for different nodes, save, reopen, check values preserved
was:The Input Data nodes specifies the datatype via _typeRef_ attribute. Allowed are simple datatypes, enumerations of allowed values and complex data types like Person.
> [DMN Editor] Input Data typeRef
> -------------------------------
>
> Key: DROOLS-1964
> URL: https://issues.jboss.org/browse/DROOLS-1964
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Labels: reported-by-qe
>
> The Input Data nodes specifies the datatype via _typeRef_ attribute. Allowed are simple datatypes, enumerations of allowed values and complex data types like Person.
> During work on this were added *typeRef* selection widgets for three DMN nodes: BKM, Decision, and Input. These selection widgets offer [BuiltInType|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-..., data types of project, editor for allowed values (enumerations).
> h2. Acceptance test
> - Load dmn from other tool, check data types recognized appropriately, can be edited, saved, reopened
> - Create new dmn, define different data types for different nodes, save, reopen, check values preserved
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10392) Regression in Remote JCA scenario with JDBC store after Artemis upgrade
by Francesco Nigro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Francesco Nigro edited comment on WFLY-10392 at 5/18/18 8:02 AM:
-----------------------------------------------------------------
[~eduda] Well done Erich! And _AMQ_BRIDGE_DUP is read through the written/read through which calls?
If is related to the read block changes it could makes sense...but given that we have already tried to rever it, maybe it should depend by the SQL used to perform the write/read used and related to the [~jmesnil] changes instead. wdyt?
was (Author: fnigro):
[~eduda] Well done Erich! And _AMQ_BRIDGE_DUP is readed through the written/read through which calls?
If is related to the read block changes it could makes sense...but given that we have already tried to rever it, maybe it should depend by the SQL used to perform the write/read used and related to the [~jmesnil] changes instead. wdyt?
> Regression in Remote JCA scenario with JDBC store after Artemis upgrade
> -----------------------------------------------------------------------
>
> Key: WFLY-10392
> URL: https://issues.jboss.org/browse/WFLY-10392
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> After Artemis upgrade to 1.5.5.jbossorg-011 (WFLY-10139) I can see a regression in Remote JCA test case when JDBC persistent store is used. This issue is not present if Artemis file based journal is used.
> When I removed commits related to JDBC HA from Artemis upgrade, the test passed with both JDBC and file based store.
> *Remote JCA scenario:*
> * There are 4 Wildfly servers
> * Servers 1 and 3 are used as messaging brokers - they are called JMS servers
> * Servers 2 and 4 have MDBs and RA configured to connect to JMS servers. These servers are called MDB servers.
> * External standalone producer sends messages to server 1 to InQueue
> * MDBs on MBD severs receive messages from InQueue and send them to OutQueue
> * External standalone receiver receives messages from server 3 from OutQueue
> * During this scenario server 1 is several times killed and restarted.
> *Expectation:* All messages sent by the standalone producer are received by the standalone receiver. There are no lost or duplicated messages.
> *Reality:* After some kills of server 1, message flow coming from the standalone producer is broken and the receiver does not receive any messages in specified timeout.
> *Critical* priority was chosen because the regression has been detected only in this particular test case so far. We ran only nightly testing scope. After that we run full testing, we will know more about impact of this issue.
> *Technical details:*
> At some point following log messages start to occur in the test log. It seems that they are related to malfunction of communication among Artemis brokers what causes that message flow is broken.
> {code}
> 21:55:51,724 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-client-global-threads)) AMQ222139: MessageFlowRecordImpl [nodeID=e53da514-5953-11e8-910a-fa163e48a89a, connector=TransportConfigur
> ation(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=10080&host=rhel7-la
> rge-58597, queueName=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, queue=QueueImpl[name=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=
> d80bf5bd-5953-11e8-ac10-fa163e48a89a]]@756a727a, isClosed=false, reset=true]::Remote queue binding jms.queue.DLQe53da514-5953-11e8-910a-fa163e48a89a has already been bound in the post office. Most likely cause f
> or this is you have a loop in your cluster due to cluster max-hops being too large or you have multiple cluster connections to the same nodes using overlapping addresses
> {code}
> {code}
> 21:55:53,078 ERROR [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.InQueuee53da514-5953-11e8-910a-fa163e48a89a on ClusterConnectionImpl@14989488[nodeUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a, connector=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=8080&host=rhel7-large-58597, address=jms, server=ActiveMQServerImpl::serverUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10392) Regression in Remote JCA scenario with JDBC store after Artemis upgrade
by Francesco Nigro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Francesco Nigro commented on WFLY-10392:
----------------------------------------
[~eduda] Well done Erich! And _AMQ_BRIDGE_DUP is readed through the written/read through which calls?
If is related to the read block changes it could makes sense...but given that we have already tried to rever it, maybe it should depend by the SQL used to perform the write/read used and related to the [~jmesnil] changes instead. wdyt?
> Regression in Remote JCA scenario with JDBC store after Artemis upgrade
> -----------------------------------------------------------------------
>
> Key: WFLY-10392
> URL: https://issues.jboss.org/browse/WFLY-10392
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> After Artemis upgrade to 1.5.5.jbossorg-011 (WFLY-10139) I can see a regression in Remote JCA test case when JDBC persistent store is used. This issue is not present if Artemis file based journal is used.
> When I removed commits related to JDBC HA from Artemis upgrade, the test passed with both JDBC and file based store.
> *Remote JCA scenario:*
> * There are 4 Wildfly servers
> * Servers 1 and 3 are used as messaging brokers - they are called JMS servers
> * Servers 2 and 4 have MDBs and RA configured to connect to JMS servers. These servers are called MDB servers.
> * External standalone producer sends messages to server 1 to InQueue
> * MDBs on MBD severs receive messages from InQueue and send them to OutQueue
> * External standalone receiver receives messages from server 3 from OutQueue
> * During this scenario server 1 is several times killed and restarted.
> *Expectation:* All messages sent by the standalone producer are received by the standalone receiver. There are no lost or duplicated messages.
> *Reality:* After some kills of server 1, message flow coming from the standalone producer is broken and the receiver does not receive any messages in specified timeout.
> *Critical* priority was chosen because the regression has been detected only in this particular test case so far. We ran only nightly testing scope. After that we run full testing, we will know more about impact of this issue.
> *Technical details:*
> At some point following log messages start to occur in the test log. It seems that they are related to malfunction of communication among Artemis brokers what causes that message flow is broken.
> {code}
> 21:55:51,724 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-client-global-threads)) AMQ222139: MessageFlowRecordImpl [nodeID=e53da514-5953-11e8-910a-fa163e48a89a, connector=TransportConfigur
> ation(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=10080&host=rhel7-la
> rge-58597, queueName=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, queue=QueueImpl[name=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=
> d80bf5bd-5953-11e8-ac10-fa163e48a89a]]@756a727a, isClosed=false, reset=true]::Remote queue binding jms.queue.DLQe53da514-5953-11e8-910a-fa163e48a89a has already been bound in the post office. Most likely cause f
> or this is you have a loop in your cluster due to cluster max-hops being too large or you have multiple cluster connections to the same nodes using overlapping addresses
> {code}
> {code}
> 21:55:53,078 ERROR [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.InQueuee53da514-5953-11e8-910a-fa163e48a89a on ClusterConnectionImpl@14989488[nodeUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a, connector=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=8080&host=rhel7-large-58597, address=jms, server=ActiveMQServerImpl::serverUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10392) Regression in Remote JCA scenario with JDBC store after Artemis upgrade
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Erich Duda commented on WFLY-10392:
-----------------------------------
[~fnigro] I looked on the test case which fails because of duplicated messages. I found a place where the duplicates are created.
* Server 2 and server 4 are in cluster
* Server 4 has active consumer so server 2 resends messages to server 4
* Message A is sent by ClusterConnectionBridge to server 4
* Server 4 receives message, sends acknowledgment back to server 2 and then sends message to the receiver
* Server 2 receives the acknowledgment from the server 4 but in the same time it is restarted by test.
* The restart causes that redistribution of message A is canceled
* After server 2 is restarted, it sends message A again to server 4.
This behavior is correct. I compared it with working Artemis version and it behaved in the same way. The difference was later on server 4 side. Correct version of Artemis receives the message A on server 4, sends back acknowledgment and then it drops the message because it was already in duplication cache.
However the incorrect version of Artemis doesn't detect duplication and sends the message A again to the receiver. And the reason is that the {{_AMQ_BRIDGE_DUP}} of the message A is different before and after restart of server 2.
{code}
_AMQ_BRIDGE_DUP=[C656 A37B 5A6A 11E8 AFF0 FA16 3ECA B4BE 0000 0000 0000 039C)]]
_AMQ_BRIDGE_DUP=[E613 7C4A 5A6A 11E8 A102 FA16 3ECA B4BE 0000 0000 0000 039C)]]
{code}
It seems that writing and reading to/from database breaks integrity of the message.
> Regression in Remote JCA scenario with JDBC store after Artemis upgrade
> -----------------------------------------------------------------------
>
> Key: WFLY-10392
> URL: https://issues.jboss.org/browse/WFLY-10392
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> After Artemis upgrade to 1.5.5.jbossorg-011 (WFLY-10139) I can see a regression in Remote JCA test case when JDBC persistent store is used. This issue is not present if Artemis file based journal is used.
> When I removed commits related to JDBC HA from Artemis upgrade, the test passed with both JDBC and file based store.
> *Remote JCA scenario:*
> * There are 4 Wildfly servers
> * Servers 1 and 3 are used as messaging brokers - they are called JMS servers
> * Servers 2 and 4 have MDBs and RA configured to connect to JMS servers. These servers are called MDB servers.
> * External standalone producer sends messages to server 1 to InQueue
> * MDBs on MBD severs receive messages from InQueue and send them to OutQueue
> * External standalone receiver receives messages from server 3 from OutQueue
> * During this scenario server 1 is several times killed and restarted.
> *Expectation:* All messages sent by the standalone producer are received by the standalone receiver. There are no lost or duplicated messages.
> *Reality:* After some kills of server 1, message flow coming from the standalone producer is broken and the receiver does not receive any messages in specified timeout.
> *Critical* priority was chosen because the regression has been detected only in this particular test case so far. We ran only nightly testing scope. After that we run full testing, we will know more about impact of this issue.
> *Technical details:*
> At some point following log messages start to occur in the test log. It seems that they are related to malfunction of communication among Artemis brokers what causes that message flow is broken.
> {code}
> 21:55:51,724 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-client-global-threads)) AMQ222139: MessageFlowRecordImpl [nodeID=e53da514-5953-11e8-910a-fa163e48a89a, connector=TransportConfigur
> ation(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=10080&host=rhel7-la
> rge-58597, queueName=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, queue=QueueImpl[name=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=
> d80bf5bd-5953-11e8-ac10-fa163e48a89a]]@756a727a, isClosed=false, reset=true]::Remote queue binding jms.queue.DLQe53da514-5953-11e8-910a-fa163e48a89a has already been bound in the post office. Most likely cause f
> or this is you have a loop in your cluster due to cluster max-hops being too large or you have multiple cluster connections to the same nodes using overlapping addresses
> {code}
> {code}
> 21:55:53,078 ERROR [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.InQueuee53da514-5953-11e8-910a-fa163e48a89a on ClusterConnectionImpl@14989488[nodeUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a, connector=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=8080&host=rhel7-large-58597, address=jms, server=ActiveMQServerImpl::serverUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2560) [DMN Designer] Change magnet of connection
by Jozef Marko (JIRA)
Jozef Marko created DROOLS-2560:
-----------------------------------
Summary: [DMN Designer] Change magnet of connection
Key: DROOLS-2560
URL: https://issues.jboss.org/browse/DROOLS-2560
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.8.0.Final
Reporter: Jozef Marko
Assignee: Michael Anstis
Priority: Blocker
Attachments: Screenshot from 2018-05-18 12-23-52.png
If user tries to change magnet of a connection between two nodes, there is shown attached error dialog. Setting as blocker because even after confirming the dialog, it appears again and again.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3825) Unify "-server" option in windows scripts (ps1, bat) for domain mode (and its servers)
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3825?page=com.atlassian.jira.plugi... ]
Kabir Khan reassigned WFCORE-3825:
----------------------------------
Assignee: (was: Kabir Khan)
> Unify "-server" option in windows scripts (ps1, bat) for domain mode (and its servers)
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-3825
> URL: https://issues.jboss.org/browse/WFCORE-3825
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Reporter: Marek Kopecký
>
> Unify "-server" option in windows scripts (ps1, bat) for domain mode (and its servers)
> Domain use "-server" option in unix, windows bat. Domain doesn't use "-server" option in windows ps1 scripts. Same for JVMs of domain servers.
> I prefer to add "-server" option to ps1 scripts.
> {noformat:title=domain.ps1 - "-server" option is missing}
> PS C:\Users\Administrator\playground\wfly.15\wildfly\bin> .\domain.ps1
> =================================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: C:\Users\Administrator\playground\wfly.15\wildfly
> JAVA: C:\Program Files\Java\jdk1.8.0_121\bin\java.exe
> MODULE_OPTS:
> JAVA_OPTS: -Xms64M -Xmx512M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman
> =================================================================================
> ...
> {noformat}
> {noformat:title=domain.bat - "-server" option is listed in JAVA_OPTS}
> C:\Users\Administrator\playground\wfly.15\wildfly\bin>domain.bat
> Calling "C:\Users\Administrator\playground\wfly.15\wildfly\bin\domain.conf.bat"
> Setting JAVA property to "C:\Program Files\Java\jdk1.8.0_121\bin\java"
> ===============================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: "C:\Users\Administrator\playground\wfly.15\wildfly"
> JAVA: "C:\Program Files\Java\jdk1.8.0_121\bin\java"
> JAVA_OPTS: "-Xms64M -Xmx512M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -server"
> ===============================================================================
> ...
> {noformat}
> cc: [~jamezp]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3831) jboss-cli.ps1 script doesn't return exit value correctly
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3831?page=com.atlassian.jira.plugi... ]
Kabir Khan reassigned WFCORE-3831:
----------------------------------
Assignee: (was: Kabir Khan)
> jboss-cli.ps1 script doesn't return exit value correctly
> --------------------------------------------------------
>
> Key: WFCORE-3831
> URL: https://issues.jboss.org/browse/WFCORE-3831
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Reporter: Marek Kopecký
>
> jboss-cli.ps1 script doesn't return exit value correctly
> Steps to reproduce:
> # start Command prompt in Windows
> # PowerShell \-ExecutionPolicy Bypass -File jboss-cli.ps1 "\-\-commands=nonsence" \-\-timeout=10000
> # echo %ERRORLEVEL%
> #* "0" is printed, "1" should be printed
> # add "exit 5" to the end of jboss-cli.ps1 file
> # PowerShell \-ExecutionPolicy Bypass -File jboss-cli.ps1 "\-\-commands=nonsence" \-\-timeout=10000
> # echo %ERRORLEVEL%
> #* "5" is printed
> cc: [~jamezp], [~eduda], [~jdenise]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months