[JBoss JIRA] (WFLY-5131) Kerberos authentication for remoting EJB without interaction does not fallback correctly
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5131?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-5131.
------------------------------------
Resolution: Rejected
As described in my last commend this behaviour needs to be defined in a custom jaas configuration, here is the example working in my local environment: -
{noformat}
com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=true
doNotPrompt=true;
};
{noformat}
Within the CLI we have been able to handle this automatically - however for EJB clients we are not running without our own process so we can not insert JAAS configuration in the same way.
> Kerberos authentication for remoting EJB without interaction does not fallback correctly
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-5131
> URL: https://issues.jboss.org/browse/WFLY-5131
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Affects Versions: 10.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case when kerberos authentication with properties fallback is correctly configured in security realm and user without correct kerberos ticket tries to invoke EJB via EJB client, then EJB client asks for kerberos username in interactive mode. It works correctly when user interacts with this mode but it causes inconvenience for access without user interaction. Fallback cannot be taken into account because EJB invocation stucks in interactive mode which leads to RuntimeException: Operation failed with status WAITING. There should be any possibility how to disable interactive mode for users which invoke EJB without kerberos.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-4814) DirectoryNotEmptyException on undeploy of ear
by Cody Lerum (JIRA)
[ https://issues.jboss.org/browse/WFLY-4814?page=com.atlassian.jira.plugin.... ]
Cody Lerum commented on WFLY-4814:
----------------------------------
Same on Wildfly 9.0.1.Final in domain mode.
{code}
[Server:server-one] 17:23:57,360 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment cfax.war (runtime-name: cfax.war) in 288ms
[Server:server-one] 17:24:00,434 ERROR [org.jboss.as.repository] (ServerService Thread Pool -- 72) WFLYDR0010: Couldn't delete content /usr/local/wildfly/domain/servers/server-one/data/content/64: java.nio.fil e.DirectoryNotEmptyException: /usr/local/wildfly/domain/servers/server-one/data/content/64
[Server:server-one] at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
[Server:server-one] at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
[Server:server-one] at java.nio.file.Files.deleteIfExists(Files.java:1165)
[Server:server-one] at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:370)
[Server:server-one] at org.jboss.as.server.mgmt.domain.RemoteFileRepositoryService.removeContent(RemoteFileRepositoryService.java:115)
[Server:server-one] at org.jboss.as.server.deployment.DeploymentRemoveHandler$1$1.handleResult(DeploymentRemoveHandler.java:118)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1401)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1381)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1332)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1292)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1180)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:937)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:885)
[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:218)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:174)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:137)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:133)
[Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
[Server:server-one] at javax.security.auth.Subject.doAs(Subject.java:360)
[Server:server-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:149)
[Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:149)
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298)
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[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] 17:24:00,440 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 72) WFLYDR0002: Content removed from location /usr/local/wildfly/domain/servers/server-one/data/content/64/ed4ac67
{code}
> DirectoryNotEmptyException on undeploy of ear
> ---------------------------------------------
>
> Key: WFLY-4814
> URL: https://issues.jboss.org/browse/WFLY-4814
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Alpha4
> Environment: Oracle Solaris SPARC 10, Oracle JDK 1.8.0_45.
> Reporter: Frank Langelage
> Assignee: Jason Greene
>
> When undeploying my ear by removing the ear file from the standalone/deployments folder I sometimes see this exception at the end:
> 21.06. 16:49:25,674 INFO [org.jboss.as.server.deployment#stop] WFLYSRV0028: Stopped deployment maj2e-langfr-dev.ear (runtime-name: maj2e-langfr-dev.ear) in 3072ms
> 21.06. 16:49:26,034 ERROR [org.jboss.as.repository#removeContent] WFLYDR0010: Couldn't delete content /mbi/tools/jboss/10.0/standalone/data/content/30: java.nio.file.DirectoryNotEmptyException: /mbi/tools/jboss/10.0/standalone/data/content/30
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
> at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> at java.nio.file.Files.deleteIfExists(Files.java:1165)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:370)
> at org.jboss.as.server.deployment.DeploymentRemoveHandler$1$1.handleResult(DeploymentRemoveHandler.java:118)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1420)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1400)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1351)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1199)
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:956)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:904)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:620)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:373)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:349)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1201)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:747)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:741)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.controller.ModelControllerImpl$3$1.run(ModelControllerImpl.java:741)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 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)
> 21.06. 16:49:26,174 INFO [org.jboss.as.repository#removeContent] WFLYDR0002: Content removed from location /mbi/tools/jboss/10.0/standalone/data/content/30/4fee5b5fa782d2a7f04723ccab3e12351d600b/content
> 21.06. 16:49:26,176 INFO [org.jboss.as.server#handleResult] WFLYSRV0009: Undeployed "maj2e-langfr-dev.ear" (runtime-name: "maj2e-langfr-dev.ear")
> The exception seems to be ignored. But the named folder and
> a file /mbi/tools/jboss/10.0/standalone/data/content/30/7cb1f70d08fb375010369eea154c5db479eaba/content are still there.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5131) Kerberos authentication for remoting EJB without interaction does not fallback correctly
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5131?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-5131:
----------------------------------------
Reviewing this would need more information to reproduce the actual scenario you are seeing. However this is most likely something that can be solved with a custom JAAS configuration.
The following Java example shows how a custom JAAS configuration can be used on the client side, the Kerberos login module can then be configured to disable prompting for a username and password: -
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tuto...
> Kerberos authentication for remoting EJB without interaction does not fallback correctly
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-5131
> URL: https://issues.jboss.org/browse/WFLY-5131
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Affects Versions: 10.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case when kerberos authentication with properties fallback is correctly configured in security realm and user without correct kerberos ticket tries to invoke EJB via EJB client, then EJB client asks for kerberos username in interactive mode. It works correctly when user interacts with this mode but it causes inconvenience for access without user interaction. Fallback cannot be taken into account because EJB invocation stucks in interactive mode which leads to RuntimeException: Operation failed with status WAITING. There should be any possibility how to disable interactive mode for users which invoke EJB without kerberos.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5079) Removing non existent mail server with standard name (via CLI) doesn't fail even though it should
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5079?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-5079:
------------------------------
Comment: was deleted
(was: Subsystem works as expected, but by default services don't get restarted unless you tell server they should be.
to make long story short. you need to provide extra header(allow-resource-service-restart=true) to cli command that tells server services can be restarted.
you need to use special syntax for header which is:
{noformat}{allow-resource-service-restart=true} {noformat}
so your last command should look like:
{noformat}
/subsystem=mail/mail-session=Mail/server=smtp:add(outbound-socket-binding-ref=mail-smtp2,ssl=false,username="...",password="..."){allow-resource-service-restart=true}
{noformat}
other option is to start server in admin mode and add all configuration to it, than run reload to runtime (default mode))
> Removing non existent mail server with standard name (via CLI) doesn't fail even though it should
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-5079
> URL: https://issues.jboss.org/browse/WFLY-5079
> Project: WildFly
> Issue Type: Bug
> Components: Mail
> Affects Versions: 10.0.0.Beta1
> Reporter: Radim Hatlapatka
> Assignee: Tomaz Cerar
> Fix For: 10.0.0.Final
>
>
> Removing non-existent mail server (which is named smtp or pop3 or imap) via CLI operation doesn't fail even though it should.
> {noformat}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651:add(jndi-name=java\:jboss\/mail\/test1439373303651)
> {"outcome" => "success"}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651:read-children-names(child-type=server)
> {
> "outcome" => "success",
> "result" => []
> }
> [standalone@localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651/server=smtp:remove
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
> Note: trying to remove non-existent server named e.g. {{xxx}} correctly fails see
> {noformat}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651/server=xxx:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0030: No resource definition is registered for address [
> (\"subsystem\" => \"mail\"),
> (\"mail-session\" => \"java:jboss/mail/test1439373303651\"),
> (\"server\" => \"xxx\")
> ]",
> "rolled-back" => true,
> "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5079) Removing non existent mail server with standard name (via CLI) doesn't fail even though it should
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5079?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-5079:
------------------------------
Fix Version/s: 10.0.0.Final
> Removing non existent mail server with standard name (via CLI) doesn't fail even though it should
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-5079
> URL: https://issues.jboss.org/browse/WFLY-5079
> Project: WildFly
> Issue Type: Bug
> Components: Mail
> Affects Versions: 10.0.0.Beta1
> Reporter: Radim Hatlapatka
> Assignee: Tomaz Cerar
> Fix For: 10.0.0.Final
>
>
> Removing non-existent mail server (which is named smtp or pop3 or imap) via CLI operation doesn't fail even though it should.
> {noformat}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651:add(jndi-name=java\:jboss\/mail\/test1439373303651)
> {"outcome" => "success"}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651:read-children-names(child-type=server)
> {
> "outcome" => "success",
> "result" => []
> }
> [standalone@localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651/server=smtp:remove
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
> Note: trying to remove non-existent server named e.g. {{xxx}} correctly fails see
> {noformat}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651/server=xxx:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0030: No resource definition is registered for address [
> (\"subsystem\" => \"mail\"),
> (\"mail-session\" => \"java:jboss/mail/test1439373303651\"),
> (\"server\" => \"xxx\")
> ]",
> "rolled-back" => true,
> "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5079) Removing non existent mail server with standard name (via CLI) doesn't fail even though it should
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5079?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reopened WFLY-5079:
-------------------------------
> Removing non existent mail server with standard name (via CLI) doesn't fail even though it should
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-5079
> URL: https://issues.jboss.org/browse/WFLY-5079
> Project: WildFly
> Issue Type: Bug
> Components: Mail
> Affects Versions: 10.0.0.Beta1
> Reporter: Radim Hatlapatka
> Assignee: Tomaz Cerar
>
> Removing non-existent mail server (which is named smtp or pop3 or imap) via CLI operation doesn't fail even though it should.
> {noformat}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651:add(jndi-name=java\:jboss\/mail\/test1439373303651)
> {"outcome" => "success"}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651:read-children-names(child-type=server)
> {
> "outcome" => "success",
> "result" => []
> }
> [standalone@localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651/server=smtp:remove
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
> Note: trying to remove non-existent server named e.g. {{xxx}} correctly fails see
> {noformat}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651/server=xxx:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0030: No resource definition is registered for address [
> (\"subsystem\" => \"mail\"),
> (\"mail-session\" => \"java:jboss/mail/test1439373303651\"),
> (\"server\" => \"xxx\")
> ]",
> "rolled-back" => true,
> "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-3498) "reload-required" set when adding mail-session via jboss-cli
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3498?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-3498.
-----------------------------
Resolution: Rejected
Subsystem works as expected, but by default services don't get restarted unless you tell server they should be.
to make long story short. you need to provide extra header(allow-resource-service-restart=true) to cli command that tells server services can be restarted.
you need to use special syntax for header which is:
{noformat}{allow-resource-service-restart=true} {noformat}
so your last command should look like:
{noformat}
/subsystem=mail/mail-session=Mail/server=smtp:add(outbound-socket-binding-ref=mail-smtp2,ssl=false,username="...",password="..."){allow-resource-service-restart=true}
{noformat}
other option is to start server in admin mode and add all configuration to it, than run reload to runtime (default mode)
> "reload-required" set when adding mail-session via jboss-cli
> ------------------------------------------------------------
>
> Key: WFLY-3498
> URL: https://issues.jboss.org/browse/WFLY-3498
> Project: WildFly
> Issue Type: Bug
> Components: Mail
> Affects Versions: 8.1.0.Final, 9.0.0.Alpha1
> Reporter: Frank Langelage
> Assignee: Tomaz Cerar
>
> When adding a mail-session using jboss-cli the server state changes to "reload-required" although the configured Mail is usable without reload.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5079) Removing non existent mail server with standard name (via CLI) doesn't fail even though it should
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5079?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-5079.
-----------------------------
Resolution: Rejected
Subsystem works as expected, but by default services don't get restarted unless you tell server they should be.
to make long story short. you need to provide extra header(allow-resource-service-restart=true) to cli command that tells server services can be restarted.
you need to use special syntax for header which is:
{noformat}{allow-resource-service-restart=true} {noformat}
so your last command should look like:
{noformat}
/subsystem=mail/mail-session=Mail/server=smtp:add(outbound-socket-binding-ref=mail-smtp2,ssl=false,username="...",password="..."){allow-resource-service-restart=true}
{noformat}
other option is to start server in admin mode and add all configuration to it, than run reload to runtime (default mode)
> Removing non existent mail server with standard name (via CLI) doesn't fail even though it should
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-5079
> URL: https://issues.jboss.org/browse/WFLY-5079
> Project: WildFly
> Issue Type: Bug
> Components: Mail
> Affects Versions: 10.0.0.Beta1
> Reporter: Radim Hatlapatka
> Assignee: Tomaz Cerar
>
> Removing non-existent mail server (which is named smtp or pop3 or imap) via CLI operation doesn't fail even though it should.
> {noformat}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651:add(jndi-name=java\:jboss\/mail\/test1439373303651)
> {"outcome" => "success"}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651:read-children-names(child-type=server)
> {
> "outcome" => "success",
> "result" => []
> }
> [standalone@localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651/server=smtp:remove
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
> Note: trying to remove non-existent server named e.g. {{xxx}} correctly fails see
> {noformat}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651/server=xxx:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0030: No resource definition is registered for address [
> (\"subsystem\" => \"mail\"),
> (\"mail-session\" => \"java:jboss/mail/test1439373303651\"),
> (\"server\" => \"xxx\")
> ]",
> "rolled-back" => true,
> "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months