[Red Hat JIRA] (WFLY-11365) Test JSONBTestCase fails with security manager
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-11365?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFLY-11365.
-------------------------------------
Resolution: Out of Date
If anyone knows a Fix Version please feel free to re-resolve as 'Done' for that fix version.
> Test JSONBTestCase fails with security manager
> ----------------------------------------------
>
> Key: WFLY-11365
> URL: https://issues.redhat.com/browse/WFLY-11365
> Project: WildFly
> Issue Type: Bug
> Components: EE, Test Suite
> Affects Versions: 15.0.0.Beta1
> Reporter: Martin Choma
> Assignee: Bartosz Baranowski
> Priority: Major
> Labels: security-manager
> Attachments: sm-fix.patch
>
>
> {noformat}
> org.jboss.as.test.integration.json (1)
> JSONBTestCase.testJsonbServlet
> {noformat}
> {noformat}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/repository/org/eclipse/yasson/1.0.2/yasson-1.0.2.jar" "read")" in code source "(vfs:/content/jsonb10-test.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.jsonb10-test.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:359)
> at java.util.zip.ZipFile.<init>(ZipFile.java:216)
> at java.util.zip.ZipFile.<init>(ZipFile.java:155)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:99)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152)
> at java.net.URL.openStream(URL.java:1045)
> at java.util.ServiceLoader.parse(ServiceLoader.java:304)
> at java.util.ServiceLoader.access$200(ServiceLoader.java:185)
> at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357)
> at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)
> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:112)
> at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108)
> at org.jboss.as.test.integration.json.JSONBServlet.doGet(JSONBServlet.java:46) ...
> {noformat}
> Looks to me similar to WFLY-11337
> [1] https://ci.wildfly.org/viewLog.html?buildId=128138&buildTypeId=WF_MasterS...
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (WFLY-14243) New JAXB tests in WFLY-13968 fails on ee9 profile
by Richard Opalka (Jira)
[ https://issues.redhat.com/browse/WFLY-14243?page=com.atlassian.jira.plugi... ]
Richard Opalka commented on WFLY-14243:
---------------------------------------
Thanks [~brian.stansberry]
> New JAXB tests in WFLY-13968 fails on ee9 profile
> -------------------------------------------------
>
> Key: WFLY-14243
> URL: https://issues.redhat.com/browse/WFLY-14243
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Minor
> Fix For: 22.0.0.Final
>
>
> The new JAXB tests introduced in WFLY-13968 fails when using the ee9 profile:
> * org.jboss.as.test.integration.jaxb.unit.JAXBContextSystemPropCustomTestCase
> * org.jboss.as.test.integration.jaxb.unit.JAXBContextUsingPropertiesTestCase
> The reason is that in ee9 the system property and the keys inside the {{jaxb.properties}} file needs to be prefixed by {{jakarta}} instead of {{javax}}.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (WFLY-14260) ClassCastException during expiration scheduling
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-14260?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-14260:
--------------------------------
Description:
This appears to be a regression due to:
https://github.com/wildfly/wildfly/commit/ff22a98553a4168a9cd47a8fbf59afa...
As seen on CI:
{noformat}
[0m09:30:39,897 INFO [org.wildfly.clustering.ee.infinispan] (default task-2) WFLYCLEEINF0002: Failed to schedule 3wnQESQq-yAwHD6_ygq39emcPLeSonW6P-oDO-0N on primary owner.: java.lang.ClassCastException: org.infinispan.remoting.transport.jgroups.JGroupsAddress cannot be cast to org.jgroups.Address
at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.createNode(ChannelCommandDispatcherFactory.java:98)
at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:57)
at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:39)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:81)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:78)
at org.wildfly.clustering.ee.cache.retry.RetryingInvoker.invoke(RetryingInvoker.java:72)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.executeOnPrimaryOwner(PrimaryOwnerScheduler.java:86)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.schedule(PrimaryOwnerScheduler.java:59)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:123)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:119)
at org.wildfly.clustering.web.cache.session.ValidSession.close(ValidSession.java:89)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.closeSession(ConcurrentSessionManager.java:151)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:55)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:52)
at org.wildfly.clustering.ee.cache.SimpleManager$1.run(SimpleManager.java:55)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.close(ConcurrentSessionManager.java:182)
at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:98)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:960)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:590)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:105)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:102)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.lang.Thread.run(Thread.java:748)
{noformat}
To fix, we should rollback the changes to InfinispanSessionManagerFactoryServiceConfigurator, and leverage the new web-passivation layer where needed.
was:
This appears to be a regression due to:
https://github.com/wildfly/wildfly/commit/ff22a98553a4168a9cd47a8fbf59afa...
As seen on CI:
{noformat}
[0m09:30:39,897 INFO [org.wildfly.clustering.ee.infinispan] (default task-2) WFLYCLEEINF0002: Failed to schedule 3wnQESQq-yAwHD6_ygq39emcPLeSonW6P-oDO-0N on primary owner.: java.lang.ClassCastException: org.infinispan.remoting.transport.jgroups.JGroupsAddress cannot be cast to org.jgroups.Address
at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.createNode(ChannelCommandDispatcherFactory.java:98)
at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:57)
at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:39)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:81)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:78)
at org.wildfly.clustering.ee.cache.retry.RetryingInvoker.invoke(RetryingInvoker.java:72)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.executeOnPrimaryOwner(PrimaryOwnerScheduler.java:86)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.schedule(PrimaryOwnerScheduler.java:59)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:123)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:119)
at org.wildfly.clustering.web.cache.session.ValidSession.close(ValidSession.java:89)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.closeSession(ConcurrentSessionManager.java:151)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:55)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:52)
at org.wildfly.clustering.ee.cache.SimpleManager$1.run(SimpleManager.java:55)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.close(ConcurrentSessionManager.java:182)
at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:98)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:960)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:590)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:105)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:102)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.lang.Thread.run(Thread.java:748)
{noformat}
> ClassCastException during expiration scheduling
> -----------------------------------------------
>
> Key: WFLY-14260
> URL: https://issues.redhat.com/browse/WFLY-14260
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 22.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
>
> This appears to be a regression due to:
> https://github.com/wildfly/wildfly/commit/ff22a98553a4168a9cd47a8fbf59afa...
> As seen on CI:
> {noformat}
> [0m09:30:39,897 INFO [org.wildfly.clustering.ee.infinispan] (default task-2) WFLYCLEEINF0002: Failed to schedule 3wnQESQq-yAwHD6_ygq39emcPLeSonW6P-oDO-0N on primary owner.: java.lang.ClassCastException: org.infinispan.remoting.transport.jgroups.JGroupsAddress cannot be cast to org.jgroups.Address
> at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.createNode(ChannelCommandDispatcherFactory.java:98)
> at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:57)
> at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:39)
> at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:81)
> at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:78)
> at org.wildfly.clustering.ee.cache.retry.RetryingInvoker.invoke(RetryingInvoker.java:72)
> at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.executeOnPrimaryOwner(PrimaryOwnerScheduler.java:86)
> at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.schedule(PrimaryOwnerScheduler.java:59)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:123)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:119)
> at org.wildfly.clustering.web.cache.session.ValidSession.close(ValidSession.java:89)
> at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.closeSession(ConcurrentSessionManager.java:151)
> at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:55)
> at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:52)
> at org.wildfly.clustering.ee.cache.SimpleManager$1.run(SimpleManager.java:55)
> at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.close(ConcurrentSessionManager.java:182)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:98)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:960)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:590)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:105)
> at java.security.AccessController.doPrivileged(Native Method)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:102)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> To fix, we should rollback the changes to InfinispanSessionManagerFactoryServiceConfigurator, and leverage the new web-passivation layer where needed.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (WFLY-14258) The first websocket that gets triggered from any deployed war file on server prevents all websockets in all other deployed war files from working
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-14258?page=com.atlassian.jira.plugi... ]
Farah Juma commented on WFLY-14258:
-----------------------------------
[~scsynergy] Have you checked if you still see this issue with the latest WildFly release (21.0.2.Final)?
> The first websocket that gets triggered from any deployed war file on server prevents all websockets in all other deployed war files from working
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14258
> URL: https://issues.redhat.com/browse/WFLY-14258
> Project: WildFly
> Issue Type: Bug
> Components: JSF, Web Sockets
> Reporter: Ronald Feicht
> Assignee: Farah Juma
> Priority: Major
> Attachments: ws1.tar.gz, ws2.tar.gz
>
>
> *Two* war files are deployed on the same Wildfly instance and both use websockets. The *first* page with f:websocket that gets loaded by the browser works perfectly well. Any websocket on any other page of the *same* war file also works perfectly well. Yet, any websocket of the *second* war file will not work until the server is restartet. Then the first page with a websocket that gets loaded determines which war file's websockets will work.
> Example:
> # WS1/index.xhtml --> websocket works
> # WS2/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
> # restart Wildfly
> # WS2/index.xhtml --> websocket works
> # WS1/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
> # if we had a WS3/index.xhtml its websockets would also not work
> issue found on: Mojarra 2.3.9.SP11 on WildFly Full 20.0.1.Final (WildFly Core 12.0.3.Final)
> Example war files attached for you to easily confirm this issue:
> ws1.tar.gz
> ws2.tar.gz
>
> Created the same bug report here because I cannot tell whether the bug is in Mojarra or the Wildfly integration of Mojarra: [https://github.com/eclipse-ee4j/mojarra/issues/4799]
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (WFLY-14189) The RunAs annotation doesn't work in EJBs with Elytron
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-14189?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-14189:
------------------------------------
Component/s: EJB
> The RunAs annotation doesn't work in EJBs with Elytron
> ------------------------------------------------------
>
> Key: WFLY-14189
> URL: https://issues.redhat.com/browse/WFLY-14189
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Affects Versions: 21.0.0.Final
> Reporter: Alessandro Moscatelli
> Priority: Major
> Labels: ejb, elytron, regression, runas, security, startup
> Attachments: standalone-full-ha.new.xml, test.zip
>
>
> Role is not correctly assigned when using @RunAs annotation and Elytron Security Domain. Everything works correctly with legacy picketbox Security Domain.
> Wildfly is configured to use default "other" application-security-domain, also using default security domain ApplicationDomain.
> This exception is rised when deploying the application.
> Caused by: javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract void org.visiontech.test.TestInterface.test() of bean: Test2 is not allowedCaused by: javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract void org.visiontech.test.TestInterface.test() of bean: Test2 is not allowed at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.security.JaccInterceptor.hasPermission(JaccInterceptor.java:120)
> Test/Sample project: [^test.zip]
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (WFLY-14260) ClassCastException during expiration scheduling
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-14260:
-----------------------------------
Summary: ClassCastException during expiration scheduling
Key: WFLY-14260
URL: https://issues.redhat.com/browse/WFLY-14260
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 22.0.0.Beta1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
This appears to be a regression due to:
https://github.com/wildfly/wildfly/commit/ff22a98553a4168a9cd47a8fbf59afa...
As seen on CI:
{noformat}
[0m09:30:39,897 INFO [org.wildfly.clustering.ee.infinispan] (default task-2) WFLYCLEEINF0002: Failed to schedule 3wnQESQq-yAwHD6_ygq39emcPLeSonW6P-oDO-0N on primary owner.: java.lang.ClassCastException: org.infinispan.remoting.transport.jgroups.JGroupsAddress cannot be cast to org.jgroups.Address
at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.createNode(ChannelCommandDispatcherFactory.java:98)
at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:57)
at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:39)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:81)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:78)
at org.wildfly.clustering.ee.cache.retry.RetryingInvoker.invoke(RetryingInvoker.java:72)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.executeOnPrimaryOwner(PrimaryOwnerScheduler.java:86)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.schedule(PrimaryOwnerScheduler.java:59)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:123)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:119)
at org.wildfly.clustering.web.cache.session.ValidSession.close(ValidSession.java:89)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.closeSession(ConcurrentSessionManager.java:151)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:55)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:52)
at org.wildfly.clustering.ee.cache.SimpleManager$1.run(SimpleManager.java:55)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.close(ConcurrentSessionManager.java:182)
at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:98)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:960)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:590)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:105)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:102)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (ELY-2065) No suitable provider found for type 'PKCS11' on openjdk 11 when configuration is passed in provider-loader
by Diana Vilkolakova (Jira)
[ https://issues.redhat.com/browse/ELY-2065?page=com.atlassian.jira.plugin.... ]
Diana Vilkolakova updated ELY-2065:
-----------------------------------
Description:
Steps to Reproduce work using OpenJDK 8, but on OpenJDK 11 the following exception gets thrown:
{code}
{{ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([}}
{{ ("subsystem" => "elytron"),}}
{{ ("key-store" => "pkcs11ks")}}
{{]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.pkcs11ks" => "WFLYELY00004: Unable to start the service.}}
{{ Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00012: No suitable provider found for type 'PKCS11'"}}}}
{code}
Configuration loading for SunPKCS11 was changed after Java 8 and the constructor that accepts InputStream configuration is not present in openjdk 11. Maybe because of this, the configuration is ignored when it is passed in *provider-loader*.
was:
Steps to Reproduce work using OpenJDK 8, but on OpenJDK 11 the following exception gets thrown:
{{ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([}}
{{ ("subsystem" => "elytron"),}}
{{ ("key-store" => "pkcs11ks")}}
{{]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.pkcs11ks" => "WFLYELY00004: Unable to start the service.}}
{{ Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00012: No suitable provider found for type 'PKCS11'"}}}}
Configuration loading for SunPKCS11 was changed after Java 8 and the constructor that accepts InputStream configuration is not present in openjdk 11. Maybe because of this, the configuration is ignored when it is passed in *provider-loader*.
> No suitable provider found for type 'PKCS11' on openjdk 11 when configuration is passed in provider-loader
> ----------------------------------------------------------------------------------------------------------
>
> Key: ELY-2065
> URL: https://issues.redhat.com/browse/ELY-2065
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI
> Reporter: Diana Vilkolakova
> Assignee: Diana Vilkolakova
> Priority: Major
>
> Steps to Reproduce work using OpenJDK 8, but on OpenJDK 11 the following exception gets thrown:
> {code}
> {{ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([}}
> {{ ("subsystem" => "elytron"),}}
> {{ ("key-store" => "pkcs11ks")}}
> {{]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.pkcs11ks" => "WFLYELY00004: Unable to start the service.}}
> {{ Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00012: No suitable provider found for type 'PKCS11'"}}}}
> {code}
> Configuration loading for SunPKCS11 was changed after Java 8 and the constructor that accepts InputStream configuration is not present in openjdk 11. Maybe because of this, the configuration is ignored when it is passed in *provider-loader*.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (ELY-2065) No suitable provider found for type 'PKCS11' on openjdk 11 when configuration is passed in provider-loader
by Diana Vilkolakova (Jira)
[ https://issues.redhat.com/browse/ELY-2065?page=com.atlassian.jira.plugin.... ]
Diana Vilkolakova updated ELY-2065:
-----------------------------------
Steps to Reproduce:
The below steps will pass using OpenJDK 8, but will throw an exception using OpenJDK 11.
1. Configure NSS:
{code}
mkdir /tmp/nssdb
echo "pass123+" > /tmp/newpass.txt
echo "dsadasdasdasdadasdasdasdasdsadfwerwerjfdksdjfksdlfhjsdk" > /tmp/noise.txt
MODUTIL_CMD="modutil -force -dbdir /tmp/nssdb"$MODUTIL_CMD -create
$MODUTIL_CMD -changepw "NSS Certificate DB" -newpwfile /tmp/newpass.txt
certutil -S -v 240 -k rsa -n "CN=localhost" -t "u,u,u" -x -s "CN=localhost" -d /tmp/nssdb -f /tmp/newpass.txt -z /tmp/noise.txt
touch /tmp/nssdb/secmod.db
$JBOSS_HOME/bin/standalone.sh
$JBOSS_HOME/bin/jboss-cli -c
{code}
2. Configure keystore:
{code}
/subsystem=elytron/provider-loader=nss:add(class-names=["sun.security.pkcs11.SunPKCS11"], configuration=\{name=testPkcs11, nssLibraryDirectory=/usr/lib64, nssSecmodDirectory=/tmp/nssdb, nssModule=keystore, name=testPkcs11},module=sun.jdk)
/subsystem=elytron/key-store=pkcs11ks:add(credential-reference=\{clear-text=pass123+}, type=PKCS11, providers=nss)
{code}
was:
The below steps will pass using OpenJDK 8, but will throw an exception using OpenJDK 11.
1. Configure NSS:
mkdir /tmp/nssdb
echo "pass123+" > /tmp/newpass.txt
echo "dsadasdasdasdadasdasdasdasdsadfwerwerjfdksdjfksdlfhjsdk" > /tmp/noise.txt
MODUTIL_CMD="modutil -force -dbdir /tmp/nssdb"$MODUTIL_CMD -create
$MODUTIL_CMD -changepw "NSS Certificate DB" -newpwfile /tmp/newpass.txt
certutil -S -v 240 -k rsa -n "CN=localhost" -t "u,u,u" -x -s "CN=localhost" -d /tmp/nssdb -f /tmp/newpass.txt -z /tmp/noise.txt
touch /tmp/nssdb/secmod.db
$JBOSS_HOME/bin/standalone.sh
$JBOSS_HOME/bin/jboss-cli -c
2. Configure keystore:
/subsystem=elytron/provider-loader=nss:add(class-names=["sun.security.pkcs11.SunPKCS11"], configuration=\{name=testPkcs11, nssLibraryDirectory=/usr/lib64, nssSecmodDirectory=/tmp/nssdb, nssModule=keystore, name=testPkcs11},module=sun.jdk)/subsystem=elytron/key-store=pkcs11ks:add(credential-reference=\{clear-text=pass123+}, type=PKCS11, providers=nss)
> No suitable provider found for type 'PKCS11' on openjdk 11 when configuration is passed in provider-loader
> ----------------------------------------------------------------------------------------------------------
>
> Key: ELY-2065
> URL: https://issues.redhat.com/browse/ELY-2065
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI
> Reporter: Diana Vilkolakova
> Assignee: Diana Vilkolakova
> Priority: Major
>
>
> Steps to Reproduce work using OpenJDK 8, but on OpenJDK 11 the following exception gets thrown:
> {{ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([}}
> {{ ("subsystem" => "elytron"),}}
> {{ ("key-store" => "pkcs11ks")}}
> {{]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.pkcs11ks" => "WFLYELY00004: Unable to start the service.}}
> {{ Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00012: No suitable provider found for type 'PKCS11'"}}}}
> Configuration loading for SunPKCS11 was changed after Java 8 and the constructor that accepts InputStream configuration is not present in openjdk 11. Maybe because of this, the configuration is ignored when it is passed in *provider-loader*.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months