[JBoss JIRA] (ELY-530) Configurable PermissionMapper
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-530:
------------------------------------
Summary: Configurable PermissionMapper
Key: ELY-530
URL: https://issues.jboss.org/browse/ELY-530
Project: WildFly Elytron
Issue Type: Feature Request
Components: Permissions
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta6
This is to provide a simple configurable PermissionMapper implementation that provides a 'reasonable' level of PermissionVerifier functionality predominantly in the form of assigning Permission or PermissionCollections based on matching against the SecurityIdentity / Roles set.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ELY-529) Aggregate / Logical Permission Mapper
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-529:
------------------------------------
Summary: Aggregate / Logical Permission Mapper
Key: ELY-529
URL: https://issues.jboss.org/browse/ELY-529
Project: WildFly Elytron
Issue Type: Feature Request
Components: Permissions
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta6
The PermissionVerfiers returned by PermissionMapper support chaining logically - we should have PermissionMapper implementations that take the PermisionVerifiers from other PermisionMappers and chain them this way.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBVFS-205) File system operations require both java.io.FilePermission and VirtualFilePermission
by Ivo Studensky (JIRA)
Ivo Studensky created JBVFS-205:
-----------------------------------
Summary: File system operations require both java.io.FilePermission and VirtualFilePermission
Key: JBVFS-205
URL: https://issues.jboss.org/browse/JBVFS-205
Project: JBoss VFS
Issue Type: Bug
Affects Versions: 3.2.11.Final, 3.5.0.Alpha1
Reporter: Ivo Studensky
Assignee: Ivo Studensky
Fix For: 3.5.0.Alpha1, 3.2.12.Final
File system operations in org.jboss.vfs.VirtualFile check for VirtualFilePermission and then execute the particular io operation which needs java.io.FilePermission if Security Manager is enabled. Because of this a user has to duplicate each permission on a deployment for both VirtualFilePermission and FilePermission.
It should be enough to check for VirtualFilePermission and execute the io operation inside of the privileged block afterwards.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1532) Upgrade VFS to 3.2.12.Final
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1532?page=com.atlassian.jira.plugi... ]
Ivo Studensky moved JBEAP-4557 to WFCORE-1532:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1532 (was: JBEAP-4557)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: VFS
(was: VFS)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 2.1.0.Final
(was: 7.0.0.GA)
> Upgrade VFS to 3.2.12.Final
> ---------------------------
>
> Key: WFCORE-1532
> URL: https://issues.jboss.org/browse/WFCORE-1532
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: VFS
> Affects Versions: 2.1.0.Final
> Reporter: Ivo Studensky
> Assignee: Tomaz Cerar
>
> Upgrade VFS to address JBVFS-204.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBAS-9578) Enabling/Disabling a Datasource prompts for server restart
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/JBAS-9578?page=com.atlassian.jira.plugin.... ]
Steven Hawkins reassigned JBAS-9578:
------------------------------------
Assignee: (was: Steven Hawkins)
This has been communicated to the Teiid/DV team as the expected behavior - which also affects data source operations we do from the admin api. So I'll forward this over to the JBAS tracker.
> Enabling/Disabling a Datasource prompts for server restart
> ----------------------------------------------------------
>
> Key: JBAS-9578
> URL: https://issues.jboss.org/browse/JBAS-9578
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Environment: Red Hat JBoss Data Virtualization 6.2.4 on EAP patched to version 6.4.6, on Oracle Linux 6
> JBoss Developer Studio 8.1.0GA with Teiid Designer 9.0.6.Final-v20160316-1409-B1242 org.teiid.designer.feature.feature.group JBoss by Red Hat, Inc.
> 64-bit Windows 7 environment
> Reporter: Steve Tran
> Attachments: Capture.PNG
>
>
> When I enable or disable a Datasource in EAP (tested only in domain mode), I get a message that prompts me to restart my server because configurations have changed. This is a new warning because it didn't do this in earlier version of EAP6.4. If I go to the topology screen, none of the servers are marked with the symbol that says it needs to be restarted. If I drill down into the specific node and server, the Datasource was marked as disabled in the UI, so I think it did actually turned off the Datasource correctly.
> I think the prompt is wrong, and should be removed. Also, this might be an EAP bug and not JDV related.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBAS-9578) Enabling/Disabling a Datasource prompts for server restart
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/JBAS-9578?page=com.atlassian.jira.plugin.... ]
Steven Hawkins moved TEIID-4190 to JBAS-9578:
---------------------------------------------
Project: Application Server 3 4 5 and 6 (was: Teiid)
Key: JBAS-9578 (was: TEIID-4190)
> Enabling/Disabling a Datasource prompts for server restart
> ----------------------------------------------------------
>
> Key: JBAS-9578
> URL: https://issues.jboss.org/browse/JBAS-9578
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Environment: Red Hat JBoss Data Virtualization 6.2.4 on EAP patched to version 6.4.6, on Oracle Linux 6
> JBoss Developer Studio 8.1.0GA with Teiid Designer 9.0.6.Final-v20160316-1409-B1242 org.teiid.designer.feature.feature.group JBoss by Red Hat, Inc.
> 64-bit Windows 7 environment
> Reporter: Steve Tran
> Assignee: Steven Hawkins
> Attachments: Capture.PNG
>
>
> When I enable or disable a Datasource in EAP (tested only in domain mode), I get a message that prompts me to restart my server because configurations have changed. This is a new warning because it didn't do this in earlier version of EAP6.4. If I go to the topology screen, none of the servers are marked with the symbol that says it needs to be restarted. If I drill down into the specific node and server, the Datasource was marked as disabled in the UI, so I think it did actually turned off the Datasource correctly.
> I think the prompt is wrong, and should be removed. Also, this might be an EAP bug and not JDV related.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6083) Removing of non-existent login-module finishes with outcome success
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6083?page=com.atlassian.jira.plugin.... ]
Chao Wang commented on WFLY-6083:
---------------------------------
Hi [~brian.stansberry] if you don't mind, I 'll close this as duplicate of WFCORE-1523
> Removing of non-existent login-module finishes with outcome success
> -------------------------------------------------------------------
>
> Key: WFLY-6083
> URL: https://issues.jboss.org/browse/WFLY-6083
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 10.0.0.Final
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
> Priority: Minor
>
> In case when non-existent login-module is removed through Management CLI, opertation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBJCA-1318) list driven ExceptionSorter, StaleConnectionChecker
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1318?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1318:
------------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1320720|https://bugzilla.redhat.com/show_bug.cgi?id=1320720] from ON_QA to VERIFIED
> list driven ExceptionSorter, StaleConnectionChecker
> ---------------------------------------------------
>
> Key: JBJCA-1318
> URL: https://issues.jboss.org/browse/JBJCA-1318
> Project: IronJacamar
> Issue Type: Task
> Components: JDBC
> Reporter: Johnathon Lee
> Assignee: Johnathon Lee
> Priority: Minor
> Fix For: WildFly/IronJacamar 1.3.4.Final, 1.0.37.Final, 1.2.8.Final
>
>
> Configuration defined ExceptionSorter, StaleConnectionChecker.
> Using an externally (from the implementation) defined "," separated list.
> Defined via '<config-property name=prop_name >value1,value2,value3</>' in the standalone/domain configuration files.
> ie:
> set via <config-property name="FatalExceptions">10099,10100,10101</>
> set via <config-property name="StaleExceptions">10099,10100,10101</>
> Documentation updated to reflect suggested error codes for vendor based upon the current implementations.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6592) NPE thrown during application redeployment, slaves taken offline
by Matthew Casperson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6592?page=com.atlassian.jira.plugin.... ]
Matthew Casperson commented on WFLY-6592:
-----------------------------------------
Thinking about this error, I suspect this is what happens to cause it:
1. We deploy an app to a domain controller with 2 slaves
2. The deployment on one slave fails because of memory issues (not a wildfly bug, more of a regular "os doesn't have swap memory and we assigned to much to java" issue)
3. At this point the deployment of the app is rolled back, but the server that didn't run out of memory doesn't have anything to roll back, causing the NPE.
I haven't tested this theory yet, but it could be more than a coincidence.
> NPE thrown during application redeployment, slaves taken offline
> ----------------------------------------------------------------
>
> Key: WFLY-6592
> URL: https://issues.jboss.org/browse/WFLY-6592
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Matthew Casperson
> Assignee: Jason Greene
>
> We have some development Wildfly 10.0.0 servers running as slaves in a domain that frequently have WAR files redeployed. We have noticed that these slaves will often go offline after a redeployment of WAR files with the following stack trace:
> {code}
> 2016-05-06 05:05:51,306 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 1012) WFLYCTL0190: Step handler org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler@3f68226b for operation {"operation" => "full-replace-deployment","name" => "whatever.war","enabled" => true,"content" => [{"hash" => bytes { 0x5d, 0x12, 0x18, 0x2b, 0x1c, 0x86, 0x71, 0x27, 0x08, 0x3d, 0xf1, 0x75, 0x08, 0x29, 0xa6, 0x49, 0x1f, 0x16, 0xe8, 0x22 }}],"operation-headers" => {"access-mechanism" => "NATIVE","domain-uuid" => "802ab616-dd2c-4081-a79c-c4d54e14c384","push-to-servers" => undefined},"address" => [],"runtime-name" => undefined} at address [] failed handling operation rollback -- java.lang.NullPointerException: java.lang.NullPointerException
> at org.jboss.as.repository.LocalDeploymentFileRepository.deleteDeployment(LocalDeploymentFileRepository.java:59)
> at org.jboss.as.host.controller.RemoteDomainConnectionService$RemoteFileRepository.deleteDeployment(RemoteDomainConnectionService.java:756)
> at org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler$1.handleResult(DeploymentFullReplaceHandler.java:181)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> This error will usually only happen for 2 out of the 4 identically configured slaves, and seems to happen randomly, although frequently enough.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years