[JBoss JIRA] (WFLY-10841) XA recovery warnings when server reloaded
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-10841?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka updated WFLY-10841:
-----------------------------------
Priority: Minor (was: Major)
> XA recovery warnings when server reloaded
> -----------------------------------------
>
> Key: WFLY-10841
> URL: https://issues.jboss.org/browse/WFLY-10841
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Transactions
> Affects Versions: 13.0.0.Final
> Reporter: Chao Wang
> Assignee: Ondra Chaloupka
> Priority: Minor
>
> Following warning messages are outputted when server reloaded.
> {code}
> 15:33:52,740 WARN [org.apache.activemq.artemis.service.extensions.xa.recovery] (Periodic Recovery) AMQ122015: Can not connect to XARecoveryConfig [transportConfiguration=[TransportConfiguration(name=, factory=org-apache-activemq-artemi
> s-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0], discoveryConfiguration=null, username=null, password=****, JNDI_NAME=java:/JmsXA] on auto-generated resource recovery: ActiveMQNotConnectedException[errorType=NOT_CONNECTED m
> essage=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:787)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.connect(ActiveMQXAResourceWrapper.java:311)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.getDelegate(ActiveMQXAResourceWrapper.java:239)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.recover(ActiveMQXAResourceWrapper.java:69)
> at org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.recover(ActiveMQXAResourceWrapperImpl.java:106)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:482)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:233)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:150)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:140)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> 15:33:52,752 WARN [org.apache.activemq.artemis.service.extensions.xa.recovery] (Periodic Recovery) AMQ122008: XA Recovery can not connect to any broker on recovery [XARecoveryConfig [transportConfiguration=[TransportConfiguration(name=
> , factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0], discoveryConfiguration=null, username=null, password=****, JNDI_NAME=java:/JmsXA]]
> 15:33:52,752 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMFAIL: javax.transaction.xa.XAException: Error trying to connect to any providers for xa reco
> very
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.getDelegate(ActiveMQXAResourceWrapper.java:258)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.recover(ActiveMQXAResourceWrapper.java:69)
> at org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.recover(ActiveMQXAResourceWrapperImpl.java:106)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:482)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:233)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:150)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:140)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=null]
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.connect(ActiveMQXAResourceWrapper.java:345)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.getDelegate(ActiveMQXAResourceWrapper.java:239)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-10841) XA recovery warnings when server reloaded
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-10841?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-10841:
----------------------------------------
there was created the upstream issue for artemis (https://issues.apache.org/jira/browse/ARTEMIS-2061) but the reason of the issue was wrong suspicion. More investigation is necessary.
> XA recovery warnings when server reloaded
> -----------------------------------------
>
> Key: WFLY-10841
> URL: https://issues.jboss.org/browse/WFLY-10841
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Transactions
> Affects Versions: 13.0.0.Final
> Reporter: Chao Wang
> Assignee: Ondra Chaloupka
> Priority: Major
>
> Following warning messages are outputted when server reloaded.
> {code}
> 15:33:52,740 WARN [org.apache.activemq.artemis.service.extensions.xa.recovery] (Periodic Recovery) AMQ122015: Can not connect to XARecoveryConfig [transportConfiguration=[TransportConfiguration(name=, factory=org-apache-activemq-artemi
> s-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0], discoveryConfiguration=null, username=null, password=****, JNDI_NAME=java:/JmsXA] on auto-generated resource recovery: ActiveMQNotConnectedException[errorType=NOT_CONNECTED m
> essage=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:787)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.connect(ActiveMQXAResourceWrapper.java:311)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.getDelegate(ActiveMQXAResourceWrapper.java:239)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.recover(ActiveMQXAResourceWrapper.java:69)
> at org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.recover(ActiveMQXAResourceWrapperImpl.java:106)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:482)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:233)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:150)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:140)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> 15:33:52,752 WARN [org.apache.activemq.artemis.service.extensions.xa.recovery] (Periodic Recovery) AMQ122008: XA Recovery can not connect to any broker on recovery [XARecoveryConfig [transportConfiguration=[TransportConfiguration(name=
> , factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0], discoveryConfiguration=null, username=null, password=****, JNDI_NAME=java:/JmsXA]]
> 15:33:52,752 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMFAIL: javax.transaction.xa.XAException: Error trying to connect to any providers for xa reco
> very
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.getDelegate(ActiveMQXAResourceWrapper.java:258)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.recover(ActiveMQXAResourceWrapper.java:69)
> at org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.recover(ActiveMQXAResourceWrapperImpl.java:106)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:482)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:233)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:150)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:140)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=null]
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.connect(ActiveMQXAResourceWrapper.java:345)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.getDelegate(ActiveMQXAResourceWrapper.java:239)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-10072) Stale session data on failover
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-10072?page=com.atlassian.jira.plugin... ]
Paul Ferraro closed WFLY-10072.
-------------------------------
Resolution: Out of Date
> Stale session data on failover
> ------------------------------
>
> Key: WFLY-10072
> URL: https://issues.jboss.org/browse/WFLY-10072
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.1.Final, 15.0.0.Alpha1
> Reporter: Daniel Čihák
> Assignee: Paul Ferraro
> Priority: Minor
>
> Occured on client. Affected scenarios:
> eap-7x-failover-ejb-ejbservlet-shutdown-dist-async
> eap-7x-failover-http-granular-shutdown-repl-sync
> eap-7x-failover-http-session-jvmkill-dist-sync
> eap-7x-failover-http-session-jvmkill-repl-sync
> eap-7x-failover-http-session-shutdown-repl-sync-haproxy
> eap-7x-failover-http-session-undeploy-dist-sync
> Client log stacktrace:
> {code}
> 2016/09/21 17:28:51:294 EDT [WARN ][Runner - 134] HOST dev220.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 42, received 41, Runner: 134>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 42, received 41, Runner: 134
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Link to client log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-10072) Stale session data on failover
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-10072?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10072:
-------------------------------------
[~tommaso-borgato] That's good news. I'll close this as out of date, since stale data can be expected with the remaining scenarios.
> Stale session data on failover
> ------------------------------
>
> Key: WFLY-10072
> URL: https://issues.jboss.org/browse/WFLY-10072
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.1.Final, 15.0.0.Alpha1
> Reporter: Daniel Čihák
> Assignee: Paul Ferraro
> Priority: Minor
>
> Occured on client. Affected scenarios:
> eap-7x-failover-ejb-ejbservlet-shutdown-dist-async
> eap-7x-failover-http-granular-shutdown-repl-sync
> eap-7x-failover-http-session-jvmkill-dist-sync
> eap-7x-failover-http-session-jvmkill-repl-sync
> eap-7x-failover-http-session-shutdown-repl-sync-haproxy
> eap-7x-failover-http-session-undeploy-dist-sync
> Client log stacktrace:
> {code}
> 2016/09/21 17:28:51:294 EDT [WARN ][Runner - 134] HOST dev220.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 42, received 41, Runner: 134>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 42, received 41, Runner: 134
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Link to client log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-8538) Remove need to configure default-virtual-host at subsystem level
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFLY-8538?page=com.atlassian.jira.plugin.... ]
Jan Stourac updated WFLY-8538:
------------------------------
Description:
There is currently needed host to which the deployments should be deployed by default. This is found out from default-virtual-host at undertow subsystem level. This value actually duplicates setting from the value set in default-host attribute of default server, as such it should be removed and thus config simplified by counting the needed value default server's default-host value.
Summing it up:
current behavior:
* default server value is determined by: {{/subsystem=undertow\[default-server\]}} attribute
* default virtual host value is determined by: {{/subsystem=undertow\[default-virtual-host\]}} attribute
proposed behavior:
* default server value is determined by: {{/subsystem=undertow\[default-server\]}} attribute (*no change here*)
* default virtual host value is determined by: {{/subsystem=undertow/server=VALUE_DETERMINED_IN_PREVIOUS_STEP\[default-host\]}} attribute
* deprecate {{/subsystem=undertow\[default-virtual-host\]}} attribute and remove it completely in some of upcoming versions
was:
There is currently needed host to which the deployments should be deployed by default. This is found out from default-virtual-host at undertow subsystem level. This value actually duplicates setting from the value set in default-host attribute of default server, as such it should be removed and thus config simplified by counting the needed value default server's default-host value.
Summing it up:
current behavior:
* default server value is determined by: {{/subsystem=undertow\[default-server\]}} attribute
* default virtual host value is determined by: {{/subsystem=undertow\[default-virtual-host\]}} attribute
proposed behavior:
* default server value is determined by: {{/subsystem=undertow\[default-server\]}} attribute (*no change here*)
* default virtual host value is determined by: {{/subsystem=undertow/server=VALUE_DETERMINED_IN_PREVIOUS_STEP\[default-host\]}} attribute
* deprecate {{/subsystem=undertow\[default-virtual-host\]}} attribute and remove it completely in some of upcoming versions
CC [~ctomc]
> Remove need to configure default-virtual-host at subsystem level
> ----------------------------------------------------------------
>
> Key: WFLY-8538
> URL: https://issues.jboss.org/browse/WFLY-8538
> Project: WildFly
> Issue Type: Enhancement
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Alpha1
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Major
>
> There is currently needed host to which the deployments should be deployed by default. This is found out from default-virtual-host at undertow subsystem level. This value actually duplicates setting from the value set in default-host attribute of default server, as such it should be removed and thus config simplified by counting the needed value default server's default-host value.
> Summing it up:
> current behavior:
> * default server value is determined by: {{/subsystem=undertow\[default-server\]}} attribute
> * default virtual host value is determined by: {{/subsystem=undertow\[default-virtual-host\]}} attribute
> proposed behavior:
> * default server value is determined by: {{/subsystem=undertow\[default-server\]}} attribute (*no change here*)
> * default virtual host value is determined by: {{/subsystem=undertow/server=VALUE_DETERMINED_IN_PREVIOUS_STEP\[default-host\]}} attribute
> * deprecate {{/subsystem=undertow\[default-virtual-host\]}} attribute and remove it completely in some of upcoming versions
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-8538) Remove need to configure default-virtual-host at subsystem level
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFLY-8538?page=com.atlassian.jira.plugin.... ]
Jan Stourac commented on WFLY-8538:
-----------------------------------
I've updated issue description to make more obvious what is going on here.
Also, I wanted to created another jira to at least mark 'default-virtual-host' attribute as deprecated to prepare for its possible removal in the future. Although, the truth is that it is still necessary for correct behavior and configuration of the server :/ . Not sure whether it is reasonable to mark it as deprecated in such case... Please raise your voice here.
> Remove need to configure default-virtual-host at subsystem level
> ----------------------------------------------------------------
>
> Key: WFLY-8538
> URL: https://issues.jboss.org/browse/WFLY-8538
> Project: WildFly
> Issue Type: Enhancement
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Alpha1
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Major
>
> There is currently needed host to which the deployments should be deployed by default. This is found out from default-virtual-host at undertow subsystem level. This value actually duplicates setting from the value set in default-host attribute of default server, as such it should be removed and thus config simplified by counting the needed value default server's default-host value.
> Summing it up:
> current behavior:
> * default server value is determined by: {{/subsystem=undertow\[default-server\]}} attribute
> * default virtual host value is determined by: {{/subsystem=undertow\[default-virtual-host\]}} attribute
> proposed behavior:
> * default server value is determined by: {{/subsystem=undertow\[default-server\]}} attribute (*no change here*)
> * default virtual host value is determined by: {{/subsystem=undertow/server=VALUE_DETERMINED_IN_PREVIOUS_STEP\[default-host\]}} attribute
> * deprecate {{/subsystem=undertow\[default-virtual-host\]}} attribute and remove it completely in some of upcoming versions
> CC [~ctomc]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-8538) Remove need to configure default-virtual-host at subsystem level
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFLY-8538?page=com.atlassian.jira.plugin.... ]
Jan Stourac updated WFLY-8538:
------------------------------
Description:
There is currently needed host to which the deployments should be deployed by default. This is found out from default-virtual-host at undertow subsystem level. This value actually duplicates setting from the value set in default-host attribute of default server, as such it should be removed and thus config simplified by counting the needed value default server's default-host value.
Summing it up:
current behavior:
* default server value is determined by: {{/subsystem=undertow\[default-server\]}} attribute
* default virtual host value is determined by: {{/subsystem=undertow\[default-virtual-host\]}} attribute
proposed behavior:
* default server value is determined by: {{/subsystem=undertow\[default-server\]}} attribute (*no change here*)
* default virtual host value is determined by: {{/subsystem=undertow/server=VALUE_DETERMINED_IN_PREVIOUS_STEP\[default-host\]}} attribute
* deprecate {{/subsystem=undertow\[default-virtual-host\]}} attribute and remove it completely in some of upcoming versions
CC [~ctomc]
was:
There is currently needed host to which the deployments should be deployed by default. This is found out from default-virtual-host at undertow subsystem level. This value actually duplicates setting from the value set in default-host attribute of default server, as such it should be removed and thus config simplified by counting the needed value default server's default-host value.
CC [~ctomc]
> Remove need to configure default-virtual-host at subsystem level
> ----------------------------------------------------------------
>
> Key: WFLY-8538
> URL: https://issues.jboss.org/browse/WFLY-8538
> Project: WildFly
> Issue Type: Enhancement
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Alpha1
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Major
>
> There is currently needed host to which the deployments should be deployed by default. This is found out from default-virtual-host at undertow subsystem level. This value actually duplicates setting from the value set in default-host attribute of default server, as such it should be removed and thus config simplified by counting the needed value default server's default-host value.
> Summing it up:
> current behavior:
> * default server value is determined by: {{/subsystem=undertow\[default-server\]}} attribute
> * default virtual host value is determined by: {{/subsystem=undertow\[default-virtual-host\]}} attribute
> proposed behavior:
> * default server value is determined by: {{/subsystem=undertow\[default-server\]}} attribute (*no change here*)
> * default virtual host value is determined by: {{/subsystem=undertow/server=VALUE_DETERMINED_IN_PREVIOUS_STEP\[default-host\]}} attribute
> * deprecate {{/subsystem=undertow\[default-virtual-host\]}} attribute and remove it completely in some of upcoming versions
> CC [~ctomc]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (DROOLS-2804) [DMN Designer] Properties Panel to drill-down to DMN component level
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-2804?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2804:
-----------------------------------
Story Points: 8 (was: 5)
> [DMN Designer] Properties Panel to drill-down to DMN component level
> --------------------------------------------------------------------
>
> Key: DROOLS-2804
> URL: https://issues.jboss.org/browse/DROOLS-2804
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
>
> The Properties Panel currently shows properties for Stunner-level "graph" components.
> We need, for DMN, the Properties Panel to show the properties of DMN elements' properties at the "grid" level. For example, when a {{Context}} is selected the Properties Panel should show only the top level properties for the {{Context}} (i.e. not those of its {{ContextEntries}}). Selection of a {{ContextEntry}} should refresh the Properties Panel to show only the top-level properties of the {{ContextEntry}}. Selection of the {{ContextEntry}}'s {{Expression}} should again refresh the Properties Panel to show only the top-level properties of the {{Expression}} and so forth.
> h2. Properties on the Grid Level
> The selection on the grid level should show the properties below. Please notice that selection of multiple cells, rows or columns should show empty properties panel.
> h3. Literal expression
> ||Selected item||Properties panel items||
> |Cell|(?)|
> h3. Context
> ||Selected item||Properties panel items||
> |Row|(?)|
> |Column|(?)|
> |Cell|(?)|
> h3. Decision Table
> ||Selected item||Properties panel items||
> |Row|(?)|
> |Column|(?)|
> |Cell|(?)|
> h3. Relation
> ||Selected item||Properties panel items||
> |Row|(?)|
> |Column|(?)|
> |Cell|(?)|
> h3. Function
> ||Selected item||Properties panel items||
> |Row|(?)|
> |Column|(?)|
> |Cell|(?)|
> h3. Invocation
> ||Selected item||Properties panel items||
> |Row|(?)|
> |Column|(?)|
> |Cell|(?)|
> h2. Manual Acceptance Test
> - Switching between DRG and Grid editor, check proper fields shown
> - Switching between rows, columns, cells in Grid editor, check proper fields
> -- In same expression kind
> -- Across different expression kinds
> - Clear expression kind
> - Read only mode - older asset version
> - All Grid specific properties saved
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (DROOLS-3028) [DMN Designer] Consolidate data type select boxes
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3028?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3028:
-----------------------------------
Story Points: 3
> [DMN Designer] Consolidate data type select boxes
> -------------------------------------------------
>
> Key: DROOLS-3028
> URL: https://issues.jboss.org/browse/DROOLS-3028
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Major
> Labels: UX, drools-tools
> Fix For: 7.13.0.Final
>
>
> We should consolidate select boxes for data type shown in properties panel and shown in manage custom data type dialog. In the first case we just show ordered default and custom data types. In the second case we add split default and custom data types with headers *DEFAULT* and *CUSTOM*. We should ensure these headers are shown also from properties panel. In other words we should ensure all selectboxes for data type selection have the same look and feel.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (DROOLS-2522) [DMN Designer] Palette aesthetics
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-2522?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2522:
-----------------------------------
Story Points: 3
> [DMN Designer] Palette aesthetics
> ---------------------------------
>
> Key: DROOLS-2522
> URL: https://issues.jboss.org/browse/DROOLS-2522
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Fix For: 7.13.0.Final
>
> Attachments: DROOLS-2522 (resized).png, DROOLS-2522.mp4, Screen Shot 2018-10-01 at 12.26.15 PM.png, palette.png
>
>
> The palette css styling has changed. There appeared margins between items in palette, what is probably not problem, however even when user click to this margin (to space between two item in palette) still some palette item is selected.
> h2. Manual Acceptance test
> h3. Stunner
> - Chrome (/)
> - Firefox (/)
> - Edge (/)
> h3. DMN
> - Chrome (/)
> - Firefox (/)
> - Edge (/)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months