[JBoss JIRA] (WFLY-11346) MicroProfile tests failing with security manager
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-11346?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFLY-11346:
--------------------------------
Labels: security-manager (was: )
> MicroProfile tests failing with security manager
> ------------------------------------------------
>
> Key: WFLY-11346
> URL: https://issues.jboss.org/browse/WFLY-11346
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 14.0.0.Final
> Reporter: Martin Choma
> Priority: Major
> Labels: security-manager
>
> {noformat}
> org.wildfly.test.integration.microprofile.config.smallrye.app (9)
> MicroProfileConfigTestCase.testGetBooleanProperties
> MicroProfileConfigTestCase.testGetDoubleProperties
> MicroProfileConfigTestCase.testGetFloatProperties
> MicroProfileConfigTestCase.testGetIntegerProperties
> MicroProfileConfigTestCase.testGetLongProperties
> MicroProfileConfigTestCase.testGetWithArraySetListDefaultProperties
> MicroProfileConfigTestCase.testGetWithArraySetListOverriddenProperties
> MicroProfileConfigTestCase.testGetWithConfigProperties
> MicroProfileConfigTestCase.testPriorityOrderingProperties
> org.wildfly.test.integration.microprofile.config.smallrye.converter (1)
> MicroProfileConfigConvertersTestCase.testConverterPriority
> org.wildfly.test.integration.microprofile.config.smallrye.management.config_source (1)
> ConfigSourceFromClassTestCase.testGetWithConfigProperties
> org.wildfly.test.integration.microprofile.config.smallrye.management.config_source_provider (1)
> ConfigSourceProviderFromClassTestCase.testGetWithConfigProperties
> {noformat}
> With MicroProfileConfigTestCase there is error
> {noformat}
> 12:01:38,872 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /MicroProfileConfigTestCase/microprofile/arraySetListDefaultTest: org.jboss.resteasy.spi.UnhandledException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getenv.myPets")" in code source "(vfs:/content/MicroProfileConfigTestCase.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:78)
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:222)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:197)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:459)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> {noformat}
> So probably solution is to add such permissions to rs application TestApplication.
> For other tests (MicroProfileConfigConvertersTestCase, ConfigSourceFromClassTestCase, ConfigSourceProviderFromClassTestCase) this exception is not printed, but I think cause will be the same as the structure of these tests is the same
> [1] https://ci.wildfly.org/viewLog.html?buildId=128138&buildTypeId=WF_MasterS...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11347) Tests from org.jboss.as.test.integration.messaging fails with security manager
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-11347?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFLY-11347:
--------------------------------
Labels: security-manager (was: )
> Tests from org.jboss.as.test.integration.messaging fails with security manager
> ------------------------------------------------------------------------------
>
> Key: WFLY-11347
> URL: https://issues.jboss.org/browse/WFLY-11347
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 14.0.0.Final
> Reporter: Martin Choma
> Priority: Major
> Labels: security-manager
>
> {noformat}
> org.jboss.as.test.integration.messaging.jms.external (8)
> DiscoveryGroupExternalMessagingDeploymentTestCase.testSendMessageInClientQueue
> DiscoveryGroupExternalMessagingDeploymentTestCase.testSendMessageInClientTopic
> ExternalMessagingDeploymentRemoteTestCase.testSendMessageInClientQueue
> ExternalMessagingDeploymentRemoteTestCase.testSendMessageInClientTopic
> ExternalMessagingDeploymentTestCase.testSendMessageInClientQueue
> ExternalMessagingDeploymentTestCase.testSendMessageInClientTopic
> SendToExternalJMSQueueTestCase.sendMessage
> SendToExternalJMSTopicTestCase.sendMessage
> org.jboss.as.test.integration.messaging.jms.context.notClosingInjectedContext (1)
> NotClosingInjectedContextTestCase.testLeakingConnection
> org.jboss.as.test.integration.messaging.jms.definitions (3)
> JMSResourceDefinitionsTestCase.testAnnotationBasedDefinitionsWithVaultedAttributes
> JMSResourceDefinitionsTestCase.testDeploymendDescriptorBasedDefinitionsWithVaultedAttributes
> JMSResourceDefinitionsTestCase.testInjectedDefinitions
> org.jboss.as.test.integration.messaging.mgmt (1)
> ExternalPooledConnectionFactoryStatisticsTestCase.testStatistics
> {noformat}
> Check if it is enough to add permission to deployment or doPrivileged block is necessary somewhere. There are erros like this
> {noformat}
> &#27;[33m00:17:58,191 WARN [org.apache.activemq.artemis.core.client] (default task-1) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost" "resolve")" in code source "(vfs:/content/ClientMessagingDeploymentTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ClientMessagingDeploymentTestCase.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.checkConnect(SecurityManager.java:1048)
> at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:389)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1268)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at java.net.InetAddress.getByName(InetAddress.java:1076)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:220)
> at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:711)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost:45700" "listen,resolve")" in code source "(vfs:/content/ClientMessagingDeploymentTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ClientMessagingDeploymentTestCase.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.checkListen(SecurityManager.java:1131)
> at org.wildfly.security.manager.WildFlySecurityManager.checkListen(WildFlySecurityManager.java:401)
> at java.net.DatagramSocket.bind(DatagramSocket.java:389)
> at java.net.MulticastSocket.<init>(MulticastSocket.java:172)
> at org.apache.activemq.artemis.api.core.UDPBroadcastEndpointFactory$UDPBroadcastEndpoint.openClient(UDPBroadcastEndpointFactory.java:203)
> at org.apache.activemq.artemis.core.cluster.DiscoveryGroup.start(DiscoveryGroup.java:105)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.initialize(ServerLocatorImpl.java:309)
> {noformat}
> [1] https://ci.wildfly.org/viewLog.html?buildId=128138&buildTypeId=WF_MasterS...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11348) EESecurityAuthMechanismTestCase fails with security manager
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-11348?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFLY-11348:
--------------------------------
Labels: security-manager (was: )
> EESecurityAuthMechanismTestCase fails with security manager
> -----------------------------------------------------------
>
> Key: WFLY-11348
> URL: https://issues.jboss.org/browse/WFLY-11348
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 14.0.0.Final
> Reporter: Martin Choma
> Priority: Major
> Labels: security-manager
>
> {noformat}
> org.jboss.as.test.integration.security.jaspi (2)
> EESecurityAuthMechanismTestCase.testAuthNotRequired
> EESecurityAuthMechanismTestCase.testSuccessfulAuthentication
> {noformat}
> Seems to me doPrivileged block is missing in server code somewhere.
> {noformat}
> &#27;[0m&#27;[31m00:29:39,192 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /EESecurityAuthMechanismTestCase/unsecured/index.jsp: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.plugins.JBossSecurityContext.getSubjectInfo")" in code source "(vfs:/content/EESecurityAuthMechanismTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.EESecurityAuthMechanismTestCase.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 org.jboss.security.plugins.JBossSecurityContext.getSubjectInfo(JBossSecurityContext.java:182)
> at org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack(JASPICallbackHandler.java:128)
> at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
> at org.glassfish.soteria.mechanisms.jaspic.Jaspic.handleCallbacks(Jaspic.java:196)
> at org.glassfish.soteria.mechanisms.jaspic.Jaspic.notifyContainerAboutLogin(Jaspic.java:182)
> at org.glassfish.soteria.mechanisms.HttpMessageContextImpl.doNothing(HttpMessageContextImpl.java:303)
> at org.jboss.as.test.integration.security.jaspi.SimpleHttpAuthenticationMechanism.validateRequest(SimpleHttpAuthenticationMechanism.java:43)
> at org.jboss.as.test.integration.security.jaspi.SimpleHttpAuthenticationMechanism$Proxy$_$$_WeldClientProxy.validateRequest(Unknown Source)
> at org.glassfish.soteria.mechanisms.jaspic.HttpBridgeServerAuthModule.validateRequest(HttpBridgeServerAuthModule.java:114)
> at org.glassfish.soteria.mechanisms.jaspic.DefaultServerAuthContext.validateRequest(DefaultServerAuthContext.java:76)
> at org.jboss.security.plugins.auth.JASPIServerAuthenticationManager.isValid(JASPIServerAuthenticationManager.java:115)
> at org.wildfly.extension.undertow.security.jaspi.JASPICAuthenticationMechanism.authenticate(JASPICAuthenticationMechanism.java:125)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55){noformat}
> {noformat}
> [1] https://ci.wildfly.org/viewLog.html?buildId=128138&buildTypeId=WF_MasterS...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-10380) ThreadPoolExecutor leak under SM due to lack of privileged block
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-10380?page=com.atlassian.jira.plugin... ]
Martin Choma edited comment on WFLY-10380 at 11/15/18 3:11 AM:
---------------------------------------------------------------
Linking issue with similar symptoms - WFLY-11340. In this case REST application is involved.
was (Author: mchoma):
Linking issue with similar symptoms
> ThreadPoolExecutor leak under SM due to lack of privileged block
> ----------------------------------------------------------------
>
> Key: WFLY-10380
> URL: https://issues.jboss.org/browse/WFLY-10380
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: David Lloyd
> Priority: Critical
> Labels: security-manager
>
> Still researching the source of these leaks.
> The way the leak happens is, a {{java.util.concurrent.ThreadPoolExecutor}} is constructed from an unprivileged context. The pool starts up and threads are created without a problem, however, the thread pool is never shut down. The finalizer runs but since it tries to shut down the pool with an access control context that was captured during construction, it fails because the context did not have the {{modifyThread}} {{RuntimePermission}}, and the thread pool never shuts down.
> We need to identify the points where TPEs are being constructed without controlled privileges.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-10380) ThreadPoolExecutor leak under SM due to lack of privileged block
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-10380?page=com.atlassian.jira.plugin... ]
Martin Choma commented on WFLY-10380:
-------------------------------------
Linking issue with similar symptoms
> ThreadPoolExecutor leak under SM due to lack of privileged block
> ----------------------------------------------------------------
>
> Key: WFLY-10380
> URL: https://issues.jboss.org/browse/WFLY-10380
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: David Lloyd
> Priority: Critical
> Labels: security-manager
>
> Still researching the source of these leaks.
> The way the leak happens is, a {{java.util.concurrent.ThreadPoolExecutor}} is constructed from an unprivileged context. The pool starts up and threads are created without a problem, however, the thread pool is never shut down. The finalizer runs but since it tries to shut down the pool with an access control context that was captured during construction, it fails because the context did not have the {{modifyThread}} {{RuntimePermission}}, and the thread pool never shuts down.
> We need to identify the points where TPEs are being constructed without controlled privileges.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11339) ServiceRef*TestCases fail with security manager
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-11339?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFLY-11339:
--------------------------------
Labels: security-manager (was: )
> ServiceRef*TestCases fail with security manager
> -----------------------------------------------
>
> Key: WFLY-11339
> URL: https://issues.jboss.org/browse/WFLY-11339
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 14.0.0.Final
> Reporter: Martin Choma
> Priority: Major
> Labels: security-manager
>
> Summary: ServiceRef*TestCases fail with security manager
> * ServiceRefEarTestCase
> * ServiceRefSevletTestCase
> * ServiceRefTestCase
> Having in common root exception like this
> {noformat}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/repository/org/jboss/ws/cxf/jbossws-cxf-factories/5.2.4.Final/jbossws-cxf-factories-5.2.4.Final.jar" "read")" in code source "(vfs:/content/ws-serviceref-example.ear/ws-serviceref-example-servlet-client.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ws-serviceref-example.ear.ws-serviceref-example-servlet-client.war" from Service Module Loader")
> {noformat}
> [1] https://ci.wildfly.org/viewLog.html?buildId=128138&buildTypeId=WF_MasterS...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11340) Tests in org.jboss.as.test.integration.microprofile.opentracing failing with security manager
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-11340?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFLY-11340:
--------------------------------
Labels: security-manager (was: )
> Tests in org.jboss.as.test.integration.microprofile.opentracing failing with security manager
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-11340
> URL: https://issues.jboss.org/browse/WFLY-11340
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 14.0.0.Final
> Reporter: Martin Choma
> Priority: Major
> Labels: security-manager
>
> These tests fail with security manager from package org.jboss.as.test.integration.microprofile.opentracing
> * ResourceNotTracedTestCase.notTracedEndpointYieldsNoSpans
> * ResourceTracedTestCase.tracedEndpointYieldsSpan
> * ResourceWithCDITestCase.tracedEndpointYieldsSpan
> * ResourceWithCustomOperationNameBeanTestCase.customOperationName
> * SimpleRestClientTestCase.clientRequestSpanJoinsServer
> {noformat}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "modifyThread")" in code source "(vfs:/content/3f3aff01-8e62-42e9-81c0-022f693ec7e0.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.3f3aff01-8e62-42e9-81c0-022f693ec7e0.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.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:742)
> at java.util.concurrent.ThreadPoolExecutor.shutdownNow(ThreadPoolExecutor.java:1429)
> at java.util.concurrent.Executors$DelegatedExecutorService.shutdownNow(Executors.java:670)
> at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:63)
> at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:82)
> at org.jboss.as.test.integration.microprofile.opentracing.ResourceNotTracedTestCase.performCall(ResourceNotTracedTestCase.java:63)
> at org.jboss.as.test.integration.microprofile.opentracing.ResourceNotTracedTestCase.notTracedEndpointYieldsNoSpans(ResourceNotTracedTestCase.java:57)
> {noformat}
> As stacktrace is from test side and tests are missing @RunAsClient, I believe tests are running in container. [~juraci.costa] is this really intent tests are missing @RunAsClient annotation?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11337) Hibernate tests failures with security manager
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-11337?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFLY-11337:
--------------------------------
Labels: security-manager (was: )
> Hibernate tests failures with security manager
> ----------------------------------------------
>
> Key: WFLY-11337
> URL: https://issues.jboss.org/browse/WFLY-11337
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager, Test Suite
> Affects Versions: 14.0.0.Final
> Reporter: Martin Choma
> Priority: Major
> Labels: security-manager
>
> As a limitation documented by JBEAP-15368 there is lot of tests (approximately 75) using hibernate that are failing with security manager. E.g in package
> * org.jboss.as.test.compat.jpa.hibernate.transformer
> * org.jboss.as.test.integration.hibernate
> * org.jboss.as.test.integration.hibernate.envers
> This failure contains exception like this
> {noformat}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/repository/org/hibernate/hibernate-envers/5.3.7.Final/hibernate-envers-5.3.7.Final.jar" "read")" in code source "(vfs:/content/hibernate4naturalid_test.ear/beans.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.hibernate4naturalid_test.ear.beans.jar" from Service Module Loader")
> {noformat}
> Is there way to workaround this limitation in testsuite?
> [1] https://ci.wildfly.org/viewLog.html?buildId=128138&buildTypeId=WF_MasterS...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11337) Hibernate tests failures with security manager
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-11337?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFLY-11337:
--------------------------------
Component/s: (was: Security Manager)
> Hibernate tests failures with security manager
> ----------------------------------------------
>
> Key: WFLY-11337
> URL: https://issues.jboss.org/browse/WFLY-11337
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 14.0.0.Final
> Reporter: Martin Choma
> Priority: Major
> Labels: security-manager
>
> As a limitation documented by JBEAP-15368 there is lot of tests (approximately 75) using hibernate that are failing with security manager. E.g in package
> * org.jboss.as.test.compat.jpa.hibernate.transformer
> * org.jboss.as.test.integration.hibernate
> * org.jboss.as.test.integration.hibernate.envers
> This failure contains exception like this
> {noformat}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/repository/org/hibernate/hibernate-envers/5.3.7.Final/hibernate-envers-5.3.7.Final.jar" "read")" in code source "(vfs:/content/hibernate4naturalid_test.ear/beans.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.hibernate4naturalid_test.ear.beans.jar" from Service Module Loader")
> {noformat}
> Is there way to workaround this limitation in testsuite?
> [1] https://ci.wildfly.org/viewLog.html?buildId=128138&buildTypeId=WF_MasterS...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11353) Classes for newer versions are not loaded from Multi-Release-JARs in WARs
by Daniel Schwering (Jira)
Daniel Schwering created WFLY-11353:
---------------------------------------
Summary: Classes for newer versions are not loaded from Multi-Release-JARs in WARs
Key: WFLY-11353
URL: https://issues.jboss.org/browse/WFLY-11353
Project: WildFly
Issue Type: Bug
Components: Class Loading
Affects Versions: 14.0.0.Final
Environment: Java 9+
Reporter: Daniel Schwering
Attachments: buggywar.src.zip, buggywar.war, multireleaselib-0.0.1-SNAPSHOT.jar, multireleaselib.src.zip
1
down vote
favorite
Since Java 9 there are Multi-Release JARs ([MRJARS|https://openjdk.java.net/jeps/238]) that allow different classes for different Java versions to be included in one JAR file. I was surprised when a Wildfly 14 running on Java 11 executed Java-8-code in a JAR included in a WAR although the JAR was a MRJAR with code for Java 11. That JAR included as a dependency for a regular Java SE project is running different code depending on the running JRE, but when included in a WAR, the Java-11-code seems to be ignored.
Is that expected behavior for a webserver, as Java EE 8 does not explicitly require Java 9 (which introduced MRJARs) but only Java 8?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months