[WFCORE-1118] Upgrade to WildFly Elytron 1.0.2.Final

https://issues.jboss.org/browse/WFCORE-1118
https://issues.jboss.org/browse/ELY-354
https://issues.jboss.org/browse/JBEAP-714

Windows Build 2631 outcome was FAILURE using a merge of 0bca18b95d2c9a62fec2afb6e500c026ca9c957d
Summary: Tests failed: 1 (1 new), passed: 3457, ignored: 64 Build time: 00:35:17
Failed tests
org.jboss.as.test.manualmode.deployment.DeploymentScannerUnitTestCase.testStartup: java.lang.AssertionError: Deployment two shouldn't exist at 2015-11-10 13:07:06,154
	at org.jboss.as.test.manualmode.deployment.DeploymentScannerUnitTestCase.testStartup(DeploymentScannerUnitTestCase.java:143)
------- Stdout: -------
13:06:57,431 INFO  [org.wildfly.core.testrunner.Server] (main) Starting container with: C:\Java\jdk1.8.0_45\jre\bin\java -D[Standalone] -javaagent:c:\store\repository\org\jboss\byteman\byteman\2.2.1\byteman-2.2.1.jar=port:9091,boot:c:\store\repository\org\jboss\byteman\byteman\2.2.1\byteman-2.2.1.jar,sys:C:\BuildAgent\work\8d74ae55e497982e\testsuite\shared\target\wildfly-core-testsuite-shared-3.0.0.Alpha1-SNAPSHOT.jar -Dorg.jboss.byteman.transform.all -Dorg.jboss.byteman.verbose=true -Dmaven.repo.local=c:\store\repository -Xmx512m -Djboss.dist=C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode/target/wildfly-core -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true -server -Dts.timeout.factor=100 -Djbossas.ts.dir=C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode -ea -Dorg.jboss.boot.log.file=C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode\target\wildfly-core\standalone\log\server.log -Dlogging.configuration=file:C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode\target\wildfly-core\standalone\configuration\logging.properties -jar C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode\target\wildfly-core\jboss-modules.jar -mp C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode\target\wildfly-core\modules org.jboss.as.standalone -Djboss.home.dir=C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode\target\wildfly-core -Djboss.server.base.dir=C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode\target\wildfly-core\standalone -Djboss.server.log.dir=C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode\target\wildfly-core\standalone\log -Djboss.server.config.dir=C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode\target\wildfly-core\standalone\configuration -c=standalone.xml -bmanagement=::1 -Djboss.http.port=8080 -Djboss.bind.address=::1
13:06:57,520 INFO  [org.xnio] (main) XNIO version 3.3.2.Final
TransformListener() : accepting requests on localhost:9091
13:06:57,590 INFO  [org.xnio.nio] (main) XNIO NIO Implementation Version 3.3.2.Final
13:06:57,651 INFO  [org.jboss.remoting] (main) JBoss Remoting version 4.0.14.Final
13:06:57,937 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
13:06:58,219 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
13:06:58,322 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: WildFly Core 3.0.0.Alpha1-SNAPSHOT "Kenny" starting
13:06:58,924 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
13:06:58,952 INFO  [org.xnio] (MSC service thread 1-3) XNIO version 3.3.2.Final
13:06:58,969 INFO  [org.xnio.nio] (MSC service thread 1-3) XNIO NIO Implementation Version 3.3.2.Final
13:06:59,075 INFO  [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 4.0.14.Final
13:06:59,229 WARN  [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-8) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console
13:06:59,382 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9990/management
13:06:59,383 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9990
13:06:59,383 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha1-SNAPSHOT "Kenny" started in 1800ms - Started 55 of 57 services (15 services are lazy, passive or on-demand)
13:07:00,220 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) WFLYDS0013: Started FileSystemDeploymentService for directory C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode\target\deployment-test-057208a1-b70c-4228-aeed-8dad12033a94
13:07:00,242 INFO  [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0001: Content added at location C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode\target\wildfly-core\standalone\data\content\e4\4c907a924dce22a436c8f949c18a820a3f509a\content
13:07:00,251 INFO  [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0001: Content added at location C:\BuildAgent\work\8d74ae55e497982e\testsuite\manualmode\target\wildfly-core\standalone\data\content\70\45cf7a266e01a004f53302f494b0385faaad6a\content
13:07:00,269 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0027: Starting deployment of "deployment-startup-one.jar" (runtime-name: "deployment-startup-one.jar")
13:07:00,269 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "deployment-startup-two.jar" (runtime-name: "deployment-startup-two.jar")
13:07:00,310 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.module.service."deployment.deployment-startup-two.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.deployment-startup-two.jar".main: WFLYSRV0179: Failed to load module: deployment.deployment-startup-two.jar:main
	at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: org.jboss.modules.ModuleNotFoundException: non.existing.dependency:main
	at org.jboss.modules.Module.addPaths(Module.java:1042)
	at org.jboss.modules.Module.link(Module.java:1398)
	at org.jboss.modules.Module.relinkIfNecessary(Module.java:1426)
	at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238)
	at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
	... 5 more

13:07:00,320 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "deployment-startup-two.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.module.service.\"deployment.deployment-startup-two.jar\".main" => "org.jboss.msc.service.StartException in service jboss.module.service.\"deployment.deployment-startup-two.jar\".main: WFLYSRV0179: Failed to load module: deployment.deployment-startup-two.jar:main
    Caused by: org.jboss.modules.ModuleNotFoundException: non.existing.dependency:main"}}
13:07:00,331 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "deployment-startup-two.jar" (runtime-name : "deployment-startup-two.jar")
13:07:00,331 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "deployment-startup-one.jar" (runtime-name : "deployment-startup-one.jar")
13:07:00,331 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report
WFLYCTL0186:   Services which failed to start:      service jboss.module.service."deployment.deployment-startup-two.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.deployment-startup-two.jar".main: WFLYSRV0179: Failed to load module: deployment.deployment-startup-two.jar:main

13:07:00,418 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 0ms timeout.
13:07:00,420 INFO  [org.jboss.as.server] (Thread-3) WFLYSRV0220: Server shutdown has been requested.
13:07:00,431 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment deployment-startup-one.jar (runtime-name: deployment-startup-one.jar) in 8ms
13:07:00,436 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment deployment-startup-two.jar (runtime-name: deployment-startup-two.jar) in 9ms
13:07:00,445 INFO  [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: WildFly Core 3.0.0.Alpha1-SNAPSHOT "Kenny" stopped in 18ms

retest this please
failure is unrelated: https://issues.jboss.org/browse/WFCORE-1074

Full integration - Windows Build 678 outcome was FAILURE using a merge of 0bca18b95d2c9a62fec2afb6e500c026ca9c957d
Summary: Tests failed: 4 (4 new), passed: 3279, ignored: 363 Build time: 00:54:56
Failed tests
org.jboss.as.test.clustering.cluster.ejb.xpc.StatefulWithXPCFailoverTestCase(SYNC-tcp).testBasicXPC: java.lang.AssertionError: expected:<200> but was:<500>
	at org.jboss.as.test.clustering.cluster.ejb.xpc.StatefulWithXPCFailoverTestCase.executeUrlWithAnswer(StatefulWithXPCFailoverTestCase.java:249)
	at org.jboss.as.test.clustering.cluster.ejb.xpc.StatefulWithXPCFailoverTestCase.testBasicXPC(StatefulWithXPCFailoverTestCase.java:224)
------- Stdout: -------
18:47:43,734 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0002: Content removed from location C:\BuildAgent\work\db872761b443af46\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-1\standalone\data\content\15\59b25933b3a70c1abd67769947a25ebded0bbc\content
18:47:43,734 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0009: Undeployed "stateful-timeout.war" (runtime-name: "stateful-timeout.war")
18:47:43,754 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Starting deployment=NONE, container=container-0
18:47:43,754 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Starting deployment=NONE, container=container-1
18:47:43,754 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Deploying deployment=deployment-0
18:47:43,770 INFO  [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location C:\BuildAgent\work\db872761b443af46\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-0\standalone\data\content\e9\cba0240887403555e28667f5418978f5d1ea93\content
18:47:43,772 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "stateful.war" (runtime-name: "stateful.war")
18:47:43,792 INFO  [org.jboss.as.jpa] (MSC service thread 1-6) WFLYJPA0002: Read persistence.xml for mypc
18:47:43,805 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 9) WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'stateful.war#mypc'
18:47:43,805 INFO  [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 9) HHH000204: Processing PersistenceUnitInfo [
	name: mypc
	...]
18:47:43,808 INFO  [org.hibernate.orm.deprecation] (ServerService Thread Pool -- 9) HHH90000001: Found usage of deprecated setting for specifying Scanner [hibernate.ejb.resource_scanner]; use [hibernate.archive.scanner] instead
18:47:43,814 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0003: Processing weld deployment stateful.war
18:47:43,818 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'StatefulBean' in deployment unit 'deployment "stateful.war"' are as follows:

	java:global/stateful/StatefulBean!org.jboss.as.test.clustering.cluster.ejb.xpc.bean.Stateful
	java:app/stateful/StatefulBean!org.jboss.as.test.clustering.cluster.ejb.xpc.bean.Stateful
	java:module/StatefulBean!org.jboss.as.test.clustering.cluster.ejb.xpc.bean.Stateful
	java:global/stateful/StatefulBean
	java:app/stateful/StatefulBean
	java:module/StatefulBean

18:47:43,818 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'SecondBean' in deployment unit 'deployment "stateful.war"' are as follows:

	java:global/stateful/SecondBean!org.jboss.as.test.clustering.cluster.ejb.xpc.bean.SecondBean
	java:app/stateful/SecondBean!org.jboss.as.test.clustering.cluster.ejb.xpc.bean.SecondBean
	java:module/SecondBean!org.jboss.as.test.clustering.cluster.ejb.xpc.bean.SecondBean
	java:global/stateful/SecondBean
	java:app/stateful/SecondBean
	java:module/SecondBean

18:47:43,878 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 9) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:43,878 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 9) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:43,879 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0006: Starting Services for CDI deployment: stateful.war
18:47:43,880 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 9) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:43,880 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 9) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:43,884 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 5) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:43,885 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0009: Starting weld service for deployment stateful.war
18:47:43,885 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 5) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:43,886 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 5) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:43,888 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 25) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:43,888 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 5) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:43,888 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 25) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:43,891 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 8) WFLYJPA0010: Starting Persistence Unit (phase 2 of 2) Service 'stateful.war#mypc'
18:47:43,893 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 9) WFLYCLINF0002: Started client-mappings cache from ejb container
18:47:43,893 INFO  [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 8) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect

