[JBoss JIRA] (ELY-1037) CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected).
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1037?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek updated ELY-1037:
------------------------------
Description:
Without --location parameter a credential store storage file isn't saved (or save as is expected).
It pass but I am not able find credential store storage file on disk.
{code}
[hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary
Alias "myalias" has been successfully stored
Credential store command summary:
--------------------------------------
/subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"})
{code}
It pass with this URI value and I am able to find credential store storage file on disk.
{code}
uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS"
{code}
I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha...
(test.store is interpreded as hostname in URI in first case)
*NOTE*
Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450.
Behaviour must be consistent!
was:
Without --location parameter a credential store storage file isn't saved (or save as is expected).
{code}
[hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary
Alias "myalias" has been successfully stored
Credential store command summary:
--------------------------------------
/subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"})
{code}
It pass with this URI value and I am able to find credential store storage file on disk.
{code}
uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS"
{code}
I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha...
(test.store is interpreded as hostname in URI in first case)
*NOTE*
Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450.
Behaviour must be consistent!
> CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected).
> -----------------------------------------------------------------------------------------------------------
>
> Key: ELY-1037
> URL: https://issues.jboss.org/browse/ELY-1037
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
>
> Without --location parameter a credential store storage file isn't saved (or save as is expected).
> It pass but I am not able find credential store storage file on disk.
> {code}
> [hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary
> Alias "myalias" has been successfully stored
> Credential store command summary:
> --------------------------------------
> /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"})
> {code}
> It pass with this URI value and I am able to find credential store storage file on disk.
> {code}
> uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS"
> {code}
> I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha...
> (test.store is interpreded as hostname in URI in first case)
> *NOTE*
> Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450.
> Behaviour must be consistent!
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1037) CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected).
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1037?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek updated ELY-1037:
------------------------------
Description:
Without --location parameter a credential store storage file isn't saved (or save as is expected).
{code}
[hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary
Alias "myalias" has been successfully stored
Credential store command summary:
--------------------------------------
/subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"})
{code}
It pass with this URI value and I am able to find credential store storage file on disk.
{code}
uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS"
{code}
I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha...
(test.store is interpreded as hostname in URI in first case)
*NOTE*
Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450.
Behaviour must be consistent!
was:
Without --location parameter a credential store storage file isn't saved (or save as is expected).
{code}
[hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary
Alias "myalias" has been successfully stored
Credential store command summary:
--------------------------------------
/subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"})
{code}
It pass with this URI value.
{code}
uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS"
{code}
I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha...
(test.store is interpreded as hostname in URI in first case)
*NOTE*
Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450.
Behaviour must be consistent!
> CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected).
> -----------------------------------------------------------------------------------------------------------
>
> Key: ELY-1037
> URL: https://issues.jboss.org/browse/ELY-1037
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
>
> Without --location parameter a credential store storage file isn't saved (or save as is expected).
> {code}
> [hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary
> Alias "myalias" has been successfully stored
> Credential store command summary:
> --------------------------------------
> /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"})
> {code}
> It pass with this URI value and I am able to find credential store storage file on disk.
> {code}
> uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS"
> {code}
> I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha...
> (test.store is interpreded as hostname in URI in first case)
> *NOTE*
> Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450.
> Behaviour must be consistent!
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1037) CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected).
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-1037:
---------------------------------
Summary: CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected).
Key: ELY-1037
URL: https://issues.jboss.org/browse/ELY-1037
Project: WildFly Elytron
Issue Type: Bug
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Without --location parameter a credential store storage file isn't saved (or save as is expected).
{code}
[hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary
Alias "myalias" has been successfully stored
Credential store command summary:
--------------------------------------
/subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"})
{code}
It pass with this URI value.
{code}
uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS"
{code}
I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha...
(test.store is interpreded as hostname in URI in first case)
*NOTE*
Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450.
Behaviour must be consistent!
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8457) TimerService.getTimers() does not return persisted timers in @PreDestroy method
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-8457?page=com.atlassian.jira.plugin.... ]
Ingo Weiss updated WFLY-8457:
-----------------------------
Environment: (was: JBoss EAP 7.x)
> TimerService.getTimers() does not return persisted timers in @PreDestroy method
> -------------------------------------------------------------------------------
>
> Key: WFLY-8457
> URL: https://issues.jboss.org/browse/WFLY-8457
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
> Attachments: TimerBean.java, TimerServiceEJBBug.jar
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Injecting the TimerService with an @Resource annotation
> {quote}
> @Resource
> private TimerService timerService;
> {quote}
> When I call timerService.getTimers().size() in the @PreDestroy method, it always return 0.
> If I deploy the same application in jboss eap 6, then timerService.getTimers().size() return 1.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8457) TimerService.getTimers() does not return persisted timers in @PreDestroy method
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-8457?page=com.atlassian.jira.plugin.... ]
Ingo Weiss moved JBEAP-9933 to WFLY-8457:
-----------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8457 (was: JBEAP-9933)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
(was: EJB)
Affects Version/s: 11.0.0.Alpha1
(was: 7.0.4.GA)
> TimerService.getTimers() does not return persisted timers in @PreDestroy method
> -------------------------------------------------------------------------------
>
> Key: WFLY-8457
> URL: https://issues.jboss.org/browse/WFLY-8457
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Alpha1
> Environment: JBoss EAP 7.x
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
> Attachments: TimerBean.java, TimerServiceEJBBug.jar
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Injecting the TimerService with an @Resource annotation
> {quote}
> @Resource
> private TimerService timerService;
> {quote}
> When I call timerService.getTimers().size() in the @PreDestroy method, it always return 0.
> If I deploy the same application in jboss eap 6, then timerService.getTimers().size() return 1.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1036) CS tool, There is possibility define same option parameter more times.
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-1036:
---------------------------------
Summary: CS tool, There is possibility define same option parameter more times.
Key: ELY-1036
URL: https://issues.jboss.org/browse/ELY-1036
Project: WildFly Elytron
Issue Type: Bug
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
There is possibility define same option parameter more times. It doesn't matter if some short/long form or combination there is used first occurrence in command.
Command with two option "add" and "secret".
{code}
[hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary --salt 12345678 --iteration 230 --add alias2 --secret secretValue2
Alias "myalias" has been successfully stored
Credential store command summary:
--------------------------------------
/subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="MASK-uNWeyrmbByBEjgZM1FAPQW==;12345678;230"})
{code}
*Same for "mask" command.*
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1035) CS tool, Error msg with mutually exclusive parameters must contain "really" used option names.
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-1035:
---------------------------------
Summary: CS tool, Error msg with mutually exclusive parameters must contain "really" used option names.
Key: ELY-1035
URL: https://issues.jboss.org/browse/ELY-1035
Project: WildFly Elytron
Issue Type: Bug
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
When we use more mutually exclusive parameters (add, remove) then we get error message. But this message contains only short version of option names.
"r" instead of "remove"
"a" instead of "add"
{code}
[hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary --salt 12345678 --iteration 230 --remove
The option 'r' was specified but an option from this group has already been selected: 'a'
{code}
*Same for "credential-store" command.*
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[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:
-------------------------------------------------
Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1406562|https://bugzilla.redhat.com/show_bug.cgi?id=1406562] from ASSIGNED to POST
> 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, 1 month
[JBoss JIRA] (WFCORE-2586) JmxControlledStateNotificationsInStaticModuleTestCase intermittently fails on IBM jdk
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2586?page=com.atlassian.jira.plugi... ]
Jan Martiska moved JBEAP-9929 to WFCORE-2586:
---------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2586 (was: JBEAP-9929)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
Affects Version/s: (was: 7.1.0.DR15)
> JmxControlledStateNotificationsInStaticModuleTestCase intermittently fails on IBM jdk
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-2586
> URL: https://issues.jboss.org/browse/WFCORE-2586
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Martiska
> Assignee: Jan Martiska
>
> Some intermittent failures in:
> org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsInStaticModuleTestCase
> org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsTestCase
> can be seen running wildfly-core integration testsuite on IBM jvm.
> see https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-as-testsu... for results of DR15 runs.
> e.g.
> _org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsTestCase.checkNotifications_startReloadStop_
> *Error Details*
> {noformat}
> jmx.attribute.change 2 jboss.root:type=state The attribute 'RuntimeConfigurationState' has changed from 'starting' to 'ok', jmx.attribute.change 13 jboss.root:type=state The attribute 'RuntimeConfigurationState' has changed from 'starting' to 'ok', jmx.attribute.change 16 jboss.root:type=state The attribute 'RuntimeConfigurationState' has changed from 'ok' to 'stopping' expected:<4> but was:<3>
> {noformat}
> *Stack Trace*
> {noformat}
> java.lang.AssertionError: jmx.attribute.change 2 jboss.root:type=state The attribute 'RuntimeConfigurationState' has changed from 'starting' to 'ok', jmx.attribute.change 13 jboss.root:type=state The attribute 'RuntimeConfigurationState' has changed from 'starting' to 'ok', jmx.attribute.change 16 jboss.root:type=state The attribute 'RuntimeConfigurationState' has changed from 'ok' to 'stopping' expected:<4> but was:<3>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsTestCase.lambda$checkFacadeJmxNotifications$0(JmxControlledStateNotificationsTestCase.java:175)
> {noformat}
> *Standard Output snippet*
> {noformat}
> &#27;[0m&#27;[0m14:18:42,096 INFO [org.jboss.as.server] (ServerService Thread Pool -- 7) WFLYSRV0212: Resuming server
> &#27;[0m&#27;[0m14:18:42,232 INFO [org.jboss.as.protocol] (management I/O-1) WFLYPRT0057: cancelled task by interrupting thread Thread[management-handler-thread - 3,5,management-handler-thread]
> &#27;[0m&#27;[31m14:18:42,240 ERROR [org.wildfly.test.jmx.ControlledStateNotificationListener] (management-handler-thread - 3) Problem handling JMX Notification: java.nio.channels.ClosedByInterruptException
> at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:220)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:228)
> at java.nio.channels.Channels.writeFullyImpl(Channels.java:89)
> at java.nio.channels.Channels.writeFully(Channels.java:112)
> at java.nio.channels.Channels.access$000(Channels.java:72)
> at java.nio.channels.Channels$1.write(Channels.java:185)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:303)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:307)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:287)
> at java.io.BufferedWriter.flush(BufferedWriter.java:265)
> at org.wildfly.test.jmx.ControlledStateNotificationListener.writeNotification(ControlledStateNotificationListener.java:84)
> at org.wildfly.test.jmx.ControlledStateNotificationListener.handleNotification(ControlledStateNotificationListener.java:74)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1766)
> at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:286)
> at javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:363)
> at javax.management.NotificationBroadcasterSupport$1.execute(NotificationBroadcasterSupport.java:348)
> at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:259)
> at org.jboss.as.server.jmx.RunningStateJmx.setProcessState(RunningStateJmx.java:112)
> at org.jboss.as.server.jmx.RunningStateJmx.lambda$registerStateListener$0(RunningStateJmx.java:212)
> at org.jboss.as.server.jmx.RunningStateJmx$$Lambda$46.0000000040DD2A40.propertyChange(Unknown Source)
> at java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:346)
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:338)
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:274)
> at org.jboss.as.controller.ControlledProcessStateService.stateChanged(ControlledProcessStateService.java:105)
> at org.jboss.as.controller.ControlledProcessState.setStopping(ControlledProcessState.java:127)
> at org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1.listenerAdded(ProcessReloadHandler.java:82)
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1537)
> at org.jboss.msc.service.ServiceControllerImpl.addListener(ServiceControllerImpl.java:1254)
> at org.jboss.as.controller.OperationContextImpl$OperationContextServiceController.addListener(OperationContextImpl.java:2449)
> at org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1.handleResult(ProcessReloadHandler.java:79)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1493)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1475)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1437)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1410)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1284)
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:856)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:842)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:748)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.jboss.as.controller.ModelControllerImpl$$Lambda$193.00000000E0015CC0.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$194.00000000E00163C0.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$192.00000000E000FE80.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> The tests were introduced just recently as a coverage for EAP7-471.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-7337) Introduce an authorization SPI
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-7337?page=com.atlassian.jira.plugin.... ]
Amos Feng closed WFLY-7337.
---------------------------
Resolution: Won't Do
> Introduce an authorization SPI
> ------------------------------
>
> Key: WFLY-7337
> URL: https://issues.jboss.org/browse/WFLY-7337
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Reporter: David Lloyd
> Assignee: Amos Feng
>
> We need an SPI that can be invoked to authorize state changes in a transaction. The method(s) should make it clear in some way which operation is being authorized, and it must run from the same thread as the thread which instigates the state change.
> It must be possible to register an implementation of the SPI when the container starts up or acquires the transaction manager.
> The operations that should provide authorization checks include, but are not limited to:
> * begin
> * rollback
> * prepare
> * forget
> * commit (one or two phase)
> * recover
> Thanks!
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month