[JBoss JIRA] (WFLY-10631) Duplicate layer 'base' in clustering testsuite
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10631?page=com.atlassian.jira.plugin... ]
Jan Kalina updated WFLY-10631:
------------------------------
Description:
When starting infinispan-server, following error occures in {{testsuite/integration/clustering/target/infinispan-server-9.2.5.Final}} log:
{code}
2018-06-24 23:41:55,844 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.patching.manager: org.jboss.msc.service.StartException in service jboss.patching.manager: java.lang.IllegalStateException: Duplicate layer 'base'
at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:106)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException: Duplicate layer 'base'
at org.jboss.as.patching.installation.LayersFactory$ProcessedLayers.addLayer(LayersFactory.java:305)
at org.jboss.as.patching.installation.LayersFactory.processRoot(LayersFactory.java:182)
at org.jboss.as.patching.installation.LayersFactory.process(LayersFactory.java:127)
at org.jboss.as.patching.installation.LayersFactory.load(LayersFactory.java:86)
at org.jboss.as.patching.installation.InstallationManagerImpl.<init>(InstallationManagerImpl.java:47)
at org.jboss.as.patching.installation.InstallationManager.load(InstallationManager.java:185)
at org.jboss.as.patching.installation.InstallationManagerService.load(InstallationManagerService.java:128)
at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:63)
... 5 more
{code}
The reason is following value in {{module.path}}:
{code}
module.path = /home/jkalina/work/wildfly/testsuite/integration/clustering/target/infinispan-server-9.2.5.Final/modules:/home/jkalina/work/wildfly/build/target/wildfly-14.0.0.Beta1-SNAPSHOT/modules:/home/jkalina/work/wildfly/testsuite/integration/clustering/target/modules
{code}
(there are two paths with "base" layer - {{infinispan-server/modules}} and {{wildfly/modules}})
Probably should be set {{modulePath}} in arquillian.xml to prevent using wildfly modules in infinispan. (they are actually ignored currently, just to remove related warning from log)
was:
When starting infinispan-server, following error occures in {{testsuite/integration/clustering/target/infinispan-server-9.2.5.Final}} log:
{code}
2018-06-24 23:41:55,844 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.patching.manager: org.jboss.msc.service.StartException in service jboss.patching.manager: java.lang.IllegalStateException: Duplicate layer 'base'
at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:106)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException: Duplicate layer 'base'
at org.jboss.as.patching.installation.LayersFactory$ProcessedLayers.addLayer(LayersFactory.java:305)
at org.jboss.as.patching.installation.LayersFactory.processRoot(LayersFactory.java:182)
at org.jboss.as.patching.installation.LayersFactory.process(LayersFactory.java:127)
at org.jboss.as.patching.installation.LayersFactory.load(LayersFactory.java:86)
at org.jboss.as.patching.installation.InstallationManagerImpl.<init>(InstallationManagerImpl.java:47)
at org.jboss.as.patching.installation.InstallationManager.load(InstallationManager.java:185)
at org.jboss.as.patching.installation.InstallationManagerService.load(InstallationManagerService.java:128)
at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:63)
... 5 more
{code}
The reason is following value in {{module.path}}:
{code}
module.path = /home/jkalina/work/wildfly/testsuite/integration/clustering/target/infinispan-server-9.2.5.Final/modules:/home/jkalina/work/wildfly/build/target/wildfly-14.0.0.Beta1-SNAPSHOT/modules:/home/jkalina/work/wildfly/testsuite/integration/clustering/target/modules
{code}
Probably should be set {{modulePath}} in arquillian.xml.
> Duplicate layer 'base' in clustering testsuite
> ----------------------------------------------
>
> Key: WFLY-10631
> URL: https://issues.jboss.org/browse/WFLY-10631
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 13.0.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> When starting infinispan-server, following error occures in {{testsuite/integration/clustering/target/infinispan-server-9.2.5.Final}} log:
> {code}
> 2018-06-24 23:41:55,844 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.patching.manager: org.jboss.msc.service.StartException in service jboss.patching.manager: java.lang.IllegalStateException: Duplicate layer 'base'
> at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:106)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: Duplicate layer 'base'
> at org.jboss.as.patching.installation.LayersFactory$ProcessedLayers.addLayer(LayersFactory.java:305)
> at org.jboss.as.patching.installation.LayersFactory.processRoot(LayersFactory.java:182)
> at org.jboss.as.patching.installation.LayersFactory.process(LayersFactory.java:127)
> at org.jboss.as.patching.installation.LayersFactory.load(LayersFactory.java:86)
> at org.jboss.as.patching.installation.InstallationManagerImpl.<init>(InstallationManagerImpl.java:47)
> at org.jboss.as.patching.installation.InstallationManager.load(InstallationManager.java:185)
> at org.jboss.as.patching.installation.InstallationManagerService.load(InstallationManagerService.java:128)
> at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:63)
> ... 5 more
> {code}
> The reason is following value in {{module.path}}:
> {code}
> module.path = /home/jkalina/work/wildfly/testsuite/integration/clustering/target/infinispan-server-9.2.5.Final/modules:/home/jkalina/work/wildfly/build/target/wildfly-14.0.0.Beta1-SNAPSHOT/modules:/home/jkalina/work/wildfly/testsuite/integration/clustering/target/modules
> {code}
> (there are two paths with "base" layer - {{infinispan-server/modules}} and {{wildfly/modules}})
> Probably should be set {{modulePath}} in arquillian.xml to prevent using wildfly modules in infinispan. (they are actually ignored currently, just to remove related warning from log)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10631) Duplicate layer 'base' in clustering testsuite
by Jan Kalina (JIRA)
Jan Kalina created WFLY-10631:
---------------------------------
Summary: Duplicate layer 'base' in clustering testsuite
Key: WFLY-10631
URL: https://issues.jboss.org/browse/WFLY-10631
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 13.0.0.Final
Reporter: Jan Kalina
Assignee: Jan Kalina
Priority: Minor
When starting infinispan-server, following error occures in {{testsuite/integration/clustering/target/infinispan-server-9.2.5.Final}} log:
{code}
2018-06-24 23:41:55,844 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.patching.manager: org.jboss.msc.service.StartException in service jboss.patching.manager: java.lang.IllegalStateException: Duplicate layer 'base'
at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:106)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException: Duplicate layer 'base'
at org.jboss.as.patching.installation.LayersFactory$ProcessedLayers.addLayer(LayersFactory.java:305)
at org.jboss.as.patching.installation.LayersFactory.processRoot(LayersFactory.java:182)
at org.jboss.as.patching.installation.LayersFactory.process(LayersFactory.java:127)
at org.jboss.as.patching.installation.LayersFactory.load(LayersFactory.java:86)
at org.jboss.as.patching.installation.InstallationManagerImpl.<init>(InstallationManagerImpl.java:47)
at org.jboss.as.patching.installation.InstallationManager.load(InstallationManager.java:185)
at org.jboss.as.patching.installation.InstallationManagerService.load(InstallationManagerService.java:128)
at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:63)
... 5 more
{code}
The reason is following value in {{module.path}}:
{code}
module.path = /home/jkalina/work/wildfly/testsuite/integration/clustering/target/infinispan-server-9.2.5.Final/modules:/home/jkalina/work/wildfly/build/target/wildfly-14.0.0.Beta1-SNAPSHOT/modules:/home/jkalina/work/wildfly/testsuite/integration/clustering/target/modules
{code}
Probably should be set {{modulePath}} in arquillian.xml.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10615) Duplicate layer 'base' in integration/elytron testsuite
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10615?page=com.atlassian.jira.plugin... ]
Jan Kalina commented on WFLY-10615:
-----------------------------------
The same error hidden also in {{testsuite/integration/clustering}}
> Duplicate layer 'base' in integration/elytron testsuite
> -------------------------------------------------------
>
> Key: WFLY-10615
> URL: https://issues.jboss.org/browse/WFLY-10615
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 13.0.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> Testsuite wildfly/testsuite/integration/elytron has workarounded module path problem:
> {code}
> MSC000001: Failed to start service jboss.patching.manager: org.jboss.msc.service.StartException in service jboss.patching.manager: java.lang.IllegalStateException: Duplicate layer 'base'
> at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:106)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: Duplicate layer 'base'
> at org.jboss.as.patching.installation.LayersFactory$ProcessedLayers.addLayer(LayersFactory.java:305)
> at org.jboss.as.patching.installation.LayersFactory.processRoot(LayersFactory.java:182)
> at org.jboss.as.patching.installation.LayersFactory.process(LayersFactory.java:127)
> at org.jboss.as.patching.installation.LayersFactory.load(LayersFactory.java:86)
> at org.jboss.as.patching.installation.InstallationManagerImpl.<init>(InstallationManagerImpl.java:47)
> at org.jboss.as.patching.installation.InstallationManager.load(InstallationManager.java:185)
> at org.jboss.as.patching.installation.InstallationManagerService.load(InstallationManagerService.java:128)
> at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:63)
> ... 8 more
> {code}
> This is currently workarounded using following in pom.xml:
> {code}
> <!-- let's override the module.path parent configuration with dummy value, to avoid the "IllegalStateException: Duplicate layer 'base'" -->
> <module.path>foo</module.path>
> {code}
> But this prevent using `org.jboss.as.test.module.util.TestModule`, as it try to put created module into "foo", which fails - adding tests using custom modules requires removing this workaround.
> The reason is {{target/wildfly/modules}} is twice in {{module.path}} system property (when in InstallationManagerService):
> {code}
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/wildfly/modules:
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/wildfly/modules:
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/modules
> {code}
> Note: when reading {{module.path}} from the test (regardless RunAsClient is used or not), the value is correct:
> {code}
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/wildfly/modules:
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/modules
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10344) Deployment order based on jboss-all.xml doesn't work properly
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10344?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski commented on WFLY-10344:
-------------------------------------------
[~panos.mitronikas] Could you please attach reproducer?
> Deployment order based on jboss-all.xml doesn't work properly
> -------------------------------------------------------------
>
> Key: WFLY-10344
> URL: https://issues.jboss.org/browse/WFLY-10344
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 12.0.0.Final
> Reporter: Panos Mitronikas
> Assignee: Jason Greene
>
> Our application consists of a core module (ear or war) and several component modules (wars) that register to the core upon deployment.
> The process is implemented with a REST service available in the core module and REST clients in each component that call a register method upon deployment and an unregister upon removal. This requires a deployment order for server restarts and it is implemented with jboss-all.xml files in each component war.
> The process was smooth on Wildfly 10 but on 12 restarts seem not to follow the deployment order, or for being exact it appears that the core REST service doesn't get initialized properly and clients just hang there waiting, resulting in a total crash of the server upon initialization (never goes up and crashes with some concurrency error after 5 minutes).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2279) Error during ASYM_ENCRYPT-----exception occurred decrypting messagejavax.crypto.BadPaddingException: Given final block not properly padded
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2279?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2279:
---------------------------
Fix Version/s: 4.0.13
> Error during ASYM_ENCRYPT-----exception occurred decrypting messagejavax.crypto.BadPaddingException: Given final block not properly padded
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2279
> URL: https://issues.jboss.org/browse/JGRP-2279
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Environment: OS:Red Hat
> JDK:1.8
> Reporter: George Jiang
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.0.13
>
>
> *asym parameters:*
> <ASYM_ENCRYPT encrypt_entire_message="true"
> sign_msgs="true"
> sym_keylength="128"
> sym_algorithm="AES/ECB/PKCS5Padding"
> asym_keylength="2048"
> asym_algorithm="RSA"
> change_key_on_leave="true"/>
> *Throws the following error:*
> 2018-05-23T03:11:53,891 +2903450778 [jgroups--12467,-1491537117,1] ERROR org.jgroups.protocols.ASYM_ENCRYPT - 1: failed decrypting message from 2 (offset=0, length=1136, buf.length=1136): javax.crypto.BadPaddingException: Given final block not properly padded, headers are ASYM_ENCRYPT: [ENCRYPT version=16 bytes], TP: [cluster_name=-1491537117]
> 2018-05-23T03:11:53,893 +2903450780 [jgroups--12467,-1491537117,1] TRACE org.jgroups.protocols.TCP_NIO2 - 1: received message batch of 1 messages from 2
> 2018-05-23T03:11:53,895 +2903450782 [jgroups--12467,-1491537117,1] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 1: received secret key from keyserver 2
> 2018-05-23T03:11:53,895 +2903450782 [jgroups--12467,-1491537117,1] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 1: created 8 symmetric ciphers with secret key (16 bytes)
> 2018-05-23T03:11:54,369 +2903451256 [jgroups--12467,-1491537117,1] TRACE org.jgroups.protocols.TCP_NIO2 - 1: received [dst:***
> 2018-05-23T03:11:54,369 +2903451256 [jgroups--12467,-1491537117,1] WARN org.jgroups.protocols.ASYM_ENCRYPT - 1: exception occurred decrypting message
> javax.crypto.BadPaddingException: Given final block not properly padded
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:991) ~[sunjce_provider.jar:1.8.0_162]
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:847) ~[sunjce_provider.jar:1.8.0_162]
> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) ~[sunjce_provider.jar:1.8.0_162]
> at javax.crypto.Cipher.doFinal(Cipher.java:2222) ~[?:1.8.0_171]
> at org.jgroups.protocols.Encrypt.code(Encrypt.java:365) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.decryptChecksum(Encrypt.java:387) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt._decrypt(Encrypt.java:299) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.decryptMessage(Encrypt.java:283) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.handleEncryptedMessage(Encrypt.java:242) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.handleUpMessage(Encrypt.java:229) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.up(Encrypt.java:155) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.ASYM_ENCRYPT.up(ASYM_ENCRYPT.java:143) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:129) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:197) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:277) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Discovery.up(Discovery.java:262) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1203) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_162]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_162]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski reassigned WFLY-10280:
-----------------------------------------
Assignee: Paul Ferraro (was: Bartosz Baranowski)
> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
> Key: WFLY-10280
> URL: https://issues.jboss.org/browse/WFLY-10280
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
> Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
> service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
> service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski commented on WFLY-10280:
-------------------------------------------
{quote}
Thread [ServerService Thread Pool -- 43] (Suspended (breakpoint at line 101 in ServiceName))
ServiceName.<init>(ServiceName, String) line: 101
ServiceName.of(ServiceName, String...) line: 92
ServiceName.of(String...) line: 70
ServiceName.parse(String) line: 482
ServiceNameFactory.parseServiceName(String) line: 46
OperationContextImpl.*getCapabilityServiceName*(String, Class<?>, PathAddress) line: 1672
ParallelBootOperationContext.*getCapabilityServiceName*(String, Class<?>) line: 394
*BinaryRequirementServiceNameFactory.getServiceName(OperationContext, String, String) line: 45*
ClusteringCacheRequirement(DefaultableBinaryServiceNameFactoryProvider).getServiceName(OperationContext, String, String) line: 44
EJBRemotingConnectorClientMappingsEntryProviderService.configure(OperationContext) line: 76
EJB3RemoteServiceAdd.installRuntimeServices(OperationContext, ModelNode) line: 88
EJB3RemoteServiceAdd.performBoottime(OperationContext, ModelNode, ModelNode) line: 76
EJB3RemoteServiceAdd(AbstractBoottimeAddStepHandler).performBoottime(OperationContext, ModelNode, Resource) line: 144
EJB3RemoteServiceAdd(AbstractBoottimeAddStepHandler).performRuntime(OperationContext, ModelNode, Resource) line: 119
AbstractAddStepHandler$1.execute(OperationContext, ModelNode) line: 159
ParallelBootOperationContext(AbstractOperationContext).executeStep(AbstractOperationContext$Step) line: 999
ParallelBootOperationContext(AbstractOperationContext).processStages() line: 743
ParallelBootOperationContext(AbstractOperationContext).executeOperation() line: 467
ParallelBootOperationStepHandler$ParallelBootTask.run() line: 384
ContextClassLoaderSavingRunnable.run() line: 35
EnhancedQueueExecutor.safeRun(Runnable) line: 1985
EnhancedQueueExecutor$ThreadBody.doRunTask(Runnable) line: 1487
EnhancedQueueExecutor$ThreadBody.run() line: 1349
JBossThread(Thread).run() line: 748
JBossThread.run() line: 485
{quote}
Which installs capability/service(?) "service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings" later on, unless method name and vars are misleading?
> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
> Key: WFLY-10280
> URL: https://issues.jboss.org/browse/WFLY-10280
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Bartosz Baranowski
> Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
> service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
> service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10630) HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
by Bernhard Kabelka (JIRA)
Bernhard Kabelka created WFLY-10630:
---------------------------------------
Summary: HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
Key: WFLY-10630
URL: https://issues.jboss.org/browse/WFLY-10630
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 13.0.0.Final, 10.0.0.Final
Environment: Windows 10, Java 1.8.0_131
Reproducible with both WildFly-10.0.0.Final and Wildfly-13.0.0.Final
Reporter: Bernhard Kabelka
Assignee: Stuart Douglas
For sessions shared across different WARs in a single EAR, the notification of HttpSessionListener works differently in WildFly 10.0.0.Final (and Wildfly 13.0.0.Final) than it it used to work in WildFly 8.2.0.Final:
I have an EAR containing two WARs with enabled session sharing across the WARs. Basically, one WAR contains the web UI, and the other WAR contains the REST interfaces for AJAX calls made by the UI. The user authenticates against the UI-WAR. On logout, a REST method in the AJAX-WAR is triggered which calls HttpSession.invalidate() on the user session.
In WildFly 8.2.0.Final, a HttpSessionListener in the UI-WAR gets notified immediately about session creation and destruction.
In WildFly 13.0.0.Final, however, a HttpSessionListener in either WAR only gets one of the two notifications:
* In the UI-WAR, I get a notification about the created session immediately when the login form is loaded. However, I do not receive any notification about the session destruction (unless it times out).
* In the AJAX-WAR, I do not get any notification about the session creation at all, but I immediately receive a notification about the session destruction.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years