org.jboss.as.test.clustering.cluster.ejb.xpc.StatefulWithXPCFailoverTestCase(SYNC-tcp).testSecondLevelCache: 	at org.jboss.as.test.clustering.cluster.ejb.xpc.StatefulWithXPCFailoverTestCase.testSecondLevelCache(StatefulWithXPCFailoverTestCase.java:178)
------- Stdout: -------
18:47:59,335 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Starting deployment=NONE, container=container-0
18:47:59,336 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Starting deployment=NONE, container=container-1
18:47:59,336 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Deploying deployment=deployment-0
18:47:59,349 INFO  [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location C:\BuildAgent\work\db872761b443af46\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-0\standalone\data\content\b5\1b8311d5d9e69fb032ec4ef43b064ff0bddb82\content
18:47:59,351 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "stateful.war" (runtime-name: "stateful.war")
18:47:59,370 INFO  [org.jboss.as.jpa] (MSC service thread 1-7) WFLYJPA0002: Read persistence.xml for mypc
18:47:59,384 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 8) WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'stateful.war#mypc'
18:47:59,384 INFO  [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 8) HHH000204: Processing PersistenceUnitInfo [
	name: mypc
	...]
18:47:59,388 INFO  [org.hibernate.orm.deprecation] (ServerService Thread Pool -- 8) HHH90000001: Found usage of deprecated setting for specifying Scanner [hibernate.ejb.resource_scanner]; use [hibernate.archive.scanner] instead
18:47:59,388 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0003: Processing weld deployment stateful.war
18:47:59,395 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'StatefulBean' in deployment unit 'deployment "stateful.war"' are as follows:

	java:global/stateful/StatefulBean!org.jboss.as.test.clustering.cluster.ejb.xpc.bean.Stateful
	java:app/stateful/StatefulBean!org.jboss.as.test.clustering.cluster.ejb.xpc.bean.Stateful
	java:module/StatefulBean!org.jboss.as.test.clustering.cluster.ejb.xpc.bean.Stateful
	java:global/stateful/StatefulBean
	java:app/stateful/StatefulBean
	java:module/StatefulBean

18:47:59,395 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'SecondBean' in deployment unit 'deployment "stateful.war"' are as follows:

	java:global/stateful/SecondBean!org.jboss.as.test.clustering.cluster.ejb.xpc.bean.SecondBean
	java:app/stateful/SecondBean!org.jboss.as.test.clustering.cluster.ejb.xpc.bean.SecondBean
	java:module/SecondBean!org.jboss.as.test.clustering.cluster.ejb.xpc.bean.SecondBean
	java:global/stateful/SecondBean
	java:app/stateful/SecondBean
	java:module/SecondBean

18:47:59,422 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 8) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:59,422 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 8) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:59,422 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0006: Starting Services for CDI deployment: stateful.war
18:47:59,424 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 8) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:59,424 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 8) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:59,427 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0009: Starting weld service for deployment stateful.war
18:47:59,429 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 8) WFLYCLINF0002: Started client-mappings cache from ejb container
18:47:59,432 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 84) WFLYJPA0010: Starting Persistence Unit (phase 2 of 2) Service 'stateful.war#mypc'
18:47:59,433 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 8) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:59,433 INFO  [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 84) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
18:47:59,433 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 8) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:59,433 WARN  [org.hibernate.dialect.H2Dialect] (ServerService Thread Pool -- 84) HHH000431: Unable to determine H2 database version, certain features may not work
18:47:59,435 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 31) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:59,435 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 31) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:59,441 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 83) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:59,441 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 83) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:59,443 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 31) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:59,443 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 31) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:47:59,448 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 8) WFLYCLINF0002: Started stateful.war cache from web container

org.jboss.as.test.clustering.cluster.jsf.JSFFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover: java.lang.AssertionError: expected:<200> but was:<500>
	at org.jboss.as.test.clustering.cluster.jsf.JSFFailoverTestCase.testGracefulUndeployFailover(JSFFailoverTestCase.java:375)
------- Stdout: -------
18:48:00,965 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Starting deployment=NONE, container=container-0
18:48:00,965 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Starting deployment=NONE, container=container-1
18:48:00,965 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Deploying deployment=deployment-0
18:48:00,992 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location C:\BuildAgent\work\db872761b443af46\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-0\standalone\data\content\c4\cd6227dd2cadb11d0c20186ea973f678be9665\content
18:48:00,993 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "numberguess-jsf.war" (runtime-name: "numberguess-jsf.war")
18:48:01,043 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0003: Processing weld deployment numberguess-jsf.war
18:48:01,065 INFO  [org.jboss.weld.deployer] (MSC service thread 1-8) WFLYWELD0006: Starting Services for CDI deployment: numberguess-jsf.war
18:48:01,070 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0009: Starting weld service for deployment numberguess-jsf.war
18:48:01,077 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 11) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:01,077 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 11) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:01,079 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 11) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:01,080 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 11) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:01,082 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 31) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:01,083 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 31) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:01,090 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 31) WFLYCLINF0002: Started numberguess-jsf.war cache from web container
18:48:01,092 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 11) WFLYCLINF0002: Started routing cache from web container
18:48:01,307 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 11) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/numberguess-jsf'
18:48:01,366 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 11) WFLYUT0021: Registered web context: /numberguess-jsf
18:48:01,376 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "numberguess-jsf.war" (runtime-name : "numberguess-jsf.war")
18:48:01,379 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Deploying deployment=deployment-1
18:48:01,390 INFO  [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location C:\BuildAgent\work\db872761b443af46\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-1\standalone\data\content\c4\cd6227dd2cadb11d0c20186ea973f678be9665\content
18:48:01,393 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0027: Starting deployment of "numberguess-jsf.war" (runtime-name: "numberguess-jsf.war")
18:48:01,419 INFO  [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment numberguess-jsf.war
18:48:01,445 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0006: Starting Services for CDI deployment: numberguess-jsf.war
18:48:01,450 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0009: Starting weld service for deployment numberguess-jsf.war
18:48:01,452 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 10) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:01,452 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 10) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:01,452 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 15) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:01,453 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 15) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:01,457 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 10) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:01,457 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 10) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:01,473 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 15) WFLYCLINF0002: Started routing cache from web container
18:48:01,476 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 10) WFLYCLINF0002: Started numberguess-jsf.war cache from web container
18:48:01,629 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 23) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/numberguess-jsf'
18:48:02,068 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 23) WFLYUT0021: Registered web context: /numberguess-jsf
18:48:02,081 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "numberguess-jsf.war" (runtime-name : "numberguess-jsf.war")
18:48:02,641 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Undeploying deployment=deployment-0
18:48:02,645 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 11) WFLYUT0022: Unregistered web context: /numberguess-jsf
18:48:02,649 INFO  [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 83) ISPN000029: Passivating all entries to disk
18:48:02,650 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0010: Stopping weld service for deployment numberguess-jsf.war
18:48:02,681 INFO  [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 83) ISPN000030: Passivated 3 entries in 33 milliseconds
18:48:02,684 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 83) WFLYCLINF0003: Stopped numberguess-jsf.war cache from web container
18:48:02,689 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment numberguess-jsf.war (runtime-name: numberguess-jsf.war) in 44ms
18:48:02,690 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 83) WFLYCLINF0003: Stopped routing cache from web container
18:48:02,703 INFO  [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0002: Content removed from location C:\BuildAgent\work\db872761b443af46\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-0\standalone\data\content\c4\cd6227dd2cadb11d0c20186ea973f678be9665\content
18:48:02,703 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0009: Undeployed "numberguess-jsf.war" (runtime-name: "numberguess-jsf.war")
18:48:03,291 ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /numberguess-jsf/home.jsf: javax.servlet.ServletException: viewId:/home.jsf - View /home.jsf could not be restored.
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:671)

