[JBoss JIRA] (WFCORE-939) Embedded host controller should set lunch type attribute to EMBEDDED
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-939?page=com.atlassian.jira.plugin... ]
Petr Kremensky updated WFCORE-939:
----------------------------------
Description:
*DomainRootDefinition.java* always set launch type to {noformat}new LaunchTypeHandler(ServerEnvironment.LaunchType.DOMAIN){noformat} even if the host controller process is embedded.
Looking into the LaunchType class, I believe that EMBEDDED value should be used.
{noformat}
/** The manner in which a server can be launched */
public static enum LaunchType {
/** Launched by a Host Controller in a managed domain */
DOMAIN(ProcessType.DOMAIN_SERVER),
/** Launched from the command line */
STANDALONE(ProcessType.STANDALONE_SERVER),
/** Launched by another process in which the server is embedded */
EMBEDDED(ProcessType.EMBEDDED_SERVER),
...
{noformat}
\\
*Additional info:*
{noformat}./standalone.sh
launch-type STANDALONE
{noformat}
{noformat}./domain.sh
launch-type DOMAIN
{noformat}
{noformat}[disconnected /] embed-server
launch-type EMBEDDED
{noformat}
{noformat}[disconnected /] embed-host-controller
launch-type DOMAIN
{noformat}
> Embedded host controller should set lunch type attribute to EMBEDDED
> --------------------------------------------------------------------
>
> Key: WFCORE-939
> URL: https://issues.jboss.org/browse/WFCORE-939
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Ken Wills
>
> *DomainRootDefinition.java* always set launch type to {noformat}new LaunchTypeHandler(ServerEnvironment.LaunchType.DOMAIN){noformat} even if the host controller process is embedded.
> Looking into the LaunchType class, I believe that EMBEDDED value should be used.
> {noformat}
> /** The manner in which a server can be launched */
> public static enum LaunchType {
> /** Launched by a Host Controller in a managed domain */
> DOMAIN(ProcessType.DOMAIN_SERVER),
> /** Launched from the command line */
> STANDALONE(ProcessType.STANDALONE_SERVER),
> /** Launched by another process in which the server is embedded */
> EMBEDDED(ProcessType.EMBEDDED_SERVER),
> ...
> {noformat}
> \\
> *Additional info:*
> {noformat}./standalone.sh
> launch-type STANDALONE
> {noformat}
> {noformat}./domain.sh
> launch-type DOMAIN
> {noformat}
> {noformat}[disconnected /] embed-server
> launch-type EMBEDDED
> {noformat}
> {noformat}[disconnected /] embed-host-controller
> launch-type DOMAIN
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (WFCORE-939) Embedded host controller should set lunch type attribute to EMBEDDED
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-939?page=com.atlassian.jira.plugin... ]
Petr Kremensky moved JBEAP-951 to WFCORE-939:
---------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-939 (was: JBEAP-951)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: CLI
Domain Management
(was: CLI)
(was: Domain Management)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.0.Beta4
(was: 7.0.0.DR9)
> Embedded host controller should set lunch type attribute to EMBEDDED
> --------------------------------------------------------------------
>
> Key: WFCORE-939
> URL: https://issues.jboss.org/browse/WFCORE-939
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Environment: *DomainRootDefinition.java* always set launch type to {noformat}new LaunchTypeHandler(ServerEnvironment.LaunchType.DOMAIN){noformat} even if the host controller process is embedded.
> Looking into the LaunchType class, I believe that EMBEDDED value should be used.
> {noformat}
> /** The manner in which a server can be launched */
> public static enum LaunchType {
> /** Launched by a Host Controller in a managed domain */
> DOMAIN(ProcessType.DOMAIN_SERVER),
> /** Launched from the command line */
> STANDALONE(ProcessType.STANDALONE_SERVER),
> /** Launched by another process in which the server is embedded */
> EMBEDDED(ProcessType.EMBEDDED_SERVER),
> ...
> {noformat}
> \\
> *Additional info:*
> {noformat}./standalone.sh
> launch-type STANDALONE
> {noformat}
> {noformat}./domain.sh
> launch-type DOMAIN
> {noformat}
> {noformat}[disconnected /] embed-server
> launch-type EMBEDDED
> {noformat}
> {noformat}[disconnected /] embed-host-controller
> launch-type DOMAIN
> {noformat}
> Reporter: Petr Kremensky
> Assignee: Ken Wills
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (WFLY-5235) CDI interceptors are not called when invoking observer method
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-5235?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-5235:
------------------------------------
[~dweil] Could you post the full stack trace? A reproducer/test application would be helpful as well.
> CDI interceptors are not called when invoking observer method
> -------------------------------------------------------------
>
> Key: WFLY-5235
> URL: https://issues.jboss.org/browse/WFLY-5235
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 9.0.1.Final
> Reporter: Dirk Weil
> Assignee: Martin Kouba
>
> The following code runs with an active transaction on WFLY 8.2.0, but failes with an TransactionRequiredException on WFLY 9.0.1:
> @ApplicationScoped
> public class InitCocktailDemoDataService
> {
> @PersistenceContext
> private EntityManager entityManager;
> @Transactional
> private void createDemoData(@Observes @Initialized(ApplicationScoped.class) Object event)
> {
> this.entityManager.merge(someEntity);
> }
> It seems that interceptors aren't called at all - at least for observers of scope lifecycle events.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (WFLY-5160) SingletonDeployment*TestCase fail on RHEL7
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-5160?page=com.atlassian.jira.plugin.... ]
Marek Kopecký reopened WFLY-5160:
---------------------------------
This issue is still valid on wildfly master
> SingletonDeployment*TestCase fail on RHEL7
> ------------------------------------------
>
> Key: WFLY-5160
> URL: https://issues.jboss.org/browse/WFLY-5160
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Marek Kopecký
> Assignee: Paul Ferraro
> Fix For: 10.0.0.Beta2
>
>
> *Description of problem:*
> * Two tests fail with "expected:<405> but was:<200>" error
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentJBossAllTestCase(SYNC-tcp)#test
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentDescriptorTestCase(SYNC-tcp)#test
> *How reproducible:*
> * RHEL7
> * IBM JDK 8, Oracle JDK 8, Open JDK 8
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Dtest=SingletonDeploymentJBossAllTestCase,SingletonDeploymentDescriptorTestCase -DfailIfNoTests=false -Dts.clustering
> *Actual results:*
> {noformat}
> java.lang.AssertionError: expected:<405> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentTestCase.test(SingletonDeploymentTestCase.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Expected results:*
> No failures in test case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (WFLY-5206) Intermittent NPE when invoking method requestDestroyed
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5206?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reopened WFLY-5206:
----------------------------------
Looks like Undertow 1.3.0.Beta10 did not make it into this core release.
> Intermittent NPE when invoking method requestDestroyed
> ------------------------------------------------------
>
> Key: WFLY-5206
> URL: https://issues.jboss.org/browse/WFLY-5206
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Stuart Douglas
> Fix For: 10.0.0.CR1
>
>
> Setup: 4-node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
> This error was seen during clustering failover testing in the following scenario:
> ejb-ejbservlet-repl-sync (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, with synchronously replicated cache)
> After undeploying application on perf19 (second node in the cluster), NullPointerException was logged 31 times in the server log.
> Stacktrace:
> {code}
> 2015/08/18 20:01:40:973 EDT [DEBUG][RMI TCP Connection(14)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Going to undeploy: 'clusterbench-ee7.ear' from 'perf19' now.
> 2015/08/18 20:01:41:265 EDT [DEBUG][RMI TCP Connection(14)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Requesting: {
> "operation" : "undeploy",
> "address" : [{
> "deployment" : "clusterbench-ee7.ear"
> }]
> }
> 20:01:41,706 INFO [org.xnio] (RMI TCP Connection(14)-10.16.90.52) XNIO version 3.3.1.Final
> 20:01:41,918 INFO [org.xnio.nio] (RMI TCP Connection(14)-10.16.90.52) XNIO NIO Implementation Version 3.3.1.Final
> 20:01:41,969 INFO [org.jboss.remoting] (RMI TCP Connection(14)-10.16.90.52) JBoss Remoting version 4.0.9.Final
> [JBossINF] [0m[0m20:01:42,603 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 79) WFLYUT0022: Unregistered web context: /clusterbench
> [JBossINF] [0m[0m20:01:42,603 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0022: Unregistered web context: /clusterbench-passivating
> [JBossINF] [0m[0m20:01:42,679 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 78) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m20:01:42,679 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[31m20:01:42,681 ERROR [io.undertow.servlet.request] (default task-46) UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldInitialListener: java.lang.NullPointerException
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestDestroyed(WeldInitialListener.java:135)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:325)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> We also see the very same error in the scenario where the nodes shutdown instead of undeploying application - right after the server shutdown has been requested (we do not use graceful shutdown yet).
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> May be relevant to https://issues.jboss.org/browse/JBEAP-863 as both errors come together, under the same conditions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (WFLY-4840) Deprecated element cluster-passivation-store from ejb subsystem does not work
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-4840?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on WFLY-4840:
----------------------------------------
Yes, it's so but it was not the point of this issue. My interest was that the {{cluster-passivation-store}} was replaced with {{passivation-store}}. But you can't use {{cluster-passivation-store}} for all settings that {{passivation-store}} offers. I just thought that even if {{cluster-passivation-store}} is deprecated it should give you chance to do process all operations which you can do with new name {{passivation-store}}.
E.g. you can't remove
{code}
[standalone@localhost:9990 /] /subsystem=ejb3/cluster-passivation-store=infinispan:remove()
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0216: Management resource '[
(\"subsystem\" => \"ejb3\"),
(\"cluster-passivation-store\" => \"infinispan\")
]' not found",
"rolled-back" => true
}
[standalone@localhost:9990 /] /subsystem=ejb3/passivation-store=infinispan:remove()
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] :reload()
{
"outcome" => "success",
"result" => undefined
}
[standalone@localhost:9990 /] /subsystem=ejb3:read-resource()
{
"outcome" => "success",
"result" => {
...
"cluster-passivation-store" => undefined,
"passivation-store" => undefined,
...
},
...
}
}
{code}
> Deprecated element cluster-passivation-store from ejb subsystem does not work
> -----------------------------------------------------------------------------
>
> Key: WFLY-4840
> URL: https://issues.jboss.org/browse/WFLY-4840
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, EJB
> Reporter: Ondřej Chaloupka
> Assignee: Paul Ferraro
>
> There is a mismatch in behaviour of deprecated element {{cluster-passivation-store}} under {{ejb}} subsystem.
> When element is deprecated still it should work and only prints warning that it's deprecated.
> {code}
> [standalone@localhost:9990 /] /subsystem=ejb3/cluster-passivation-store=infinispan:read-resource()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"ejb3\"),
> (\"cluster-passivation-store\" => \"infinispan\")
> ]' not found",
> "rolled-back" => true
> }
> {code}
> but
> {code}
> [standalone@localhost:9990 /] /subsystem=ejb3/cluster-passivation-store=infinispan:add()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb.cache.factory.distributable.infinispan is already registered",
> "rolled-back" => true
> }
> {code}
> _A note:_ the element {{cluster-passivation-store}} was replaced by {{passivation-store}} which works fine
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (WFLY-5237) [Migration operation] [Web to Undertow] Unable to migrate rewrite conditions
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5237?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka updated WFLY-5237:
-----------------------------------
Affects Version/s: 10.0.0.Beta2
> [Migration operation] [Web to Undertow] Unable to migrate rewrite conditions
> ----------------------------------------------------------------------------
>
> Key: WFLY-5237
> URL: https://issues.jboss.org/browse/WFLY-5237
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Beta2
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Critical
>
> Reewrite conditions are not migrated as :migrate operation currently marks them as resources, which is not able to migrate see migration warning [].
> In Undertow it is possible to create equivalent configuration by using filters (predicate attributes and handlers, see [http://undertow.io/undertow-docs/undertow-docs-1.2.0/index.html#predicate...]).
> I thus believe that rewrite conditions from Web should be also automatically migrated to Undertow via :migrate management operation.
> [1]
> {noformat}
> "result" => {"migration-warnings" => [
> "WFLYWEB0002: Could not migrate resource {
> \"pattern\" => \"(.*)/toberewritten/(.*)\",
> \"substitution\" => \"$1/rewritten/$2\",
> \"flags\" => \"NC\",
> \"operation\" => \"add\",
> \"address\" => [
> (\"subsystem\" => \"web\"),
> (\"virtual-server\" => \"default\"),
> (\"rewrite\" => \"test\")
> ]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (WFLY-5237) [Migration operation] [Web to Undertow] Unable to migrate rewrite conditions
by Radim Hatlapatka (JIRA)
Radim Hatlapatka created WFLY-5237:
--------------------------------------
Summary: [Migration operation] [Web to Undertow] Unable to migrate rewrite conditions
Key: WFLY-5237
URL: https://issues.jboss.org/browse/WFLY-5237
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Radim Hatlapatka
Assignee: Stuart Douglas
Priority: Critical
Reewrite conditions are not migrated as :migrate operation currently marks them as resources, which is not able to migrate see migration warning [].
In Undertow it is possible to create equivalent configuration by using filters (predicate attributes and handlers, see [http://undertow.io/undertow-docs/undertow-docs-1.2.0/index.html#predicate...]).
I thus believe that rewrite conditions from Web should be also automatically migrated to Undertow via :migrate management operation.
[1]
{noformat}
"result" => {"migration-warnings" => [
"WFLYWEB0002: Could not migrate resource {
\"pattern\" => \"(.*)/toberewritten/(.*)\",
\"substitution\" => \"$1/rewritten/$2\",
\"flags\" => \"NC\",
\"operation\" => \"add\",
\"address\" => [
(\"subsystem\" => \"web\"),
(\"virtual-server\" => \"default\"),
(\"rewrite\" => \"test\")
]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month