March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2533) DeploymentRolloutFailureTestCase fails with security manager in WF core

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2533?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2533: ------------------------------------- Component/s: Domain Management > DeploymentRolloutFailureTestCase fails with security manager in WF core > ----------------------------------------------------------------------- > > Key: WFCORE-2533 > URL: https://issues.jboss.org/browse/WFCORE-2533 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Jan Tymel > > *org.jboss.as.test.integration.domain.suites.DeploymentRolloutFailureTestCase#test* > {{cd testsuite/domain/}} > {{mvn test -Dtest=DeploymentRolloutFailureTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > [Server:main-three] 13:08:06,210 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "broken.jar" (runtime-name: "broken.jar") > [Server:main-three] 13:08:06,318 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service test.deployment.broken: org.jboss.msc.service.StartException in service test.deployment.broken: Failed to start service > [Server:main-three] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:main-three] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0] > [Server:main-three] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0] > [Server:main-three] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0] > [Server:main-three] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.broken.fail" "read")" in code source "(vfs:/content/broken.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.broken.jar" from Service Module Loader") > [Server:main-three] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:main-three] at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:469) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:main-three] at java.lang.System.getProperty(System.java:443) [vm.jar:1.8.0] > [Server:main-three] at java.lang.System.getProperty(System.java:427) [vm.jar:1.8.0] > [Server:main-three] at java.lang.Boolean.getBoolean(Boolean.java:265) [rt.jar:1.8.0] > [Server:main-three] at org.jboss.as.test.integration.domain.deployment.broken.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:54) > [Server:main-three] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:main-three] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:main-three] ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1220) Try closing the channel if java.lang.Error prevents sending error responses to the client

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1220?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1220: ---------------------------------------- Assignee: (was: Brian Stansberry) > Try closing the channel if java.lang.Error prevents sending error responses to the client > ----------------------------------------------------------------------------------------- > > Key: WFCORE-1220 > URL: https://issues.jboss.org/browse/WFCORE-1220 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Brian Stansberry > Labels: domain-mode > > Beyond the basic work on WFCORE-1134, look into further reaction when Errors occur and the server or HC cannot even send an error response to the caller. If we get to this point, the task has already failed to handle a problem and now we can't notify the remote side either. Most likely this is an OOME situation, although any Error here means a major issue. > Options: > 1) Try and close the channel to disconnect this process from the remote end so it doesn't disrupt the remote end. If this is an intra-HC or HC-server connection a successful close will remove this process from normal domain control. If this is a server the HC still has some control over the server via the ProcessController, e.g. to handle a 'kill' or 'destroy' management op. If this is a slave HC, the slave is disconnected from the domain. Either a server or a slave HC may try to reconnect, although it's likely better if that fails and the user just restarts the process. > If the remote side is an end user client (e.g. CLI) then a successful close will be noticed by the client. The user can reconnect or take action to terminate this process. > 2) Commit suicide via SystemExiter.exit. But I'm not certain complete termination of the process is how we want to deal with problems with management requests. Probably some sort of configurable policy would be better. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1058) Encapsulate logic to specify dynamic capability name resolution from a PathAddress

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1058?page=com.atlassian.jira.plugi... ] Tomaz Cerar resolved WFCORE-1058. --------------------------------- Resolution: Done This is now done as part of work on WFCORE-2202 On RuntimeCapabilty you now have #setDynamicNameMapper(Function<PathAddress,String[]>) Which species the mapping between path address and dynamic parts There is also new CompositeAttributeDependencyRecorder which takes this dynamic parts into account where recording requirements. When building attributes you have new variants to set capability reference #setCapabilityReference(String referencedCapability, AttributeDefinition ... dependantAttributes) and few others. > Encapsulate logic to specify dynamic capability name resolution from a PathAddress > ---------------------------------------------------------------------------------- > > Key: WFCORE-1058 > URL: https://issues.jboss.org/browse/WFCORE-1058 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > > One can create a capability whose dynamic name is not resolved using the value of the last element of a path address (e.g. using the value of a parent resource). In this case, the logic for generating the dynamic name need to be modified in multiple places. > # CapabilityReferenceRecorder.DefaultCapabilityReferenceRecorder.getDynamicDependentName(...) > # AbstractAddStepHandler.recordCapabilitiesAndRequirements(...) > # AbstractRemoveStepHandler.recordCapabilitiesAndRequirements(...) > For reference, the clustering subsystems handle this via a custom abstraction: > https://github.com/wildfly/wildfly/blob/master/clustering/common/src/main... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1058) Encapsulate logic to specify dynamic capability name resolution from a PathAddress

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1058?page=com.atlassian.jira.plugi... ] Tomaz Cerar edited comment on WFCORE-1058 at 3/17/17 8:09 PM: -------------------------------------------------------------- This is now done as part of work on WFCORE-2202 On RuntimeCapabilty you now have #setDynamicNameMapper(Function<PathAddress,String[]>) Which defines the mapping between path address and dynamic parts There is also new CompositeAttributeDependencyRecorder which takes this dynamic parts into account where recording requirements. When building attributes you have new variants to set capability reference #setCapabilityReference(String referencedCapability, AttributeDefinition ... dependantAttributes) and few others. was (Author: ctomc): This is now done as part of work on WFCORE-2202 On RuntimeCapabilty you now have #setDynamicNameMapper(Function<PathAddress,String[]>) Which species the mapping between path address and dynamic parts There is also new CompositeAttributeDependencyRecorder which takes this dynamic parts into account where recording requirements. When building attributes you have new variants to set capability reference #setCapabilityReference(String referencedCapability, AttributeDefinition ... dependantAttributes) and few others. > Encapsulate logic to specify dynamic capability name resolution from a PathAddress > ---------------------------------------------------------------------------------- > > Key: WFCORE-1058 > URL: https://issues.jboss.org/browse/WFCORE-1058 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > > One can create a capability whose dynamic name is not resolved using the value of the last element of a path address (e.g. using the value of a parent resource). In this case, the logic for generating the dynamic name need to be modified in multiple places. > # CapabilityReferenceRecorder.DefaultCapabilityReferenceRecorder.getDynamicDependentName(...) > # AbstractAddStepHandler.recordCapabilitiesAndRequirements(...) > # AbstractRemoveStepHandler.recordCapabilitiesAndRequirements(...) > For reference, the clustering subsystems handle this via a custom abstraction: > https://github.com/wildfly/wildfly/blob/master/clustering/common/src/main... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3030) Test Suite is not security manager-aware

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3030?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-3030. ------------------------------------ Resolution: Out of Date While this is by no means all cleaned up, I'm going to resolve this as out of date as since this was filed there have been and still are a great many separate issues tracking particular problems. > Test Suite is not security manager-aware > ---------------------------------------- > > Key: WFLY-3030 > URL: https://issues.jboss.org/browse/WFLY-3030 > Project: WildFly > Issue Type: Task > Components: Test Suite > Affects Versions: 8.0.0.Final > Reporter: David Lloyd > > Our test suite has over 1000 failures running in security manager mode ({{-Dsecurity.manager}}). These are due in large part to missing {{permissions.xml}} files. Just adding these files to each test/arq deployment should cut the number of failures down dramatically. > Once this is done, individual test failures can be tackled. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8148) Intermittent failure in InterDeploymentDependenciesEarTestCase

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-8148?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-8148. ------------------------------------ Resolution: Duplicate Issue > Intermittent failure in InterDeploymentDependenciesEarTestCase > -------------------------------------------------------------- > > Key: WFLY-8148 > URL: https://issues.jboss.org/browse/WFLY-8148 > Project: WildFly > Issue Type: Bug > Components: EE, Test Suite > Reporter: Brian Stansberry > > On a fairly frequent basis we are seeing failures in InterDeploymentDependenciesEarTestCase. This then seems to be followed by ~ 200 other failures. > https://ci.wildfly.org/viewLog.html?buildId=46213&buildTypeId=WildFlyCore... is an example. > Pattern is: > Failure: > {code} > javax.ejb.NoSuchEJBException: No such EJB: app2/hello/LogAccessBean > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:354) > at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:75) > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:357) > at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:608) > at org.jboss.ejb.client.EJBInvocationHandler.lambda$invoke$0(EJBInvocationHandler.java:164) > at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:428) > at org.jboss.ejb.client.EJBClientContext.performLocatedAction(EJBClientContext.java:387) > at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:150) > at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100) > at com.sun.proxy.$Proxy65.getLog(Unknown Source) > at org.jboss.as.test.integration.deployment.dependencies.ear.InterDeploymentDependenciesEarTestCase.test(InterDeploymentDependenciesEarTestCase.java:127) > {code} > Earliest failure I see with this pattern in the TeamCity history is from Aug 17, 2016. But such failures were confined to JDK9 runs and stopped last Sept 2. Then they start appearing quite frequently on Feb 6, 2017. First appearance was in a test of PR #9600, but there are other failures before that PR was merged so I doubt that PR is relevant. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1058) Encapsulate logic to specify dynamic capability name resolution from a PathAddress

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1058?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1058: ---------------------------------------- Assignee: Tomaz Cerar (was: Brian Stansberry) [~ctomc] I believe this is done. > Encapsulate logic to specify dynamic capability name resolution from a PathAddress > ---------------------------------------------------------------------------------- > > Key: WFCORE-1058 > URL: https://issues.jboss.org/browse/WFCORE-1058 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > > One can create a capability whose dynamic name is not resolved using the value of the last element of a path address (e.g. using the value of a parent resource). In this case, the logic for generating the dynamic name need to be modified in multiple places. > # CapabilityReferenceRecorder.DefaultCapabilityReferenceRecorder.getDynamicDependentName(...) > # AbstractAddStepHandler.recordCapabilitiesAndRequirements(...) > # AbstractRemoveStepHandler.recordCapabilitiesAndRequirements(...) > For reference, the clustering subsystems handle this via a custom abstraction: > https://github.com/wildfly/wildfly/blob/master/clustering/common/src/main... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMETA-381) DefaultPropertyReplacer can't handle ${:} expression

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/JBMETA-381?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved JBMETA-381. ------------------------------------- Fix Version/s: 8.1.1.Final 7.2.0.Final Resolution: Done > DefaultPropertyReplacer can't handle ${:} expression > ---------------------------------------------------- > > Key: JBMETA-381 > URL: https://issues.jboss.org/browse/JBMETA-381 > Project: JBoss Metadata > Issue Type: Bug > Components: common > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 8.1.1.Final, 7.2.0.Final > > > If the string "${:}" is passed to default property replacer, it does not parse it as indicating File.pathSeparator; rather it treats it as the default delimiter. > ${:} resolves to an empty string. > a${:} resolves to a > ${:}a resolves to a -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-840) Improve API on AttributeDefinitions where a capability is referenced.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-840?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved WFCORE-840. ------------------------------------- Resolution: Out of Date The unambiguous case no longer requires you to provide the name of the dependent capability. > Improve API on AttributeDefinitions where a capability is referenced. > --------------------------------------------------------------------- > > Key: WFCORE-840 > URL: https://issues.jboss.org/browse/WFCORE-840 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 2.0.0.Alpha11 > Reporter: Darran Lofthouse > Assignee: Tomaz Cerar > > Take the following method call defining an attribute: - > {code} > .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true) > {code} > This definition says this attribute references something which provides the PROVIDERS_CAPABILITY. > However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY. > Really what the resource provides is not directly related to this attribute definition. > The following pull request has already improved on registering in advance what capability a resource can provide: - > https://github.com/wildfly/wildfly-core/pull/909 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1342) Lazy Enlistment expects active transaction

by Flavia Rainone (JIRA)

Flavia Rainone created JBJCA-1342: ------------------------------------- Summary: Lazy Enlistment expects active transaction Key: JBJCA-1342 URL: https://issues.jboss.org/browse/JBJCA-1342 Project: IronJacamar Issue Type: Bug Components: Deployer Reporter: Flavia Rainone Assignee: Flavia Rainone Lazy enlistment fails when there is no active transaction: javax.resource.ResourceException: IJ000652: Unable to obtain lock org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.lazyEnlist(TxConnectionManagerImpl.java:820) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2017