org.jboss.as.test.clustering.cluster.jsf.JSFFailoverTestCase(SYNC-tcp).testGracefulSimpleFailover: java.lang.AssertionError: expected:<200> but was:<500>
	at org.jboss.as.test.clustering.cluster.jsf.JSFFailoverTestCase.testGracefulSimpleFailover(JSFFailoverTestCase.java:251)
------- Stdout: -------
18:48:03,360 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Starting deployment=NONE, container=container-0
18:48:03,360 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Starting deployment=NONE, container=container-1
18:48:03,360 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Deploying deployment=deployment-0
18:48:03,375 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location C:\BuildAgent\work\db872761b443af46\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-0\standalone\data\content\78\870f0f25ead650b43b6385c2b48c0126f56e13\content
18:48:03,377 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "numberguess-jsf.war" (runtime-name: "numberguess-jsf.war")
18:48:03,399 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0003: Processing weld deployment numberguess-jsf.war
18:48:03,437 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0006: Starting Services for CDI deployment: numberguess-jsf.war
18:48:03,443 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0009: Starting weld service for deployment numberguess-jsf.war
18:48:03,457 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 83) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:03,457 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 83) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:03,499 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 83) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:03,500 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 83) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:03,504 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 83) WFLYCLINF0002: Started numberguess-jsf.war cache from web container
18:48:03,511 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 11) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:03,512 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 11) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:03,517 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 11) WFLYCLINF0002: Started routing cache from web container
18:48:03,632 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 5) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/numberguess-jsf'
18:48:03,805 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 5) WFLYUT0021: Registered web context: /numberguess-jsf
18:48:03,814 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "numberguess-jsf.war" (runtime-name : "numberguess-jsf.war")
18:48:03,818 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Deploying deployment=deployment-1
18:48:03,829 INFO  [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location C:\BuildAgent\work\db872761b443af46\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-1\standalone\data\content\78\870f0f25ead650b43b6385c2b48c0126f56e13\content
18:48:03,831 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "numberguess-jsf.war" (runtime-name: "numberguess-jsf.war")
18:48:03,855 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment numberguess-jsf.war
18:48:03,884 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0006: Starting Services for CDI deployment: numberguess-jsf.war
18:48:03,889 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0009: Starting weld service for deployment numberguess-jsf.war
18:48:04,013 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 23) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:04,059 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 23) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:04,079 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 23) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:04,080 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 23) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:04,088 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 19) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:04,088 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 19) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
18:48:04,099 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 19) WFLYCLINF0002: Started numberguess-jsf.war cache from web container
18:48:04,155 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 23) WFLYCLINF0002: Started routing cache from web container
18:48:04,517 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 23) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/numberguess-jsf'
18:48:04,606 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 23) WFLYUT0021: Registered web context: /numberguess-jsf
18:48:04,617 INFO  [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0010: Deployed "numberguess-jsf.war" (runtime-name : "numberguess-jsf.war")
18:48:04,625 INFO  [org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase] (main) URLs are: http://[::1]:8080/numberguess-jsf/home.jsf, http://[::1]:8180/numberguess-jsf/home.jsf
18:48:04,708 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0
18:48:04,711 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 0ms timeout.
18:48:04,717 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
18:48:04,731 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel server
18:48:04,731 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel server
18:48:04,736 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 84) WFLYUT0022: Unregistered web context: /numberguess-jsf
18:48:04,752 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping
18:48:04,752 INFO  [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 31) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
18:48:04,755 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 31) MODCLUSTER000002: Initiating mod_cluster shutdown
18:48:04,761 INFO  [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 87) ISPN000029: Passivating all entries to disk
18:48:04,763 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-7) WFLYCLINF0003: Stopped local-query cache from hibernate container

retest this please

Windows Build 2657 outcome was FAILURE using a merge of 0bca18b95d2c9a62fec2afb6e500c026ca9c957d
Summary: Cannot start build runner Build time: 00:00:08

retest this please
And please use a VM with a JVM installed ;-)

@ctomc ^

Core - Full Integration Build 2263 outcome was FAILURE using a merge of 0bca18b95d2c9a62fec2afb6e500c026ca9c957d
Summary: Tests failed: 1 (1 new), passed: 3282, ignored: 363 Build time: 00:51:33
Failed tests
org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase.testEjb20TopicMDBs: java.lang.AssertionError: Reply message was null on reply queue: ActiveMQQueue[ejb2x/replyQueueA]
	at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase.testEjb20TopicMDBs(MDB20TopicTestCase.java:117)
