[JBoss JIRA] (WFLY-10409) Thin build differs from fat dist in more than the absence of jars from modules
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10409?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-10409:
------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/11256
> Thin build differs from fat dist in more than the absence of jars from modules
> ------------------------------------------------------------------------------
>
> Key: WFLY-10409
> URL: https://issues.jboss.org/browse/WFLY-10409
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
>
> AIUI the thin build is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
> But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thin build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
> Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem.
> Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
> This work should make sure servlet-build is correct as well.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10410) Adding Undertow application-security-domain requires server reload although the server does not say so
by Peter Palaga (JIRA)
Peter Palaga created WFLY-10410:
-----------------------------------
Summary: Adding Undertow application-security-domain requires server reload although the server does not say so
Key: WFLY-10410
URL: https://issues.jboss.org/browse/WFLY-10410
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Peter Palaga
Assignee: Stuart Douglas
I stumbled upon this when writing a security related test in WildFly Camel. When adding a new Undertow {{application-security-domain}} via a {{ServerSetupTask}}, the domain is not ready for the subsequently deployed application unless the server is reloaded.
I am reporting this in spite of seeing that https://issues.jboss.org/browse/WFLY-8505 and https://issues.jboss.org/browse/JBEAP-10112 were rejected as not a bug.
The present issue is different because the application is not deployed during the add operation and hence there is no way to reload the app.
I believe either {{application-security-domain:add()}} should cause the server status change to {{reload-required}} or the {{application-security-domain}} should be available for the subsequent deployment without having to reload the server.
I have written a test case - see steps to reproduce.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10409) Thin build differs from fat dist in more than the absence of jars from modules
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10409?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-10409:
------------------------------------
Description:
AIUI the thin build is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thin build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem.
Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
This work should make sure servlet-build is correct as well.
was:
AIUI the thin dist is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thin build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem.
Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
This work should make sure servlet-build is correct as well.
> Thin build differs from fat dist in more than the absence of jars from modules
> ------------------------------------------------------------------------------
>
> Key: WFLY-10409
> URL: https://issues.jboss.org/browse/WFLY-10409
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
>
> AIUI the thin build is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
> But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thin build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
> Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem.
> Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
> This work should make sure servlet-build is correct as well.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10409) Thin build differs from fat dist in more than the absence of jars from modules
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10409?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-10409:
------------------------------------
Summary: Thin build differs from fat dist in more than the absence of jars from modules (was: Thin build differs from thick dist in more than the absence of jar from modules)
> Thin build differs from fat dist in more than the absence of jars from modules
> ------------------------------------------------------------------------------
>
> Key: WFLY-10409
> URL: https://issues.jboss.org/browse/WFLY-10409
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
>
> AIUI the thin dist is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
> But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thin build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
> Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem.
> Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
> This work should make sure servlet-build is correct as well.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10409) Thin build differs from thick dist in more than the absence of jar from modules
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10409?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-10409:
------------------------------------
Description:
AIUI the thin dist is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thin build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem.
Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
This work should make sure servlet-build is correct as well.
was:
AIUI the thin dist is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thick build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem. Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
This work should make sure servlet-build is correct as well.
> Thin build differs from thick dist in more than the absence of jar from modules
> -------------------------------------------------------------------------------
>
> Key: WFLY-10409
> URL: https://issues.jboss.org/browse/WFLY-10409
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
>
> AIUI the thin dist is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
> But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thin build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
> Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem.
> Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
> This work should make sure servlet-build is correct as well.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10409) Thin build differs from thick dist in more than the absence of jar from modules
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10409?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-10409:
------------------------------------
Description:
AIUI the thin dist is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thick build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem. Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
This work should make sure servlet-build is correct as well.
was:
AIUI the thin dist is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thick build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem. Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
> Thin build differs from thick dist in more than the absence of jar from modules
> -------------------------------------------------------------------------------
>
> Key: WFLY-10409
> URL: https://issues.jboss.org/browse/WFLY-10409
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
>
> AIUI the thin dist is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
> But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thick build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
> Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem. Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
> This work should make sure servlet-build is correct as well.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10409) Thin build differs from thick dist in more than the absence of jar from modules
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-10409?page=com.atlassian.jira.plugin... ]
Kabir Khan reassigned WFLY-10409:
---------------------------------
Assignee: Brian Stansberry
> Thin build differs from thick dist in more than the absence of jar from modules
> -------------------------------------------------------------------------------
>
> Key: WFLY-10409
> URL: https://issues.jboss.org/browse/WFLY-10409
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
>
> AIUI the thin dist is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
> But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thick build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
> Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem. Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10409) Thin build differs from thick dist in more than the absence of jar from modules
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-10409:
---------------------------------------
Summary: Thin build differs from thick dist in more than the absence of jar from modules
Key: WFLY-10409
URL: https://issues.jboss.org/browse/WFLY-10409
Project: WildFly
Issue Type: Bug
Components: Build System
Reporter: Brian Stansberry
Priority: Critical
AIUI the thin dist is meant to be the same as the fat dist except the jars are not in the modules; rather their gavs are in the various module.xml and JBoss Modules finds them in a maven repo.
But currently the differences are more than that. For sure the org.jboss.as.product module isn't even present in the thick build. This will lead to test failures in EAP as new tests added in WF 13 will not work if the console module location info from the product module is not available.
Comparing the galleon provisioning plugin config from dist/pom.xml to build/pom.xml gives a sense of the problem. Note that this diff is not due to the switch to galleon. The fact that a different galleon config was needed for build vs dist is because that is what was necessary to match what the prevacy legacy build created.
--
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/19/18 8:26 AM:
-----------------------------------------------------------------
[~jmesnil][~eduda] I have built a "special" version of 1.5.5 that contains just the Properties-based-SQLProvider commit + a fix on a JDBC connection leaks: https://github.com/franz1981/activemq-artemis/tree/WFLY-10392_NO_JDBC_HA (ie no JDBC HA at all).
Testing it has resulted in a failure: https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/WFLY-10392/3/
was (Author: fnigro):
[~jmesnil][~eduda] I have built a "special" version of 1.5.5 that contains just the Peroperties-based-SQLProvider commit + a fix on a JDBC connection leaks: https://github.com/franz1981/activemq-artemis/tree/WFLY-10392_NO_JDBC_HA (ie no JDBC HA at all).
Testing it has resulted in a failure: https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/WFLY-10392/3/
> 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
> Attachments: image-2018-05-19-10-26-05-662.png, sql-diff.png
>
>
> 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