[JBoss JIRA] (WFLY-10067) Failover does not work with HTTP conncetors/acceptors
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10067?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10067:
------------------------------------
This is a known limitation of Artemis in WildFly that is covered by https://issues.jboss.org/browse/EAP7-605.
This is considered as a new feature, it should not be blocker and should not block the upgrade of Artemis 2.x in WildFly.
> Failover does not work with HTTP conncetors/acceptors
> -----------------------------------------------------
>
> Key: WFLY-10067
> URL: https://issues.jboss.org/browse/WFLY-10067
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: clients.log, server1.log, server2.log, test.log
>
>
> Failover does not work with HTTP connectors/acceptors.
> *Scenario:*
> # There are two Wildfly servers configured as Live-Backup pair
> # There is one JMS producer and one JMS receiver which sends/receives messages
> # Live server is several times killed and restarted.
> *Expectation:* Always when the Live server is killed or restarted, clients do failover or failback.
> *Reality*: Sometimes happens that clients don't do failover.
> *Users impact:* One of basics feature of HA, failover, does not work properly.
> *Detail description of issue*
> In the trace logs it can be seen that clients send HTTP handshake request to active backup, but the handshake fails. All checks (and logs) say that the backup is active in this time period. I tried to run the test with Netty connectors/acceptors and I didn't see this issue.
> {code:title=Backup log}
> 07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=55, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
> 07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=56, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
> 07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485068, b=2147485067]
> 07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485076, b=2147485075]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484450, b=2147484449]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485072, b=2147485071]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484454, b=2147484453]
> 07:52:47,866 WARN [org.apache.activemq.artemis.core.client] (activemq-discovery-group-thread-dg-group1) AMQ212034: There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have a backup node active at the same time as its live node. nodeID=0dee81c9-2d9d-11e8-ba3f-cc3d825f79a4
> 07:52:47,867 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221007: Server is now live
> {code}
> {code:title=Clients log}
> 07:52:49,274 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
> 07:52:49,274 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=8080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1081] Trying backup config = TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=9080&host=localhost
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:447] Connector NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] using native epoll
> 07:52:49,275 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET HTTP/1.1
> host: localhost
> upgrade: activemq-remoting
> connection: upgrade
> activemqServerName: default
> httpUpgradeEndpoint: acceptor
> Sec-ActiveMQRemoting-Key: QWV3bCfgh75NjWH3pZV5Ew==
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:601] AMQ211002: Started EPOLL Netty Connector version 4.1.16.Final to localhost:9080
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
> 07:52:49,276 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET HTTP/1.1
> host: localhost
> upgrade: activemq-remoting
> connection: upgrade
> activemqServerName: default
> httpUpgradeEndpoint: acceptor
> Sec-ActiveMQRemoting-Key: P9xBwRk1eZP5QjDWjqYuIg==
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
> Content-Length: 2426
> Content-Type: text/html
> Accept-Ranges: bytes
> Date: Thu, 22 Mar 2018 06:52:49 GMT
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
> Content-Length: 2426
> Content-Type: text/html
> Accept-Ranges: bytes
> Date: Thu, 22 Mar 2018 06:52:49 GMT
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
> 07:52:49,277 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10067) Failover does not work with HTTP conncetors/acceptors
by Erich Duda (JIRA)
Erich Duda created WFLY-10067:
---------------------------------
Summary: Failover does not work with HTTP conncetors/acceptors
Key: WFLY-10067
URL: https://issues.jboss.org/browse/WFLY-10067
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 13.0.0.Beta1
Reporter: Erich Duda
Assignee: Jeff Mesnil
Priority: Blocker
Attachments: clients.log, server1.log, server2.log, test.log
Failover does not work with HTTP connectors/acceptors.
*Scenario:*
# There are two Wildfly servers configured as Live-Backup pair
# There is one JMS producer and one JMS receiver which sends/receives messages
# Live server is several times killed and restarted.
*Expectation:* Always when the Live server is killed or restarted, clients do failover or failback.
*Reality*: Sometimes happens that clients don't do failover.
*Users impact:* One of basics feature of HA, failover, does not work properly.
*Detail description of issue*
In the trace logs it can be seen that clients send HTTP handshake request to active backup, but the handshake fails. All checks (and logs) say that the backup is active in this time period. I tried to run the test with Netty connectors/acceptors and I didn't see this issue.
{code:title=Backup log}
07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=55, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=56, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485068, b=2147485067]
07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485076, b=2147485075]
07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484450, b=2147484449]
07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485072, b=2147485071]
07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484454, b=2147484453]
07:52:47,866 WARN [org.apache.activemq.artemis.core.client] (activemq-discovery-group-thread-dg-group1) AMQ212034: There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have a backup node active at the same time as its live node. nodeID=0dee81c9-2d9d-11e8-ba3f-cc3d825f79a4
07:52:47,867 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221007: Server is now live
{code}
{code:title=Clients log}
07:52:49,274 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
07:52:49,274 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=8080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1081] Trying backup config = TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=9080&host=localhost
07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:447] Connector NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] using native epoll
07:52:49,275 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
GET HTTP/1.1
host: localhost
upgrade: activemq-remoting
connection: upgrade
activemqServerName: default
httpUpgradeEndpoint: acceptor
Sec-ActiveMQRemoting-Key: QWV3bCfgh75NjWH3pZV5Ew==
07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:601] AMQ211002: Started EPOLL Netty Connector version 4.1.16.Final to localhost:9080
07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
07:52:49,276 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
GET HTTP/1.1
host: localhost
upgrade: activemq-remoting
connection: upgrade
activemqServerName: default
httpUpgradeEndpoint: acceptor
Sec-ActiveMQRemoting-Key: P9xBwRk1eZP5QjDWjqYuIg==
07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
HTTP/1.1 200 OK
Connection: keep-alive
Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
Content-Length: 2426
Content-Type: text/html
Accept-Ranges: bytes
Date: Thu, 22 Mar 2018 06:52:49 GMT
07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
HTTP/1.1 200 OK
Connection: keep-alive
Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
Content-Length: 2426
Content-Type: text/html
Accept-Ranges: bytes
Date: Thu, 22 Mar 2018 06:52:49 GMT
07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
07:52:49,277 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-1792) [Guided Decision Table] Default value of a column is not validated with the field data type
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1792?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-1792:
--------------------------------
Sprint: 2018 Week 11-12
> [Guided Decision Table] Default value of a column is not validated with the field data type
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-1792
> URL: https://issues.jboss.org/browse/DROOLS-1792
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.0.0.Beta5
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Labels: dtable_testday_preparation, qe-suggest-pre-7.0.0.Final, qe-test-day, reported-by-qe
> Fix For: 7.7.0.Final
>
>
> During definition of a condition or an action column, user has possibility to specify 'Default value' for this column. The problem is that the default value is not validated with the field data type. In practice it means that even when the column expects only _Integer_ values (because of the field data type), the default value still can be some _String_ value. The 'Default value' inputs should be validated like particular cells of the guided decision table. In those cells the user is not able to put _String_ value into the cell where are expected only _Integer_ values.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2407) [DMN Designer] Context Entry deletion assign row number to default entry
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2407?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-2407:
-------------------------------------
Manual check finished, no issue found, approving PR.
> [DMN Designer] Context Entry deletion assign row number to default entry
> ------------------------------------------------------------------------
>
> Key: DROOLS-2407
> URL: https://issues.jboss.org/browse/DROOLS-2407
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.7.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Optional
>
> During review of DROOLS-2398 I noticed the behavior described below, however not sure if it is related to that issue.
> If user deletes a context entry, then row number is assigned to default context entry.
> h2. Acceptance criteria
> The default context entry has not row number even if:
> # Context entry deleted (/)
> # Context entry cleared (/)
> # Context entry added (/)
> # Something of above undone and consequently redone (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2407) [DMN Designer] Context Entry deletion assign row number to default entry
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2407?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2407:
--------------------------------
Description:
During review of DROOLS-2398 I noticed the behavior described below, however not sure if it is related to that issue.
If user deletes a context entry, then row number is assigned to default context entry.
h2. Acceptance criteria
The default context entry has not row number even if:
# Context entry deleted (/)
# Context entry cleared (/)
# Context entry added (/)
# Something of above undone and consequently redone (/)
was:
During review of DROOLS-2398 I noticed the behavior described below, however not sure if it is related to that issue.
If user deletes a context entry, then row number is assigned to default context entry.
h2. Acceptance criteria
The default context entry has not row number even if:
# Context entry deleted
# Context entry cleared (/)
# Context entry added (/)
# Something of above undone and consequently redone
> [DMN Designer] Context Entry deletion assign row number to default entry
> ------------------------------------------------------------------------
>
> Key: DROOLS-2407
> URL: https://issues.jboss.org/browse/DROOLS-2407
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.7.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Optional
>
> During review of DROOLS-2398 I noticed the behavior described below, however not sure if it is related to that issue.
> If user deletes a context entry, then row number is assigned to default context entry.
> h2. Acceptance criteria
> The default context entry has not row number even if:
> # Context entry deleted (/)
> # Context entry cleared (/)
> # Context entry added (/)
> # Something of above undone and consequently redone (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2407) [DMN Designer] Context Entry deletion assign row number to default entry
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2407?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2407:
--------------------------------
Description:
During review of DROOLS-2398 I noticed the behavior described below, however not sure if it is related to that issue.
If user deletes a context entry, then row number is assigned to default context entry.
h2. Acceptance criteria
The default context entry has not row number even if:
# Context entry deleted
# Context entry cleared (/)
# Context entry added (/)
# Something of above undone and consequently redone
was:
During review of DROOLS-2398 I noticed the behavior described below, however not sure if it is related to that issue.
If user deletes a context entry, then row number is assigned to default context entry.
h2. Acceptance criteria
The default context entry has not row number even if:
# Context entry deleted
# Context entry cleared
# Context entry added (/)
# Something of above undone and consequently redone
> [DMN Designer] Context Entry deletion assign row number to default entry
> ------------------------------------------------------------------------
>
> Key: DROOLS-2407
> URL: https://issues.jboss.org/browse/DROOLS-2407
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.7.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Optional
>
> During review of DROOLS-2398 I noticed the behavior described below, however not sure if it is related to that issue.
> If user deletes a context entry, then row number is assigned to default context entry.
> h2. Acceptance criteria
> The default context entry has not row number even if:
> # Context entry deleted
> # Context entry cleared (/)
> # Context entry added (/)
> # Something of above undone and consequently redone
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2407) [DMN Designer] Context Entry deletion assign row number to default entry
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2407?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2407:
--------------------------------
Description:
During review of DROOLS-2398 I noticed the behavior described below, however not sure if it is related to that issue.
If user deletes a context entry, then row number is assigned to default context entry.
h2. Acceptance criteria
The default context entry has not row number even if:
# Context entry deleted
# Context entry cleared
# Context entry added (/)
# Something of above undone and consequently redone
was:
During review of DROOLS-2398 I noticed the behavior described below, however not sure if it is related to that issue.
If user deletes a context entry, then row number is assigned to default context entry.
h2. Acceptance criteria
The default context entry has not row number even if:
# Context entry deleted
# Context entry cleared
# Context entry added
# Something of above undone and consequently redone
> [DMN Designer] Context Entry deletion assign row number to default entry
> ------------------------------------------------------------------------
>
> Key: DROOLS-2407
> URL: https://issues.jboss.org/browse/DROOLS-2407
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.7.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Optional
>
> During review of DROOLS-2398 I noticed the behavior described below, however not sure if it is related to that issue.
> If user deletes a context entry, then row number is assigned to default context entry.
> h2. Acceptance criteria
> The default context entry has not row number even if:
> # Context entry deleted
> # Context entry cleared
> # Context entry added (/)
> # Something of above undone and consequently redone
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9961) Annotations in applications, compiled using JDK 9, aren't recognized causing deployment issues
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9961?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-9961:
-------------------------------
Summary: Annotations in applications, compiled using JDK 9, aren't recognized causing deployment issues (was: [JDK9+] @WebListener and Spring WebApplicationInitializer not working (JDK8 OK!))
> Annotations in applications, compiled using JDK 9, aren't recognized causing deployment issues
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-9961
> URL: https://issues.jboss.org/browse/WFLY-9961
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 12.0.0.Final
> Reporter: cnsgithub cnsgithub
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 13.0.0.Beta1
>
>
> After upgrading to WFLY 12 Final, the WebApplicationInitializer class residing in the *.war classes Folder is no longer being detected when built with JDK 9. However with JDK 1.8 it works as expected.
> With WFLY 11, both variants JDK9, and JDK1.8 Build were working.
> {code:java}
> package de.test;
> import javax.servlet.ServletContext;
> import javax.servlet.ServletException;
> import org.springframework.web.WebApplicationInitializer;
> public class MyWebApplicationInitializer implements WebApplicationInitializer {
> @Override
> public void onStartup(ServletContext container) throws ServletException {
> System.out.println("!!!!!!!!!!!!!! ;-) !!!!!!!!!!!!");
> }
> }
> {code}
> Maybe(!) related to this: https://issues.jboss.org/browse/WFLY-9081
> Even more serious: the @WebListener doesn't seem to be recognized with JDK9 as well:
> {code:java}
> package de.test;
> import javax.servlet.ServletContextEvent;
> import javax.servlet.ServletContextListener;
> import javax.servlet.annotation.WebListener;
> import javax.servlet.http.HttpSessionEvent;
> import javax.servlet.http.HttpSessionIdListener;
> import javax.servlet.http.HttpSessionListener;
> @WebListener
> public class MyWebListener implements ServletContextListener, HttpSessionIdListener, HttpSessionListener {
> @Override
> public void contextInitialized(ServletContextEvent event) {
> System.out.println("contextInitialized !!!!!!!! I'm only working when i was built with JDK8");
> }
>
> @Override
> public void sessionIdChanged(HttpSessionEvent arg0, String arg1) {
> // TODO Auto-generated method stub
>
> }
> }
> {code}
> The actual error seems to happen quite early: JBossWebMetaData
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month