[JBoss JIRA] (WFLY-7808) Security subsystem, audit provider-module lacks "module" attribute
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-7808?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-7808:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1392436|https://bugzilla.redhat.com/show_bug.cgi?id=1392436] from MODIFIED to ON_QA
> Security subsystem, audit provider-module lacks "module" attribute
> ------------------------------------------------------------------
>
> Key: WFLY-7808
> URL: https://issues.jboss.org/browse/WFLY-7808
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Peter Palaga
> Assignee: Peter Palaga
> Fix For: 11.0.0.Alpha1
>
> Time Spent: 1 day, 6 hours
> Remaining Estimate: 0 minutes
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1392436 :
> When adding a provider module for auditing:
> {code}
> [standalone@orac.usersys.redhat.com:9999 /] /subsystem=security/security-domain=LdapRealm/audit=classic/provider-module=test:add(
> => hit TAB
> code= module-options=
> {code}
> There is no attribute "module" which would allow a customer to install a custom module.
> Workaround: custom jar file must be added to the "org.picketbox" module.
> However, this needs to be checked/redone each time a CP is installed making it a big overhead when a customer has many installations.
> Logging as a bug and not an RFE, as the presence of the "module" attribute was expected.
> The "module" attribute is defined in the jboss-as-security and wildfly-security schemas since version 1.1, but it seems to never have been implemented.
> cc [~tfonteyn], [~j_ri]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-7808) Security subsystem, audit provider-module lacks "module" attribute
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-7808?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-7808:
-----------------------------------------------
Petr Jurak <pjurak(a)redhat.com> changed the Status of [bug 1392436|https://bugzilla.redhat.com/show_bug.cgi?id=1392436] from POST to MODIFIED
> Security subsystem, audit provider-module lacks "module" attribute
> ------------------------------------------------------------------
>
> Key: WFLY-7808
> URL: https://issues.jboss.org/browse/WFLY-7808
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Peter Palaga
> Assignee: Peter Palaga
> Fix For: 11.0.0.Alpha1
>
> Time Spent: 1 day, 6 hours
> Remaining Estimate: 0 minutes
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1392436 :
> When adding a provider module for auditing:
> {code}
> [standalone@orac.usersys.redhat.com:9999 /] /subsystem=security/security-domain=LdapRealm/audit=classic/provider-module=test:add(
> => hit TAB
> code= module-options=
> {code}
> There is no attribute "module" which would allow a customer to install a custom module.
> Workaround: custom jar file must be added to the "org.picketbox" module.
> However, this needs to be checked/redone each time a CP is installed making it a big overhead when a customer has many installations.
> Logging as a bug and not an RFE, as the presence of the "module" attribute was expected.
> The "module" attribute is defined in the jboss-as-security and wildfly-security schemas since version 1.1, but it seems to never have been implemented.
> cc [~tfonteyn], [~j_ri]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1138) Operation ("clean-obsolete-content") failed NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1138?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1138:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1404553|https://bugzilla.redhat.com/show_bug.cgi?id=1404553] from MODIFIED to ON_QA
> Operation ("clean-obsolete-content") failed NPE
> -----------------------------------------------
>
> Key: WFCORE-1138
> URL: https://issues.jboss.org/browse/WFCORE-1138
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: Centos 6.7, OpenJDK 1.7, Wildfly 9.0.1.Final, nginx-plus
> Domain, Full-ha, 2 nodes, one war
> Reporter: nathan dennis
> Assignee: ehsavoie Hugonnet
> Labels: nullpointerexception
> Fix For: 2.0.2.Final
>
>
> NPE happens randomly knocking the instance off line and has to be restarted.
> [Server:server-one] 13:03:37,900 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 1) WFLYCTL0013: Operation ("clean-obsolete-content") failed - address: ([]): java.lang.NullPointerException
> [Server:server-one] at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.listLocalContents(ContentRepository.java:428)
> [Server:server-one] at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.cleanObsoleteContent(ContentRepository.java:390)
> [Server:server-one] at org.jboss.as.server.mgmt.domain.RemoteFileRepositoryService.cleanObsoleteContent(RemoteFileRepositoryService.java:160)
> [Server:server-one] at org.jboss.as.server.operations.CleanObsoleteContentHandler.execute(CleanObsoleteContentHandler.java:76)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:803)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> [Server:server-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:626)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:616)
> [Server:server-one] at org.jboss.as.server.deployment.ContentRepositoryCleaner.cleanObsoleteContent(ContentRepositoryCleaner.java:132)
> [Server:server-one] at org.jboss.as.server.deployment.ContentRepositoryCleaner$ContentRepositoryCleanerTask.run(ContentRepositoryCleaner.java:67)
> [Server:server-one] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [Server:server-one] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [Server:server-one] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [Server:server-one] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [Server:server-one] at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [Server:server-one]
> [Server:server-one] 13:03:37,931 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 1) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0158: Operation handler failed: java.lang.NullPointerException
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1536) NPE thrown during application redeployment, slaves taken offline
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1536?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1536:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1406562|https://bugzilla.redhat.com/show_bug.cgi?id=1406562] from MODIFIED to ON_QA
> NPE thrown during application redeployment, slaves taken offline
> ----------------------------------------------------------------
>
> Key: WFCORE-1536
> URL: https://issues.jboss.org/browse/WFCORE-1536
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Matthew Casperson
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha2
>
>
> 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
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-7885) Persistent calendar timer force logging for each invocation if the deployed-class has changed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-7885?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-7885:
-----------------------------------------------
Petr Jurak <pjurak(a)redhat.com> changed the Status of [bug 1413033|https://bugzilla.redhat.com/show_bug.cgi?id=1413033] from POST to MODIFIED
> Persistent calendar timer force logging for each invocation if the deployed-class has changed
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-7885
> URL: https://issues.jboss.org/browse/WFLY-7885
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Ingo Weiss
> Priority: Minor
> Labels: ejb, ejb3.1, timers, timerservice
> Fix For: 11.0.0.Alpha1
>
>
> It will be common to change classes which contains @Schedule timer methods.
> In case such methods are removed or renamed (for persistent calendar timers) the server will log the following warning forever for each invocation.
> WARN [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0161: Failed to reinstate timer 'ejb31-timer.ejb31-timer.SimpleScheduleSingletonTimerBean' (id=1a419372-d807-43d8-ac77-5be6696b022d) from its persistent state
> As this is intentional there should be a WARN message at (first) deployment time and the timer should be removed from the persistence.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8131) Aliases in credential stores should be case insensitive
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-8131?page=com.atlassian.jira.plugin.... ]
Josef Cacek commented on WFLY-8131:
-----------------------------------
Usage in credential references should be also case insensitive.
> Aliases in credential stores should be case insensitive
> -------------------------------------------------------
>
> Key: WFLY-8131
> URL: https://issues.jboss.org/browse/WFLY-8131
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: credential-store, user_experience
>
> Working with credential store aliases should be case insensitive.
> Current behavior, when aliases are converted to lowercase during add operation is not user-friendly. Subsequent operations should also support automatic conversion to lowercase.
> E.g.
> {code}
> /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:add(secret-value=password)
> /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:remove()
> {code}
> *Current behavior:*
> First command succeeds and the second fails as the alias is changed to "upper" (in lowercase).
> *Expected behavior:*
> Both commans succeeds.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8131) Aliases in credential stores should be case insensitive
by Josef Cacek (JIRA)
Josef Cacek created WFLY-8131:
---------------------------------
Summary: Aliases in credential stores should be case insensitive
Key: WFLY-8131
URL: https://issues.jboss.org/browse/WFLY-8131
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Josef Cacek
Assignee: Darran Lofthouse
Priority: Critical
Working with credential store aliases should be case insensitive.
Current behavior, when aliases are converted to lowercase during add operation is not user-friendly. Subsequent operations should also support automatic conversion to lowercase.
E.g.
{code}
/subsystem=elytron/credential-store=cred-store-default/alias=UPPER:add(secret-value=password)
/subsystem=elytron/credential-store=cred-store-default/alias=UPPER:remove()
{code}
*Current behavior:*
First command succeeds and the second fails as the alias is changed to "upper" (in lowercase).
*Expected behavior:*
Both commans succeeds.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months