------- Stdout: -------
 [0m18:50:03,603 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment mdb.jar (runtime-name: mdb.jar) in 15ms
 [0m [0m18:50:03,664 INFO  [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0002: Content removed from location /opt/buildAgent/work/db872761b443af46/full/testsuite/integration/basic/target/jbossas/standalone/data/content/68/aab9e33e933671decb3a3d178500439881bb6d/content
 [0m [0m18:50:03,664 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0009: Undeployed "mdb.jar" (runtime-name: "mdb.jar")
 [0m18:50:03,673 INFO  [org.jboss.as.test.integration.common.jms.JMSOperationsProvider] (main) Operation successful for update = {
    "operation" => "remove",
    "address" => [
        ("subsystem" => "messaging-activemq"),
        ("server" => "default"),
        ("jms-queue" => "ejb2x/queue")
    ]
}
18:50:03,690 INFO  [org.jboss.as.test.integration.common.jms.JMSOperationsProvider] (main) Operation successful for update = {
    "operation" => "remove",
    "address" => [
        ("subsystem" => "messaging-activemq"),
        ("server" => "default"),
        ("jms-queue" => "ejb2x/replyQueue")
    ]
}
18:50:03,695 INFO  [org.jboss.as.test.integration.ejb.mdb.ejb2x.AbstractMDB2xTestCase] (main) MDB20TopicTestCase.jar:
/org/
/org/jboss/
/org/jboss/as/
/org/jboss/as/test/
/org/jboss/as/test/integration/
/org/jboss/as/test/integration/ejb/
/org/jboss/as/test/integration/ejb/mdb/
/org/jboss/as/test/integration/ejb/mdb/ejb2x/
/org/jboss/as/test/integration/ejb/mdb/ejb2x/MDB20TopicTestCase$JmsQueueSetup.class
/org/jboss/as/test/integration/ejb/mdb/ejb2x/EJB2xMDB.class
/org/jboss/as/test/integration/ejb/mdb/ejb2x/AbstractMDB2xTestCase.class
/org/jboss/as/test/integration/common/
/org/jboss/as/test/integration/common/jms/
/org/jboss/as/test/integration/common/jms/JMSOperations.class
/org/jboss/as/test/integration/common/jms/JMSOperationsProvider.class
/org/jboss/as/test/integration/common/jms/ActiveMQProviderJMSOperations.class
/org/jboss/as/test/integration/common/jms/JMSOperationsException.class
/org/jboss/as/test/shared/
/org/jboss/as/test/shared/TimeoutUtil.class
/META-INF/
/META-INF/MANIFEST.MF
/META-INF/ejb-jar.xml
/META-INF/jboss-ejb3.xml
 [0m18:50:03,713 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 29) AMQ221003: trying to deploy queue jms.topic.ejb2x/topic
 [0m18:50:03,755 INFO  [org.jboss.as.test.integration.common.jms.JMSOperationsProvider] (main) Operation successful for update = {
    "operation" => "add",
    "address" => [
        ("subsystem" => "messaging-activemq"),

Agent was fixed earlier today


declaring necessary proptest for any implementation of a trait

Hi, I generally have the a thing-api and thing-lib, where the -api contains the public trait capturing the behaviours that thing offers. The actual implementation (e.g. struct TheRealThing) is in thing-lib.
I'd love to be able to define a bunch of invariants that any implementation of thing-api\ICanThing must implement, but I can't figure out how to do this with proptest.
I want to define a set of property tests in thing-api which thing-lib can call as separate property tests, providing the actual implementation, but I can't see how to inject the implementation from thing-lib into the proptests defined in thing-api without resorting to a macro.
I really want to write something like the following:
// thing-api
pub trait ICanThing {
  fn do_your_thing(&self);
}

pub fn assert_invariants(thing: impl ICanThing) {
  #proptest! {
    #[test]
    fn assert_invariant_one() { ... }
    #[test]
    fn assert_invariant_two() { ... }
  }
}

// thing-lib
pub struct TheRealThing {}
impl api::ICanThing for TheRealThing { ... }

#[test]
fn assert_invariants() {
  api::assert_invariants(TheRealThing {})
}

Is my only choice a macro in thing-api?
Thanks!
NOTE: at the moment the proptest stuff lives in thing-lib and works beautifully, but it feels like it is in the wrong place and really needs to be in thing-api

Well the macro just creates a runner and calls it, it's certainly possible to do that in macro-less code. But it's probably more verbose than is ideal. (Though it's probably possible to pull a lot of this into a helper function)
Off the top of my head, I could imagine an attribute macro that you could apply to a module containing a bunch of property tests that would create a function that can be called with a concrete instance of that trait, and would run all the tests against it, though that approach isn't without its drawbacks. The main one I can think of is that you'd essentially lose the granularity of tests (which your example also suffers from - there's only 1 #[test]).
Alternatively, such a macro could also generate a decl-macro that you could invoke in your lib crate that would expand into all the correct tests, and you could just provide a fn to get an implementor of the trait.
But I agree with you that the invariants make more sense being declared in the API crate, I just don't think it's worth losing the ability to cargo test invariant_1. In some crates I work with, there are proptests that take multiple hours to run, while others take seconds. And I don't think a custom proptest CLI would be the way to go.
I'll try to come up with a draft design when I'm in front of my laptop

thanks @cameron1024 - I'm excited to see what you come up with, but please don't think this is a urgent need! I think it's a interesting design question, but the existing implementation is more than good enough :-).

So IMO this is something that should be done after the attribute macro work is finished (in case you haven't seen, it just means the ability to write #[proptest] where you would usually write #[test] instead of using the function-like macro proptest! { }.
But I'd like to see something like this:
#[invariant_set(MyTrait)]
mod invariants {
  #[proptest]
  fn invariant_1(my_trait: impl MyTrait, s: String) {
    // my_trait is "any struct which implements `MyTrait`
    // s is an arbitrary string
    let foo = my_trait.frobnicate(s);
    assert!(foo.bar());
  }

  #[proptest]
  fn invariant_2(my_trait: impl MyTrait, s: String) {
    todo!()
  }
}

This would expand to a macro_rules invocation that can then be used like this (in the lib crate):
my_api_crate::my_trait_proptest_invariants!(MyTraitImplementor::new(1, 2, 3));

This generated macro would then expand to:
#[proptest]
fn invariant_1(s: String) {
  let my_trait = MyTraitImplementor::new(1, 2, 3);

  // my_trait is "any struct which implements `MyTrait`
  // s is an arbitrary string
  let foo = my_trait.frobnicate(s);
  assert!(foo.bar());
}

#[proptest]
fn invariant_2(s: String) {
  let my_trait = MyTraitImplementor::new(1, 2, 3);

  todo!()
}

This way, we get to keep individual tests that cargo test is aware of.
I don't think this would be too hard to implement, but I think it's not worth doing for the proptest! {} syntax, which there seems to be a general sentiment to move away from

yes - that looks much more composable. Nice. Thanks @cameron1024


Blog on DDEV golang debugging

This is a summary of last Wednesday's Contributor Training on DDEV Golang Debugging.
Suggestions and review welcome!
Rendered version at https://20240517-go-debugging.ddev-com-front-end.pages.dev/blog/golang-debugging

@mandrasch - you're in the video thumbnail here. Is that OK? (Your review in general is welcome also)

@mandrasch - you're in the video thumbnail here. Is that OK? (Your review in general is welcome also)

I saw it briefly on YouTube already, funny snapshot 😄
If it is not too much hassle, please change it - I don't really feel like being the face of Go debugging (yet) 😄
Blog post is a great summary from my perspective, awesome work to document it afterwards 👍

Done, thanks.


TypeError: Cannot call a class as a function

babel-preset-latest  cannot support class?
any other advice for me? thanks a lot.

This is not enough information, I don't understand your problem. With this template, Babel should transpile classes to ES5

Your error sounds like you did this:
var something = YourClass()

Where you should do this:
var something = new YourClass()

Closing for inactivity.

@LinusBorg thanks you saved my life


Include new dashboard "AWS Well-Architected Workload Lens Risks Report"

Added new dashboard for visualizing average risks across all workloads filter by Lens.

@marceloig Thank you for submitting this pull request, we truly value your contribution.
We will conduct a review and testing on our end, intending to include it in the next release.


Add API gateway

Resolves #14, #19, #20, #24
Overview
Previously, our question service was exposed, allowing anyone to use the endpoints. The API gateway provides automatic authentication, as well as provides ingress capabilities.

To review after PR #166


Hiding grades.yml

Is it true on repl.it that all hidden files are not viewable to the public? Or is .env exceptional?
If it's true that all hidden files are private, then we should consider making grades.yml hidden to protect tokens.
We should then add another command, something like rake fixtoken, to overwrite .grades.yml.

This may or may not be necessary anymore on Codio. Please check whether a) Codio workspaces are visible to students, b) even if they do share them with one another, can they see hidden files (I assume that yes, if they share a workspace then hidden files are visible)?

@raghubetina It looks like you can share Codio workspaces. I think by default they are available to Teachers. The settings are available in Project > Permissions.... You can choose to share with all teachers or all students or individual students. You then can further specify Read/Write/Admin access.
It looks like even just with read access will give the shared student the ability to see all files.

@jelaniwoods Alright; in that case it seems like this issue is pointless; no need to make grades.yml a hidden file, it won't do any good. Right?

@raghubetina yes it seems like all files are visible to anyone with read access—even hidden files.


Replacing fuzzer dependency for JS, Python and Go modules

Description
The JS, Python, and Go modules currently depend on api(project(":utbot-fuzzers")). Looks like this dependency should be replaces to implementation(project(":utbot-fuzzing")). In the future the better option is to get rid of all utbot-fuzzer module's classes.
It is assumed that utbot-fuzzers will be modified and used only for Java/Kotlin
Expected behavior
The utbot-js, utbot-python and utbot-go modules depend on implementation(project(":utbot-fuzzing")) and do not contain imports from org.utbot.fuzzer
Context
Much of the utbot-fuzzers module is specific to Java, for the most part, the JS, Python and Go modules use only FuzzedValue and UtFuzzedExecution.

@tamarinvs19 Anything else is planned here or we can close the case?

utbot-js still contains imports from utbot-fuzzer


Add Support for XR Interaction Toolkit

Currently it doesn't seems like UltimateXR Supports Unity's XR Interaction Toolkit which is something I would very much like to have while using the SDK.
It would be great if support for XR Interaction Toolkit could be added to the sdk which would make the developer experience much better.

Hi @Priyanshu-CODERX,
UltimateXR and Unity XR IT have a lot of overlapping functionality. What exactly from XRIT would you like to use with UltimateXR?

Hi @entromp
I am looking majorly for the hand interactions to work alongside of XRIT as that would help me a lot to build more accurate and reliable interactions for my applications and if possible I would also appreciate hand tracking integration of UltimateXR too.


Add organizations to data structure

Adding a ROR and calling id external_id. There will be a root type field which can be at least: institute, consortium, collaboration and project. But it may also need to contain other kinds of types.


Malaysian holidays

I've finally finished this.  It was a ton of work, but holidays for all 16 States made into it and they should work on a going forward basis.
Also wrote a very extensive 2021 test suite with a matrix of 768 cells, which I will replicate for 2022 once those dates are available and if required fix any remaining issues with the code.
EDITED TO ADD:
Includes #523 which I messed up in pushing:

Refactored Chinese lunisolar calendar calculation into the new LuniSolar class shared in utils.py. This lengthy code was duplicated in Hong Kong (where it originates from before I copied it), Singapore, and now Malaysia.
Used the new LuniSolar class for China holidays (instead of some Korean(!) library)
Renamed the shared function get_gre_date) (the original name I gave it) to islamic_to_gre, which is less confusing as we are now dealing with multiple calendars in utils.py.
Renamed isLeapYear function in HongKong to the Pythonic is_leap_year
A few docstring updates here and there

Fixed original failure of test by running pre-commit (for some reason git doesn't do it automatically for this project before pushing).  The tests now is failing for some unrelated Coverall issue, but the code does pass all local tox tests.

Sorry for dribbling new commits. The weekend is over so this will be the very last one and feel free to incorporate into beta.
Two final improvements:

I realized that Wesak day is calculated slightly differently in Malaysia than it is in Singapore (as Vesak day), and implemented this.  These calendars are nothing if convoluted, but fascinating.
I fixed all the docstrings so they now work beautifully in IDEs to make life simpler for developers (PyCharm below).  The base class HolidayBase and the countries Malaysia and Singapore have useful docstrings, as do all the helper functions in utils.py.

(of course I only now notice that there's a typo in the very first word of the shiny brand new Malaysia docstring depicted above, sigh; it will be for the next cleanup!).

Back to other work now; feel free to incorporate into beta.  Ciao!

Hey there Mike @mborsetti !
Thx a lot for your huge work.. it took me a while to check/merge to be honest, but in the end I didn't touch a byte!
..Great work as usual! this is the last commit before releasing.. time for 0.11.3 :)
Cheers 👍

Maurizio sorry for bungling the separate refactoring pull request; Git is still an untamed beast to me and by the time I realized what I did wrong it was too late.   I made it harder on you to review, and thanks for slogging through it.

Hey Mike that's no problem! Thanks for your work! 👍


Nixos/alps: init module

Description of changes

Added service definition for alps
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

What is missing:
[ ] Service restart does not work
[ ] Systemd target dependency is not correct

To acoid cluttering this pr with the packaging fixes, I extracted that part into a separate pr: https://github.com/NixOS/nixpkgs/pull/180699

Thanks for adding the reviews,  and thanks adding the service and adding yourself as a maintainer!
This LGTM after feedback from other reviews is applied.

@madonius can we help you with pushing this forward? :)


Geometry type seems to be silently cast to geography

Hey, I have the following definitions:
# Model
  schema "places" do
    field :name, :binary
    field :location, Geo.PostGIS.Geometry
  end

  def changeset(struct \\ %__MODULE__{}, attrs) do
    struct
    |> cast(attrs, @fields)
    |> validate_required(@fields)
  end

My migration:
    create table("places") do
      add :name, :binary
      add :location, :geometry
    end

And I try to use it as follows:
    google_maps_srid = 3857
    location = %Geo.Point{coordinates: {50.091211805442974, 19.89650102357312}, srid: google_maps_srid}
    %{name: "name", location: location}
    |> Place.changeset()
    |> Repo.insert()

I get the following error:
(Postgrex.Error) ERROR 22023 (invalid_parameter_value) Only lon/lat coordinate systems are supported in geography.

And insert log:
21:54:17.882 [debug] QUERY ERROR db=38.5ms queue=4.3ms
     INSERT INTO "places" ("location","name") VALUES ($1,$2) RETURNING "id" [%Geo.Point{coordinates: {50.091211805442974, 19.89650102357312}, properties: %{}, srid: 3857}, "Some name"]

It looks like somewhere along the way the geometry type is treated as geography but I fail at understanding where. Any help would be appreciated.

Hi, I'm running into the same bug. @kanes115 did you have any luck figuring this out?


purescript: 0.15.2 -> 0.15.3-3

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for purescript is: "A strongly-typed functional programming language that compiles to JavaScript"
meta.homepage for purescript is: "https://www.purescript.org/"
meta.changelog for purescript is: "https://github.com/purescript/purescript/releases/tag/v0.15.3-3"
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.15.3-3 with grep in /nix/store/c3zcmf2v1hp913dfa6a50pcx3p6znp74-purescript-0.15.3-3
found 0.15.3-3 in filename of file in /nix/store/c3zcmf2v1hp913dfa6a50pcx3p6znp74-purescript-0.15.3-3

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
pulp
purescript

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/c3zcmf2v1hp913dfa6a50pcx3p6znp74-purescript-0.15.3-3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A purescript https://github.com/r-ryantm/nixpkgs/archive/78295517f1cd88e39cf2f242514c4486ecf286b6.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/c3zcmf2v1hp913dfa6a50pcx3p6znp74-purescript-0.15.3-3
ls -la /nix/store/c3zcmf2v1hp913dfa6a50pcx3p6znp74-purescript-0.15.3-3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

pulp
purescript

Maintainer pings
cc @justinwoo @mbbx6spp @cdepillabout for testing.

I agree these should not be in nixpkgs (I'm on the PureScript core team). These prereleases are meant for folks to be able to check compiler work continuously and are not intended as stable releases. For example, while these prereleases can be downwloaded from NPM using npm i purescript@next, a normal installation npm i purescript will not download a prerelease version.
Perhaps this is something that could be changed in https://github.com/ryantm/nixpkgs-update so that prereleases are omitted, at least for this package?

Perhaps this is something that could be changed in https://github.com/ryantm/nixpkgs-update so that prereleases are omitted, at least for this package?

I imagine that would probably be the best solution, although I'm not familiar with the bot enough to know how easy implementing it would be.  At the very least, the bot/package is written in Haskell, so if someone from the PureScript community was interested in fixing this, I imagine they might not have too much trouble.

Actually, I think the problem is with the update script here in Nixpkgs; this line doesn't take prereleases into account.

FYI for when you do that, there's a GitHub endpoint specifically for the latest full release that you might want to use instead of the get-all-releases endpoint.


Update configure-aggregation-layer.md

This update removes a period after the swimlane graph. This period (IMO) is unnecessary, and it takes an extra line by itself thus create surprise for readers.
Screenshot:

/retitle Remove spurious period character


fix(tooltip): exception if mdTooltip is not a string

Fixes an error that is thrown if something rather than a string is passed via [mdTooltip] @Input, i.e:
@Component({
  selector: 'some-selector',
  template: '<div [mdTooltip]="myNumber">Content</div>'
})
export class SomeClass {

  myNumber = 3;
}

Results in the following error:

this._message.trim is not a function

PLUNKER

Can you add a unit test for this?

@crisbeto  I can't do this. It gives me error (the method signature asks for a string):

Type '{}' is not assignable to type 'string'.

You can change the testing component signature to something like string | null.

I'm not sure I follow what you mean. tooltipDirective is an instance of MdTooltip and there the signature of set message(..)  accepts (only) a string:
 set message(value: string) {
   this._message = value;
   this._setTooltipMessage(this._message);
 }

I was talking about one of the test components here: https://github.com/angular/material2/blob/master/src/lib/tooltip/tooltip.spec.ts#L523

Changing message to any still fail.

Closing due to #7018 and #7024. :)


chore(test): fix race on setupPrivateSSHKey

Fixes https://github.com/dagger/dagger/issues/8204 and reintroduces #8191
This PR addresses a data race where goroutines were potentially accessing testing.T after test completion. The solution implements a controlled shutdown mechanism using context cancellation and a WaitGroup.
Key changes:

Introduce context for cancellation signaling
Use sync.WaitGroup to track goroutines
Implement graceful shutdown in cleanup function

This resolves the race condition by:

Ensuring all goroutines complete before test finalization
Providing immediate shutdown signaling
Guaranteeing proper resource release order

The result is a thread-safe setup process that aligns with the test lifecycle, preventing any out-of-bounds operations.

Unable to understand the root cause of the failure, SGTM on my end

@jedevc @grouville I noticed that we changed this revert when this got merged:

https://github.com/dagger/dagger/pull/8196

I don't think that was intentional. I just put it back part of:

https://github.com/dagger/dagger/pull/8212

Once that gets merged, the revert will be reapplied. That's what I think we still want, but sharing here in case something changed since. cc @sipsma


[Usage] ValueError: Unknown image tower: /data1/ljq/Moellava/MoE-LLaVA-Qwen-1.8B-4e/clip-vit-large-patch14-336

Describe the issue
when i enter $ deepspeed --include localhost:0 /data1/ljq/Moellava/MoE-LLaVA-main/moellava/serve/cli.py --model-path "/data1/ljq/Moellava/MoE-LLaVA-Qwen-1.8B-4e" --image-file "/data1/ljq/Moellava/MoE-LLaVA-main/moellava/serve/examples/extreme_ironing.jpg",it turns errors what can i do?

The same problem. Do you solve it, buddy? I made some attempts, but still ERROR.

The same problem. Do you solve it?

您的来件已收到，我会尽快查看，辛苦了。


Release new version

Can we get a release with the latest?

This would be greatly appreciated @kallisti-dev.
I have tested the four open PRs in my fork for some integration testing we're doing at work, and they're working for selenium with Chrome. If those can be merged as well that'd be fantastic.
I'm open to helping to maintain this project as well so if you want to add me to the committers, that'd be great.

My apologies for the delay on release. I haven't had as much free time
available for open source dev unfortunately. I'll look at the pull requests
tonight and push a release. I'll also be looking at giving commit access to
interested contributors.
Thank you for your patience.
On Apr 12, 2017 7:49 PM, "Matt Parsons"<EMAIL_ADDRESS>wrote:

This would be greatly appreciated @kallisti-dev
https://github.com/kallisti-dev.
I have tested the four open PRs in my fork for some integration testing
we're doing at work, and they're working for selenium with Chrome. If those
can be merged as well that'd be fantastic.
I'm open to helping to maintain this project as well so if you want to add
me to the committers, that'd be great.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kallisti-dev/hs-webdriver/issues/120#issuecomment-293738469,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABdZhH-xUtzs4SDtk-S8BYRNhvLEpAv-ks5rvWMegaJpZM4MAujV
.

0.8.5 is on Hackage now. Thanks again for your patience.

Looks like Travis builds are failing for GHC 7.4 and 7.6. Odd considering that all the pull requests passed.


chore: support for disable automated sync

Fixes #255
Modifications
Support disabling automated sync for all gitsyncs in the cluster.
Verification

Actually, should we be doing this on an individual file basis?
If auto heal is off, I'm a user, and I manually update my Deployment resource in the cluster but then I change my ConfigMap spec in github, I want my ConfigMap to get updated but I don't want my Deployment to be auto-healed.

Actually, should we be doing this on an individual file basis?
If auto heal is off, I'm a user, and I manually update my Deployment resource in the cluster but then I change my ConfigMap spec in github, I want my ConfigMap to get updated but I don't want my Deployment to be auto-healed.

Yeah, can you create an issue to track this feature? Thanks!

Yeah, can you create an issue to track this feature? Thanks!

Done. I guess I was more thinking it was a Bug - not sure if you agree?
https://github.com/numaproj-labs/numaplane/issues/261

Yeah, can you create an issue to track this feature? Thanks!

Done. I guess I was more thinking it was a Bug - not sure if you agree? #261

Not quite agree, to me this is a feature to auto heal at individual resource level instead of whole gitsync.


Support for Retrieval in OpenAI Assistants (File Search)

Enhance OpenAI agents with File Search capabilities as outlined in the assistants API - https://platform.openai.com/docs/assistants/tools/file-search

Duplicate of #55


Make use of scalafmt and remove the creation of akka materializer

Need to check why the tests are not running. Valid reason to move to testcontainers as soon as possible rather than spinning docker-compose files all over

Hey @Tochemey ,
Thanks for the contribution! I'll have a look at the PR today or tomorrow when I have more free time.
Regarding your testcontainers suggestion, I am afraid but I cannot accept such change:

Docker occasionally have changes that are not backward-compatible and the changes don't always hit upstream quickly.
I swing between 4 language and having to keep up with each one's syntax peculiarities is something I would rather avoid.

FYI, I have fixed the issue with the failing mysql container, which was triggered by this change

@chmodas I really don't understand the reason behind using testcontainers.

@Tochemey , I've outlined the reasons why I don't like using testcontainers in the issue you've opened (#107).

You can find the reasons for using Docker Compose in the first place in the other issue you've opened - #108

@chmodas all I can say it makes sense to make it serde even though I don't like shortcut naming even if you can say it is conventional.

@Tochemey let me know when you push the last changes we agreed on so I can merge.

@chmodas all I can say it makes sense to make it serde even though I don't like shortcut naming even if you can say it is conventional. I totally agree with the point you made and I have used the same path.

Hey I will probably take a look in the weekend.

@Tochemey let me know when you push the last changes we agreed on so I can merge.

Hey @chmodas I will probably take a look in the weekend

@chmodas I think I have fixed the formatting. You can take a look. Feel free to update the PR or discard it if you are still not satisfied. I am afraid I will have time to continue on it. Thanks


code changes don't reload monarch

Target copy_flutter_bundle failed: Exception: Flutter failed to copy ..\f_common_widgets_flutter\.dart_tool\flutter_build\0cf 2e1c3577630af4f31f6666d4b20e1\app.dill to .monarch\flutter_assets\kernel_blob.bin due to unknown error. The flutter tool cannot access the file or directory. Please ensure that the SDK and/or project is installed in a location that has read/write permissions for the current user.
any ideas?

when not running monarch from a terminal within my IDE than it works

I'll try it. Which IDE do you use?

Android Studio

Yes I am, but the problem does not occur any more. Sorry for the incovenience. Closing the issue


[cmake] Fix a few issues around swift cmake support build/test

Specifically I did the following:

add_swift_host_tool was adding a -L flag for the just built runtime to host code (before the -L to the host runtime!). This is incorrect and caused us to have a race that sometimes resulted in us mixing/matching binary artifacts and other weirdness.
I changed add_swift_host_library and add_swift_host_tool to not assume that the subdirectory we are in defines LLVM_COMMON_DEPENDS and to instead just respect it if it is set. The reason I did this is philosophically I don't think that things that do not depend on LLVM libraries (like my swift-cmake tests which are really simple) should have to define LLVM_COMMON_DEPENDS and also it makes it so that swift-cmake is no longer dependent on specific tools being built (like swift syntax) which causes these tests to not be built if the tools are not built. This test is meant to make sure that swift host side toolchain can build simple swift libraries and smoke out any errors, not actually depend on the tools we build.

@swift-ci smoke test windows


streamlink: 0.10.0 -> 0.12.1

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/streamlink/versions.
These checks were done:

built on NixOS
ran ‘/nix/store/7rxcwgcznrsqj6kkvrxi8j2ggjx3il4v-streamlink-0.12.1/bin/.streamlink-wrapped -h’ got 0 exit code
ran ‘/nix/store/7rxcwgcznrsqj6kkvrxi8j2ggjx3il4v-streamlink-0.12.1/bin/.streamlink-wrapped --help’ got 0 exit code
ran ‘/nix/store/7rxcwgcznrsqj6kkvrxi8j2ggjx3il4v-streamlink-0.12.1/bin/.streamlink-wrapped -V’ and found version 0.12.1
ran ‘/nix/store/7rxcwgcznrsqj6kkvrxi8j2ggjx3il4v-streamlink-0.12.1/bin/.streamlink-wrapped --version’ and found version 0.12.1
ran ‘/nix/store/7rxcwgcznrsqj6kkvrxi8j2ggjx3il4v-streamlink-0.12.1/bin/streamlink -h’ got 0 exit code
ran ‘/nix/store/7rxcwgcznrsqj6kkvrxi8j2ggjx3il4v-streamlink-0.12.1/bin/streamlink --help’ got 0 exit code
ran ‘/nix/store/7rxcwgcznrsqj6kkvrxi8j2ggjx3il4v-streamlink-0.12.1/bin/streamlink -V’ and found version 0.12.1
ran ‘/nix/store/7rxcwgcznrsqj6kkvrxi8j2ggjx3il4v-streamlink-0.12.1/bin/streamlink --version’ and found version 0.12.1
found 0.12.1 with grep in /nix/store/7rxcwgcznrsqj6kkvrxi8j2ggjx3il4v-streamlink-0.12.1
directory tree listing: https://gist.github.com/09fbfb8c035d471bd38a592acf455d9a

cc @dezgeg @zraexy for testing

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: streamlink
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: streamlink
Partial log (click to expand)
test_read_timeout (tests.test_buffer.TestRingBuffer) ... ok
test_resize (tests.test_buffer.TestRingBuffer) ... ok
test_write (tests.test_buffer.TestRingBuffer) ... ok
test_write_after_close (tests.test_buffer.TestRingBuffer) ... ok

----------------------------------------------------------------------
Ran 424 tests in 25.322s

OK (skipped=20)
/nix/store/g54xcbvpai9qwf873irdib6kfzk5hbxz-streamlink-0.12.1

Success on x86_64-linux (full log)
Attempted: streamlink
Partial log (click to expand)
test_can_handle_url (tests.test_plugin_cyro.TestPluginCyro) ... ok
test_can_handle_url (tests.test_plugin_tv5monde.TestPluginTV5Monde) ... ok
test_can_handle_url (tests.test_plugin_rtbf.TestPluginRTBF) ... ok
test_can_handle_url (tests.test_plugin_streann.TestPluginStreann) ... ok

----------------------------------------------------------------------
Ran 424 tests in 11.315s

OK (skipped=20)
/nix/store/7rxcwgcznrsqj6kkvrxi8j2ggjx3il4v-streamlink-0.12.1


Fix IDBKeyVal get returning undefined instead of null

Details
getItem is supposed to return null when the value doesn't exist in storage. This is what the native sqlite storage implementation does, as well as what the function documentation says.  However https://github.com/jakearchibald/idb-keyval#get returns undefined when the value doesn't exist so we need to convert it to null.
This caused some issues where some components would stay stuck in loading state because in onyx we assume undefined means the key value has not been loaded from storage, non-existing keys are represented by null. The issue was reported here https://github.com/Expensify/App/pull/29169#issuecomment-1783386090.
Related Issues
https://github.com/Expensify/App/pull/29169
Automated Tests
N/A
Manual Tests
Tested in Expensify app with https://github.com/Expensify/App/pull/29169. On web, opening settings will cause a blank screen to open. After this fix it loads properly.
Author Checklist

[x] I linked the correct issue in the ### Related Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome
Before:

After:

Mobile Web - Safari

Desktop

iOS

Android

I'm getting some unexpected report preview loading behaviour when testing this PR (but probably stemming from https://github.com/Expensify/react-native-onyx/pull/401), as well as the RHP generally rendering less snappily:
https://github.com/Expensify/react-native-onyx/assets/27287420/a87d7647-6cc2-468f-83a2-269533326021
Note that the IOU preview and header aren't rendering at the same time. Compare with v1.0.107:
https://github.com/Expensify/react-native-onyx/assets/27287420/5fa11fda-2508-4d8c-b615-7f21a80019c8

@jjcoffee Do you know if this happens only on this PR and not on main? Or is it a regression since 1.0.107?

It looks like a regression since 1.0.107.

I've tested against #401 with this fix added and I'm not seeing the same issue, so must be unrelated!

Sorry! I don't have any ideas what can be causing that, but it sounds like we are OK to merge this.

@mountiny would you approve and merge this, please?

I can confirm the regression @jjcoffee found is related to https://github.com/Expensify/react-native-onyx/pull/401, looking at what is going on exactly now.


User Account: Trailing volume

implemented - not tested. Will rename in the next pull request as I see I've not named it very well. See: UserAccountService.getUserAccounts()

Assigning to self to ensure there is a test for it.


COR-350 fix(clerk-js): Add password bytes exceeded error message

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[x] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

Packages affected

[x] @clerk/clerk-js
[ ] @clerk/clerk-react
[ ] @clerk/nextjs
[ ] @clerk/remix
[x] @clerk/types
[ ] @clerk/themes
[x] @clerk/localizations
[ ] @clerk/clerk-expo
[ ] @clerk/backend
[ ] @clerk/clerk-sdk-node
[ ] @clerk/shared
[ ] @clerk/fastify
[ ] @clerk/chrome-extension
[ ] gatsby-plugin-clerk
[ ] build/tooling/chore

Description

[ ] npm test runs as expected.
[ ] npm run build runs as expected.

Add password bytes exceeded error message

Why is there a change in package-lock.json? Seems unrelated.
Other than that, looks good to me.

This resulted after pulling the latest main branch and doing npm install.  cc @nikosdouvlis do you think this is an issue?

@raptisj I just rebased from main, this is good to go.


Update docs: config > options

The internal replacement of config > options throughout the distribution also changed the locally injected config to be named options.  This PR updates the docs to reflect that change.
Blame: https://github.com/auth0/angular-jwt/commit/bb6a838b6e105c6c04d534125d02bdbbdaf3e3ba#diff-0842e4bf8332d56a93631c40e495aef3R115

Oh sorry, should’ve looked, but GH-85 also does this!

Thanks for this :) closing as 85 was just merged.


[BUG] "coutme" should be "countme"

https://github.com/tommytran732/Linux-Setup-Scripts/blob/eb421d1fe451f3041f6f8a743b29ee65e55aa709/Fedora-Workstation-36.sh#L45
Source: https://www.privacyguides.org/linux-desktop/overview/#system-counting

Fixed


is it possible to load monaco within a VSCode Extension?

I'm using the monaco-editor-webpack-plugin to load monaco within a vscode extension, but I'm running into an error around the webworkers when it loads the json language:
Uncaught ReferenceError: importScripts is not defined

is just not supported?

AFAIK, Webview doesn't allow web workers being loaded. Please continue the discussion in the VS Code issue you created, thanks!

shouldn’t it fall back to something? for example the json one shouldn’t be able to fall back?


File names and structures...

Some changes  to the file should be implemented:

consistency in headers & some logical structure (e.g. lower case; sample_id, probe_id, reference_name, segment_start, segment_end)
I suggest making the "value" columns non-descriptive and open ended; i.e. value[1..n]. I would keep the value_1, value_2 ... example, but allow a undefined numer of columns (one could set a max. like 127, to block run-away data ...)
I am not sure if we can include the liftover bibnary?
I'm not happy with the "CNprobes" file name; so maybe just use "probes" (with an internal recognition of ^(?:CN)?probes(?:,chr\w\d?)\.tab$

New files will have consistent headers now (replace the old headers):

for probes: probe_id, chromosome, position
for segments: segment_id , chromosome, start, end

Other column names are kept the same in new files.
liftover binary is off.
Can specify new files names now, we'll use "segments,cn.tsv" and "probes,cn.tsv"

Can specify new files names now, we'll use "segments,cn.tsv" and "probes,cn.tsv"

Yes, let's do this. I'll grep over my source tree, too.


[Feature Request] Limit amount of messages for a role

Hi,
As explained in the title, a way to limit spam. For example : .lspm BasicUser 100 allows users with BasicUser role to send only 100 messages every 24h in this channel (time could be an argument too).

Too specific, not happening, just use .slowmode i guess if it fits


Correct argument of CPU_ISSET for glibc <2.5

fixes #2104

Yes, I was able to reproduce the originally reported OpenBLAS build failure and confirm a restored OpenBLAS build using the patch provided by this PR in a manylinux1 container:
docker pull quay.io/pypa/manylinux1_x86_64
docker run -it quay.io/pypa/manylinux1_x86_64
git clone https://github.com/xianyi/OpenBLAS.git
make # with or without this patch


Experimental API for dynamic UDF parameter updates

This allows to dynamically update UDF parameters while LiberTEM is running the UDF. Implemented for dask, pipelined, inline, and concurrent for now (not implemented for delayed).
With this patch applied, the following code works:
result_iter = lt_ctx.run_udf_iter(dataset=default_raw, udf=[DynamicParamsUDF(latest_index=0)])
with contextlib.closing(result_iter) as result_iter:
    for idx, part_res in enumerate(result_iter):
        # a list of dicts, with one dict for each UDF in the `run_udf_iter` call:
        result_iter.update_parameters_experimental([
            {"latest_index": idx + 1}
        ])

In combination with LiberTEM-live, this gives you interactivity while a scan is running.
Discussion points

How does this integrate with the UDF interface? It might be needed to declare UDF parameters, and how/if they can change over time

Possibly defer this for now? Or add a section to docs that UDF authors should document if parameters can vary

This already makes it possible to implement tighter-than-per-scan feedback loops, if a certain remaining latency can be tolerated (upper bound n_workers * processing_time_per_partition basically)
If we want to reduce the latency further, we would have to have out-of-band communication - for example, the UDF could actively query an "in-memory database" about the most recent values of certain parameters, or there could be a second set of queues
How does this relate to per-frame metadata? I.e. "zipping" the normal data stream with a matching stream of metadata. This certainly needs a different interface on the sending side/data source, but can the UDF side be the same for both use cases?

TODO

[x] Update parameters for UDF.merge and other functions that run on the main node
[x] Executor support - which ones are doable?
[x] Un-flake the tests (maybe we can actually synchronize somehow instead of relying on flimsy timing)
[ ] Move code: new classes might not be so happy in libertem.udf.base or libertem.api
[x] Implement "patching"/partial updates of UDF parameters
[x] Documentation

Contributor Checklist:

[ ] I have added or updated my entry in the creators.json file
[x] I have added a changelog entry for my contribution
[x] I have added/updated documentation for all user-facing changes
[x] I have added/updated test cases
[ ] I have included the rebuilt production build of the client (only if changes were made to the GUI)

Reviewer Checklist:

[ ] /azp run libertem.libertem-data passed
[ ] No import of GPL code from MIT code

@matbryan52 @uellue this also ties in with the pre-process-before-running ideas we discussed last month - in some cases, the pre-processing when changing parameters can happen concurrently with the running data acquisition, and once done, the new parameters are pushed to the workers.

/azp run libertem.libertem-data

This is looking great, and surprisingly simple in the implementation!
From my understanding, the implication is that the List[params] passed to result_iter.update_parameters are all the **kwargs passed to the UDFs __init__ and accessible normally under self.params.<name> within the UDF process methods? In this case params will always be a dict-like?
To cover the case of only wanting to do a partial update of the params, could we use dict.update between the existing scattered params and the scatter_update params, easiest to see in the PipelineExecutor case, where currently you replace fully:
work_mem[key] = header["value"]

instead:
for existing_kwargs, kwarg_update in zip(work_mem[key], header["value"]):
    existing_kwargs.update(kwarg_update)

Then an update like result_iter.update_parameters([{}, {}, {'b': 55}]) would only update parameter 'b' on the third UDF.
As an alternative, since the ResultsForDataSet is provided on the main node and hence has the same UDF objects that the user supplied, could we even provide something like:
class ResultsForDataSet:
   ...

   def update_udf_params(self, udf, **params):
        # Supply one-or-more param updates to a single UDF
        # Logic to lookup the index of `udf` within `params`
         ...

retaining the existing endpoint for a batch update of multiple sets of UDF params at once.

Thanks for having a look!

From my understanding, the implication is that the List[params] passed to result_iter.update_parameters are all the **kwargs passed to the UDFs __init__ and accessible normally under self.params.<name> within the UDF process methods? In this case params will always be a dict-like?

Yes - this is how we build the self.params thingy and how we separately scatter the parameters from the task object - we extract the **kwargs from UDF._kwargs, which are then put into an UDFParams object.

To cover the case of only wanting to do a partial update of the params, could we use dict.update between the existing scattered params and the scatter_update params, easiest to see in the PipelineExecutor case, where currently you replace fully:
work_mem[key] = header["value"]

instead:
for existing_kwargs, kwarg_update in zip(work_mem[key], header["value"]):
    existing_kwargs.update(kwarg_update)

Hmm - I have to think a bit about this. In general I agree that this is nice to have (especially if you have some large parameters!) - on the other hand, right now the executor doesn't know about the inner structure of the scattered object. Maybe the generic idea of this is a scatter_update_patch method for the executor, which assumes some structure for the object that is scattered. Something like an interface Updatable with a method update(self, patch) where patch is some opaque object which updates self in some way.
The above loop won't directly work, as work_mem[key] is  an UDFParams instance, which is not iterable. So in the concrete use-case for UDFParams, we would add a method UDFParams.update(self, patch: List[dict]) which would implement the loop above, and which would be called on the worker by the respective executors.
Does that make sense?

Then an update like result_iter.update_parameters([{}, {}, {'b': 55}]) would only update parameter 'b' on the third UDF.

One case this doesn't completely cover is optional parameters, i.e. going from a concrete value to not specifying said value. Then one has to specify the default value explicitly (could be None, but could also be something else). I'd be fine with this, if we properly document this.

As an alternative, since the ResultsForDataSet is provided on the main node and hence has the same UDF objects that the user supplied, could we even provide something like:
class ResultsForDataSet:
   ...

   def update_udf_params(self, udf, **params):
        # Supply one-or-more param updates to a single UDF
        # Logic to lookup the index of `udf` within `params`
         ...

True - I think I discussed this shortly with @uellue too, and I convinced him that list-of-dict is fine, as this is symmetric to how you get the results with run_udf_iter. But we still may want to re-consider this...
One nice thing about the list-of-dict API is that as a user, you don't necessarily need to keep track of the UDF instances. I'm thinking of a pattern like this:
udf_parameters : List[dict] = get_current_parameters()
udf_classes = get_udf_classes()
udfs = [cls(**params) for cls, params in zip(udf_classes, udf_parameters)]
res_iter = ctx.run_udf_iter(dataset=ds, udfs=udfs):
    new_parameters = get_current_parameters()  # this might re-calculate based on user input, or update parameters based on latest results or whetever
    if new_parameters != udf_parameters:
        res_iter.update_parameters(new_parameters)  # ... possibly not `new_parameters` directly, but a patch between `udf_parameters` and `new_parameters`
        udf_parameters = new_parameters

What kind of pattern did you think of, where the update(udf, params) style would make most sense?
Btw this makes me think of something else - right now we only update the UDF instances on the workers, but the parameters of the UDF instance where the merge function is running, i.e. the main process, might also need to be updated in the same way...

retaining the existing endpoint for a batch update of multiple sets of UDF params at once.

:+1:

I haven't dug into it but I assume the update will work for params which are BufferWrapper, too ?

Probably - I think the only way these are handled differently is in per-task initialization, and when you access them form the UDF. But a good point that we should have at least a test case for this.

Another topic is executor support.

inline: done, tested
pipelined: done, needs integration test
concurrent: eagerly creates futures for all tasks
dask: does limit the number of in-flight futures, so new futures could (in theory) use the new parameters. Or we could try to control the scatter keys that are used by scattering a dict, but I'm not sure I'm reading the API docs correctly...
delayed: I think same issue as concurrent? Also IIRC no real support for partial results?

I think mostly the issue is that tasks are generated eagerly in most executors, meaning they are basically a closure over the initial parameters. But concurrent could be changed to not have too many in-flight futures, similarly to the dask executor, creating futures on demand and with updated parameters, if they changed.
Another question is, how useful is this feature for offline processing? Maybe if the processing is slow and you can already see that the results are incorrect?

Discussion with @uellue:

Some UDFs currently rely on changing parameters (example: the record UDF which will probably fail completely if parameters aren't passing through the UDF constructor, which does something different on main node vs. on workers)
Patching semantics make sense: users don't want to have parameters in the update dict which should not be changed
It could be necessary to pass newly constructed UDF instances instead of only the parameters, so we know that the parameters have been through the constructor

Then we need to compare parameters with the old ones to implement patching, which gives rise to the question of either doing a shallow object-identity comparison vs doing a deep equality check. The latter can be quite expensive (dask uses hashing for this and puts a 500MB/s number to it...), but would possibly be expected by the user for efficient updates of large array parameters.

Hmm, there is also a connection to our discussion in Grenoble - the way things are pointing, the outer parameters of UDFs should be JSON-serializable in the future, if this is possible at all. This is important if we want to build a live-processing server that runs any number of UDFs, remotely from the user interface. If we have a preprocess step, for example for baking trotter stacks for SSB, then this has to be re-run on parameter changes. If the outer parameters of the UDF are JSON serializable, it is also no big deal to do a deep comparison for efficient delta updates.
JSON-serializable parameters also aligns with extending the ideas at #1376 to support complete specification of a "batch job": a dataset plus a list of UDFs plus their parameters, all specified in a TOML (or YAML/JSON) file. I think we discussed something in this direction already before.
One possibility I discussed with @uellue: introduce this interface first as update_parameters_experimental, which is replaced in the future with a more fleshed-out update_parameters method. The replacement then supports declarative parameters, better aux data (however that looks like), etc. and incorporates any lessons learned from the low-level experimental method.
I hope I captured the essence of our discussion @uellue - feel free to add anything I missed!

/azp run libertem.libertem-data

/azp run libertem.libertem-data

/azp run libertem.libertem-data

/azp run libertem.libertem-data

/azp run libertem.libertem-data

/azp run libertem.libertem-data

If I understand correctly, there's an orphaned set of methods to perform a full update that is not documented and not covered by tests? Maybe remove it, comment it out, ...?

I'll remove them, good catch.

If I understand correctly, it would allow updating something that cannot be patched? Otherwise the only difference to patching all parameters would be that it can eliminate parameters altogether instead of setting them to some value?

Yeah, exactly: there is one corner case that is not obvious with the patch API: if you want to go back to the default value for a parameter, you need to explicitly specify the default value, you can't just leave it out. But that should not be too common, so I went ahead and implemented the patching version, just didn't remove all the full update methods yet.

/azp run libertem.libertem-data