[JBoss JIRA] (WFLY-6191) ExpressionSubstitutionInContainerTestCase fails due to AccessControlException with security manager enabled
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6191?page=com.atlassian.jira.plugin.... ]
Ivo Studensky reassigned WFLY-6191:
-----------------------------------
Assignee: Ivo Studensky
> ExpressionSubstitutionInContainerTestCase fails due to AccessControlException with security manager enabled
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6191
> URL: https://issues.jboss.org/browse/WFLY-6191
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.management.api.expression.ExpressionSubstitutionInContainerTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.management.api.expression.ExpressionSubstitutionInContainerTestCase}}
> {code}
> Failed to start service jboss.deployment.unit."expression-substitution-test.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."expression-substitution-test.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "expression-substitution-test.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/expression-substitution-test.jar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1525)
> at java.lang.Class.getClassLoader(Class.java:683)
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1529)
> at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51)
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099)
> at org.jboss.msc.service.ServiceControllerImpl.commitInstallation(ServiceControllerImpl.java:265)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:771)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> at org.jboss.as.test.integration.management.api.expression.ExpressionTestManagementService.activate(ExpressionTestManagementService.java:69)
> at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:74)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6192) JAXBUsageTestCase fails with security manager with security manager enabled
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6192?page=com.atlassian.jira.plugin.... ]
Ivo Studensky reassigned WFLY-6192:
-----------------------------------
Assignee: Ivo Studensky
> JAXBUsageTestCase fails with security manager with security manager enabled
> ---------------------------------------------------------------------------
>
> Key: WFLY-6192
> URL: https://issues.jboss.org/browse/WFLY-6192
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6194) Tests fail with "java.util.PropertyPermission" with security manager enabled
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6194?page=com.atlassian.jira.plugin.... ]
Ivo Studensky reassigned WFLY-6194:
-----------------------------------
Assignee: Ivo Studensky
> Tests fail with "java.util.PropertyPermission" with security manager enabled
> ----------------------------------------------------------------------------
>
> Key: WFLY-6194
> URL: https://issues.jboss.org/browse/WFLY-6194
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.ee.injection.support.websocket.WebSocketInjectionSupportTestCase#testWebSocketInjectionAndInterception*
> *org.jboss.as.test.integration.ee.suspend.EEConcurrencySuspendTestCase#testRequestInShutdown*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.ee.injection.support.websocket.WebSocketInjectionSupportTestCase#testWebSocketInjectionAndInterception}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.ee.suspend.EEConcurrencySuspendTestCase#testRequestInShutdown}}
> Fail with:
> {code}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "management.address" "read")" in code source "(vfs:/content/ee-suspend.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:496)
> at java.lang.System.getProperty(System.java:717)
> at org.jboss.as.test.shared.TestSuiteEnvironment.getServerAddress(TestSuiteEnvironment.java:77)
> at org.jboss.as.test.integration.ee.suspend.EEConcurrencySuspendTestCase.testRequestInShutdown(EEConcurrencySuspendTestCase.java:77)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1101) Upgrade protobuf-java from 2.5.0 to 2.6.0
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1101?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-1101:
------------------------------------------
Once jbpm-flow is compiled from source against protobuf 2.6, that failure above goes away.
*Protobuf 2.6 is source backwards compatible - but not binary backwards compatible - with 2.5. So our users can't use 2.6 with old jbpm versions, but we can upgrade without trouble.*
> Upgrade protobuf-java from 2.5.0 to 2.6.0
> -----------------------------------------
>
> Key: DROOLS-1101
> URL: https://issues.jboss.org/browse/DROOLS-1101
> Project: Drools
> Issue Type: Task
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Geoffrey De Smet
>
> From RPM discussion (BPMSPL-282)
> Productization: protobuf-java redhat version is: 2.6.0-redhat-1, is it ok to upgrade from 2.5.0->2.6.0?
> Motivation:
> - The 2.5 version isn't build from source by productization, there is no redhat version.
> - The 2.6 version is, which means they can do security patches on it easily (= important for long term support) and it can be RPM'ed (important for BPMSPL-282, which has PM support)
> - 2.6 is higher than 2.5, so in theory this is low-risk change.
> Needed on both master and 6.4.x.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6223) Enabling statistics in web console requires reload while it doesn't in CLI
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6223?page=com.atlassian.jira.plugin.... ]
Chao Wang edited comment on WFLY-6223 at 3/22/16 1:34 AM:
----------------------------------------------------------
This is not an issue in HAL as originally reported. When it writes the attributes in ws provider form, it writes also attribute Wsdl host : ${jboss.bind.address:127.0.0.1} as well, which requires a reload action if there is an active ws deployment. Because WSServerConfigAttributeHandler compares unresolved current value to a resolved value. If you click "Save" without changing any value, it asks for a server reload as well.
was (Author: soul2zimate):
This is not an issue in HAL as originally reported. When it writes the attributes in ws provider form, it write also attribute Wsdl host : ${jboss.bind.address:127.0.0.1} as well, which requires a reload action if there is an active ws deployment. Because WSServerConfigAttributeHandler compares unresolved current value to a resolved value. If you click "Save" without changing any value, it asks for a server reload as well.
> Enabling statistics in web console requires reload while it doesn't in CLI
> --------------------------------------------------------------------------
>
> Key: WFLY-6223
> URL: https://issues.jboss.org/browse/WFLY-6223
> Project: WildFly
> Issue Type: Bug
> Components: Web Console, Web Services
> Affects Versions: 10.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> If I want to enable statistics for Web Services subsystem, I do it in CLI:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=webservices:write-attribute(name=statistics-enabled, value=true)
> {"outcome" => "success"}
> {noformat}
> Via web console, I navigate to Configuration->Subsystems->Web Services->View
> I click edit and click checkbox for statistics enabled attribute. Now when I submit the value by clicking Save, dialog appears with reload require information.
> There is no need to require reload just for enabling statistics, by the way statistics are accessible even before reload (Runtime->Subsystems->Webservices and try to get wsdl for the web service for several times).
> Note: if there is no active deployment, reload is not required in web console (correct). To reproduce the issue you must have some active WS deployment
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBMETA-369) Compilation error in AbstractWebServiceRefProcessor with JDK7
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/JBMETA-369?page=com.atlassian.jira.plugin... ]
Chao Wang closed JBMETA-369.
----------------------------
Resolution: Out of Date
> Compilation error in AbstractWebServiceRefProcessor with JDK7
> -------------------------------------------------------------
>
> Key: JBMETA-369
> URL: https://issues.jboss.org/browse/JBMETA-369
> Project: JBoss Metadata
> Issue Type: Bug
> Affects Versions: 1.0.6.GA
> Environment: Java version: 1.7.0_40, vendor: Oracle Corporation
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> When I built jboss metadata on https://svn.jboss.org/repos/jbossas/projects/metadata/trunk
> I received a compilation error in AbstractWebServiceRefProcessor with JDK7, but I can build without this error with JDK6.
> {noformat}
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 7.340s
> [INFO] Finished at: Mon Dec 02 17:20:37 CST 2013
> [INFO] Final Memory: 13M/211M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project jboss-metadata: Compilation failure
> [ERROR] /home/wangchao/work/jbossas/EAP5/metadata/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[116,28] error: incomparable types: Class<CAP#1> and Class<Object>
> {noformat}
> the error indicates to AbstractWebServiceRefProcessor.java:
> {code:title=AbstractWebServiceRefProcessor.java|borderStyle=solid}
> if(annotation.value() != Object.class && annotation.value() != Service.class)
> ref.setServiceInterface(annotation.value().getName());
> {code}
> From JAX-WS 2.1 to 2.2 API, the value type and default value have been changed from Object.class to Service.class.
> {code:title=WebServiceRef.java|borderStyle=solid}
> /**
> * The service class, alwiays a type extending
> * <code>javax.xml.ws.Service</code>. This element MUST be specified
> * whenever the type of the reference is a service endpoint interface.
> */
> // 2.1 has Class value() default Object.class;
> // Fixing this raw Class type correctly in 2.2 API. This shouldn't cause
> // any compatibility issues for applications.
> Class<? extends Service> value() default Service.class;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1446) EJB thread pool keepalive not honored and is not reusing inactive threads
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1446?page=com.atlassian.jira.plugi... ]
Brad Maxwell moved JBEAP-3913 to WFCORE-1446:
---------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1446 (was: JBEAP-3913)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: (was: EJB)
Target Release: (was: 7.backlog.GA)
Affects Version/s: (was: 7.0.0.ER5)
> EJB thread pool keepalive not honored and is not reusing inactive threads
> -------------------------------------------------------------------------
>
> Key: WFCORE-1446
> URL: https://issues.jboss.org/browse/WFCORE-1446
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Brad Maxwell
> Assignee: Panagiotis Sotiropoulos
>
> Copied description from BZ1255494 :
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there. The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6413) Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6413?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-6413.
----------------------------------
Resolution: Out of Date
This is already working upstream with no need to configure the range handler (see https://issues.jboss.org/browse/WFLY-6387).
I have created https://issues.jboss.org/browse/UNDERTOW-664 for the range handler not dealing with HEAD requests.
> Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6413
> URL: https://issues.jboss.org/browse/WFLY-6413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0.0.Final
> Windows 7 or Mac 10.11.3
> Java 8
> Chrome, Firefox, Safari
> Reporter: Jason Holmberg
> Assignee: Stuart Douglas
> Priority: Critical
>
> Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
> After enabling range headers as described here:
> https://developer.jboss.org/message/953058#953058
> I made some range requests via `curl` to see what is being returned:
> This is the result of a request to *WildFly* with the Range headers enabled:
> {noformat}
> $ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
> X-Powered-By: Undertow/1
> Server: WildFly/10
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 16:59:55 GMT
> {noformat}
> This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat 8*:
> {noformat}
> $ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
> HTTP/1.1 206 Partial Content
> Server: Apache-Coyote/1.1
> Accept-Ranges: bytes
> ETag: W/"8200890-1458232627000"
> Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
> Content-Range: bytes 0-8200889/8200890
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 17:00:08 GMT
> {noformat}
> I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month