[JBoss JIRA] (WFCORE-2793) Get rid of the "DeploymentScanner Threads" pool
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2793?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2793:
------------------------------------------
*Uses of ServerService.ServerScheduledExecutorService:*
HostControllerConnectionService uses it for a ResponseAttachmentInputStreamSupport.
AbstractModelControllerOperationHandlerFactoryService uses it for a ResponseAttachmentInputStreamSupport
ContentRepositoryCleaner uses it.
*Uses of HostControllerService.HostControllerScheduledExecutorService (the HC analogue):*
RemoteDomainConnectionService uses it for a ResponseAttachmentInputStreamSupport
AbstractModelControllerOperationHandlerFactoryService uses it for a ResponseAttachmentInputStreamSupport
ContentRepositoryCleaner uses it.
So, basically 2 things: cleaning up response attachments, and the content repo cleaner.
> Get rid of the "DeploymentScanner Threads" pool
> -----------------------------------------------
>
> Key: WFCORE-2793
> URL: https://issues.jboss.org/browse/WFCORE-2793
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Look into whether we can consolidate thread usage for scheduled tasks.
> 1) Get rid of the "DeploymentScanner Threads" pool
> The deployment scanner can use the kernel scheduled executor. I'm a bit reluctant in general to allow use of this pool by subsystems as scheduled executors have a fixed size pool, so arbitrary usage by subsystems can result in tying up all the threads doing long running tasks and undesirable behavior. But deployment-scanner is "kernel-ish enough" that I think it's ok.
> This will remove 2 threads.
> The server scheduled executor has 4 threads which is actually pretty high given the very limited usage of it. So I'll consider narrowing it down.
> The big problem with using the server scheduled executor is tying up its threads long running tasks, which the scanner does do. What i'll probably do is just use the scheduled executor to trigger a task which then submits a task on the main ServerService thread pool (which is unlimited in size.)
> Perhaps I'll abstract this kind of usage pattern into a service, and make that service a generally available kernel capability.
> 2) Get rid of the "ServerDeploymentRepository-temp-threads" pool
> This one is used by DeploymentMountProvider to do file cleanup. Similar discussion applies.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2786) Improve the composition operation output
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2786?page=com.atlassian.jira.plugi... ]
Filippe Spolti edited comment on WFCORE-2786 at 5/10/17 2:28 PM:
-----------------------------------------------------------------
I did a little modification and got this result:
{code:title=Request}
{
"address": [],
"json.pretty": 1,
"operation": "composite",
"rename-steps": "true",
"steps": [
{
"name": "server-state",
"operation": "read-attribute"
},
{
"address": {
"deployment": "*"
},
"name": "deployment-status",
"operation": "read-attribute"
},
{
"address": {
"core-service": "management"
},
"name": "read-boot-errors",
"operation": "read-boot-errors"
}
]
}
{code}
{code:title=response}
{
"outcome": "success",
"result": {
"deployment-status": {
"outcome": "success",
"result": []
},
"read-boot-errors": {
"outcome": "success",
"result": []
},
"server-state": {
"outcome": "success",
"result": "running"
}
}
}
{code}
In this case the user can add a parameter in the request "rename-steps" to true, if false or its absence the step-N will be used.
Also, user must define the operation name, like:
{code}
{
"address": {
"deployment": "*"
},
"name": "deployment-info",
"operation": "read-attribute"
}
{code}
If no name is set, step-N will be used.
was (Author: filippe.spolti):
I did a little modification and got this result:
{code:title=Request}
{
"address": [],
"json.pretty": 1,
"operation": "composite",
"rename-steps": "true",
"steps": [
{
"name": "server-state",
"operation": "read-attribute"
},
{
"address": {
"deployment": "*"
},
"name": "deployment-status",
"operation": "read-attribute"
},
{
"address": {
"core-service": "management"
},
"name": "read-boot-errors",
"operation": "read-boot-errors"
}
]
}
{code}
{code:title=response}
{
"outcome": "success",
"result": {
"deployment-status": {
"outcome": "success",
"result": []
},
"read-boot-errors": {
"outcome": "success",
"result": []
},
"server-state": {
"outcome": "success",
"result": "running"
}
}
}
{code}
In this case the user can add a parameter in the request "rename-steps" to true, if false or its absence the step-N will be used.
Also, user must define the operation name, like:
{code}
{
"address": {
"deployment": "*"
},
"name": "deployment-info",
"operation": "read-attribute"
}
{code}
> Improve the composition operation output
> ----------------------------------------
>
> Key: WFCORE-2786
> URL: https://issues.jboss.org/browse/WFCORE-2786
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Filippe Spolti
>
> When you perform a composite operations with many commands the output will be enumerated in steps, like: step-1, step-2, ..., step-N.
> I am not sure, but looks like the step-X correspond to the order of the commands sent in the request payload, example:
> {code:title=Payload}
> {
> "address": [],
> "json.pretty": 1,
> "operation": "composite",
> "steps": [
> {
> "name": "server-state",
> "operation": "read-attribute"
> },
> {
> "address": {
> "deployment": "*"
> },
> "name": "status",
> "operation": "read-attribute"
> }
> ]
> }
> {code}
> {code:title=Response}
> {
> "outcome": "success",
> "result": {
> "step-1": {
> "outcome": "success",
> "result": "running"
> },
> "step-2": {
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
> If you have something the dynamically builds the composite payload, it is very hard to identify the output corresponding to each command in the payload.
> It will be great if we can add a extra field in the response or change the steps name to its operation name, for example:
> {code}
> {
> "outcome": "success",
> "result": {
> "step-1": {
> "operation-name": "server-state",
> "outcome": "success",
> "result": "running"
> },
> "step-2": {
> "operation-name": "deployment-info",
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
> Or
> {code}
> {
> "outcome": "success",
> "result": {
> "server-state": {
> "outcome": "success",
> "result": "running"
> },
> "deployment-info": {
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2786) Improve the composition operation output
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2786?page=com.atlassian.jira.plugi... ]
Filippe Spolti updated WFCORE-2786:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2414
> Improve the composition operation output
> ----------------------------------------
>
> Key: WFCORE-2786
> URL: https://issues.jboss.org/browse/WFCORE-2786
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Filippe Spolti
>
> When you perform a composite operations with many commands the output will be enumerated in steps, like: step-1, step-2, ..., step-N.
> I am not sure, but looks like the step-X correspond to the order of the commands sent in the request payload, example:
> {code:title=Payload}
> {
> "address": [],
> "json.pretty": 1,
> "operation": "composite",
> "steps": [
> {
> "name": "server-state",
> "operation": "read-attribute"
> },
> {
> "address": {
> "deployment": "*"
> },
> "name": "status",
> "operation": "read-attribute"
> }
> ]
> }
> {code}
> {code:title=Response}
> {
> "outcome": "success",
> "result": {
> "step-1": {
> "outcome": "success",
> "result": "running"
> },
> "step-2": {
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
> If you have something the dynamically builds the composite payload, it is very hard to identify the output corresponding to each command in the payload.
> It will be great if we can add a extra field in the response or change the steps name to its operation name, for example:
> {code}
> {
> "outcome": "success",
> "result": {
> "step-1": {
> "operation-name": "server-state",
> "outcome": "success",
> "result": "running"
> },
> "step-2": {
> "operation-name": "deployment-info",
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
> Or
> {code}
> {
> "outcome": "success",
> "result": {
> "server-state": {
> "outcome": "success",
> "result": "running"
> },
> "deployment-info": {
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2786) Improve the composition operation output
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2786?page=com.atlassian.jira.plugi... ]
Filippe Spolti edited comment on WFCORE-2786 at 5/10/17 2:16 PM:
-----------------------------------------------------------------
I did a little modification and got this result:
{code:title=Request}
{
"address": [],
"json.pretty": 1,
"operation": "composite",
"rename-steps": "true",
"steps": [
{
"name": "server-state",
"operation": "read-attribute"
},
{
"address": {
"deployment": "*"
},
"name": "deployment-status",
"operation": "read-attribute"
},
{
"address": {
"core-service": "management"
},
"name": "read-boot-errors",
"operation": "read-boot-errors"
}
]
}
{code}
{code:title=response}
{
"outcome": "success",
"result": {
"deployment-status": {
"outcome": "success",
"result": []
},
"read-boot-errors": {
"outcome": "success",
"result": []
},
"server-state": {
"outcome": "success",
"result": "running"
}
}
}
{code}
In this case the user can add a parameter in the request "rename-steps" to true, if false or its absence the step-N will be used.
Also, user must define the operation name, like:
{code}
{
"address": {
"deployment": "*"
},
"name": "deployment-info",
"operation": "read-attribute"
}
{code}
was (Author: filippe.spolti):
I did a little modification and got this result:
{code:title=Request}
{
"address": [],
"json.pretty": 1,
"operation": "composite",
"rename-steps": "true",
"steps": [
{
"name": "server-state",
"operation": "read-attribute"
},
{
"address": {
"deployment": "*"
},
"name": "deployment-status",
"operation": "read-attribute"
},
{
"address": {
"core-service": "management"
},
"name": "read-boot-errors",
"operation": "read-boot-errors"
}
]
}
{code}
{code:title=response}:
{
"outcome": "success",
"result": {
"deployment-status": {
"outcome": "success",
"result": []
},
"read-boot-errors": {
"outcome": "success",
"result": []
},
"server-state": {
"outcome": "success",
"result": "running"
}
}
}
{code}
In this case the user can add a parameter in the request "rename-steps" to true, if false or its absence the step-N will be used.
Also, user must define the operation name, like:
{code}
{
"address": {
"deployment": "*"
},
"name": "deployment-info",
"operation": "read-attribute"
}
{code}
> Improve the composition operation output
> ----------------------------------------
>
> Key: WFCORE-2786
> URL: https://issues.jboss.org/browse/WFCORE-2786
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Filippe Spolti
>
> When you perform a composite operations with many commands the output will be enumerated in steps, like: step-1, step-2, ..., step-N.
> I am not sure, but looks like the step-X correspond to the order of the commands sent in the request payload, example:
> {code:title=Payload}
> {
> "address": [],
> "json.pretty": 1,
> "operation": "composite",
> "steps": [
> {
> "name": "server-state",
> "operation": "read-attribute"
> },
> {
> "address": {
> "deployment": "*"
> },
> "name": "status",
> "operation": "read-attribute"
> }
> ]
> }
> {code}
> {code:title=Response}
> {
> "outcome": "success",
> "result": {
> "step-1": {
> "outcome": "success",
> "result": "running"
> },
> "step-2": {
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
> If you have something the dynamically builds the composite payload, it is very hard to identify the output corresponding to each command in the payload.
> It will be great if we can add a extra field in the response or change the steps name to its operation name, for example:
> {code}
> {
> "outcome": "success",
> "result": {
> "step-1": {
> "operation-name": "server-state",
> "outcome": "success",
> "result": "running"
> },
> "step-2": {
> "operation-name": "deployment-info",
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
> Or
> {code}
> {
> "outcome": "success",
> "result": {
> "server-state": {
> "outcome": "success",
> "result": "running"
> },
> "deployment-info": {
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2786) Improve the composition operation output
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2786?page=com.atlassian.jira.plugi... ]
Filippe Spolti commented on WFCORE-2786:
----------------------------------------
I did a little modification and got this result:
{code:title=Request}
{
"address": [],
"json.pretty": 1,
"operation": "composite",
"rename-steps": "true",
"steps": [
{
"name": "server-state",
"operation": "read-attribute"
},
{
"address": {
"deployment": "*"
},
"name": "deployment-status",
"operation": "read-attribute"
},
{
"address": {
"core-service": "management"
},
"name": "read-boot-errors",
"operation": "read-boot-errors"
}
]
}
{code}
{code:title=response}:
{
"outcome": "success",
"result": {
"deployment-status": {
"outcome": "success",
"result": []
},
"read-boot-errors": {
"outcome": "success",
"result": []
},
"server-state": {
"outcome": "success",
"result": "running"
}
}
}
{code}
In this case the user can add a parameter in the request "rename-steps" to true, if false or its absence the step-N will be used.
Also, user must define the operation name, like:
{code}
{
"address": {
"deployment": "*"
},
"name": "deployment-info",
"operation": "read-attribute"
}
{code}
> Improve the composition operation output
> ----------------------------------------
>
> Key: WFCORE-2786
> URL: https://issues.jboss.org/browse/WFCORE-2786
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Filippe Spolti
>
> When you perform a composite operations with many commands the output will be enumerated in steps, like: step-1, step-2, ..., step-N.
> I am not sure, but looks like the step-X correspond to the order of the commands sent in the request payload, example:
> {code:title=Payload}
> {
> "address": [],
> "json.pretty": 1,
> "operation": "composite",
> "steps": [
> {
> "name": "server-state",
> "operation": "read-attribute"
> },
> {
> "address": {
> "deployment": "*"
> },
> "name": "status",
> "operation": "read-attribute"
> }
> ]
> }
> {code}
> {code:title=Response}
> {
> "outcome": "success",
> "result": {
> "step-1": {
> "outcome": "success",
> "result": "running"
> },
> "step-2": {
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
> If you have something the dynamically builds the composite payload, it is very hard to identify the output corresponding to each command in the payload.
> It will be great if we can add a extra field in the response or change the steps name to its operation name, for example:
> {code}
> {
> "outcome": "success",
> "result": {
> "step-1": {
> "operation-name": "server-state",
> "outcome": "success",
> "result": "running"
> },
> "step-2": {
> "operation-name": "deployment-info",
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
> Or
> {code}
> {
> "outcome": "success",
> "result": {
> "server-state": {
> "outcome": "success",
> "result": "running"
> },
> "deployment-info": {
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2793) Get rid of the "DeploymentScanner Threads" pool
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2793?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2793:
------------------------------------------
An important thing to consider is the lifecycle of the pool and what happens to scheduled tasks when the pool is stopped.
The ServerService.ServerScheduledExecutorService uses non-daemon threads. The service stop does a simple shutdown(), with no blocking for completion. The pool has setExecuteExistingDelayedTasksAfterShutdownPolicy(false) set so following the shutdown call any tasks not started will be discarded. But tasks that are in progress will continue. Since the threads are non-daemon they should keep the vm alive until completed.
ServerDeploymentRepository-temp-threads uses daemon threads. The service stop does a simple shutdown(), with no blocking for completion. The pool *does not* have setExecuteExistingDelayedTasksAfterShutdownPolicy(false) set so following the shutdown call any tasks not started will still be executed. But the fact the threads are daemon threads means the VM will exit despite tasks being queued or in progress.
The deployment-scanner uses non-daemon threads. The service stop does a simple shutdown(), with no blocking for completion. The pool *does not* have setExecuteExistingDelayedTasksAfterShutdownPolicy(false) set so following the shutdown call any tasks not started will still be executed. Since the threads are non-daemon they should keep the vm alive until completed.
> Get rid of the "DeploymentScanner Threads" pool
> -----------------------------------------------
>
> Key: WFCORE-2793
> URL: https://issues.jboss.org/browse/WFCORE-2793
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Look into whether we can consolidate thread usage for scheduled tasks.
> 1) Get rid of the "DeploymentScanner Threads" pool
> The deployment scanner can use the kernel scheduled executor. I'm a bit reluctant in general to allow use of this pool by subsystems as scheduled executors have a fixed size pool, so arbitrary usage by subsystems can result in tying up all the threads doing long running tasks and undesirable behavior. But deployment-scanner is "kernel-ish enough" that I think it's ok.
> This will remove 2 threads.
> The server scheduled executor has 4 threads which is actually pretty high given the very limited usage of it. So I'll consider narrowing it down.
> The big problem with using the server scheduled executor is tying up its threads long running tasks, which the scanner does do. What i'll probably do is just use the scheduled executor to trigger a task which then submits a task on the main ServerService thread pool (which is unlimited in size.)
> Perhaps I'll abstract this kind of usage pattern into a service, and make that service a generally available kernel capability.
> 2) Get rid of the "ServerDeploymentRepository-temp-threads" pool
> This one is used by DeploymentMountProvider to do file cleanup. Similar discussion applies.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2793) Get rid of the "DeploymentScanner Threads" pool
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2793?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2793:
-------------------------------------
Description:
Look into whether we can consolidate thread usage for scheduled tasks.
1) Get rid of the "DeploymentScanner Threads" pool
The deployment scanner can use the kernel scheduled executor. I'm a bit reluctant in general to allow use of this pool by subsystems as scheduled executors have a fixed size pool, so arbitrary usage by subsystems can result in tying up all the threads doing long running tasks and undesirable behavior. But deployment-scanner is "kernel-ish enough" that I think it's ok.
This will remove 2 threads.
The server scheduled executor has 4 threads which is actually pretty high given the very limited usage of it. So I'll consider narrowing it down.
The big problem with using the server scheduled executor is tying up its threads long running tasks, which the scanner does do. What i'll probably do is just use the scheduled executor to trigger a task which then submits a task on the main ServerService thread pool (which is unlimited in size.)
Perhaps I'll abstract this kind of usage pattern into a service, and make that service a generally available kernel capability.
2) Get rid of the "ServerDeploymentRepository-temp-threads" pool
This one is used by DeploymentMountProvider to do file cleanup. Similar discussion applies.
was:
The deployment scanner can use the kernel scheduled executor. I'm a bit reluctant in general to allow use of this pool by subsystems as scheduled executors have a fixed size pool, so arbitrary usage by subsystems can result in tying up all the threads doing long running tasks and undesirable behavior. But deployment-scanner is "kernel-ish enough" that I think it's ok.
This will remove 2 threads.
The server scheduled executor has 4 threads which is actually pretty high given the very limited usage of it. So I'll consider narrowing it down.
The big problem with using the server scheduled executor is tying up its threads long running tasks, which the scanner does do. What i'll probably do is just use the scheduled executor to trigger a task which then submits a task on the main ServerService thread pool (which is unlimited in size.)
Perhaps I'll abstract this kind of usage pattern into a service, and make that service a generally available kernel capability.
> Get rid of the "DeploymentScanner Threads" pool
> -----------------------------------------------
>
> Key: WFCORE-2793
> URL: https://issues.jboss.org/browse/WFCORE-2793
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Look into whether we can consolidate thread usage for scheduled tasks.
> 1) Get rid of the "DeploymentScanner Threads" pool
> The deployment scanner can use the kernel scheduled executor. I'm a bit reluctant in general to allow use of this pool by subsystems as scheduled executors have a fixed size pool, so arbitrary usage by subsystems can result in tying up all the threads doing long running tasks and undesirable behavior. But deployment-scanner is "kernel-ish enough" that I think it's ok.
> This will remove 2 threads.
> The server scheduled executor has 4 threads which is actually pretty high given the very limited usage of it. So I'll consider narrowing it down.
> The big problem with using the server scheduled executor is tying up its threads long running tasks, which the scanner does do. What i'll probably do is just use the scheduled executor to trigger a task which then submits a task on the main ServerService thread pool (which is unlimited in size.)
> Perhaps I'll abstract this kind of usage pattern into a service, and make that service a generally available kernel capability.
> 2) Get rid of the "ServerDeploymentRepository-temp-threads" pool
> This one is used by DeploymentMountProvider to do file cleanup. Similar discussion applies.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2793) Get rid of the "DeploymentScanner Threads" pool
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2793:
----------------------------------------
Summary: Get rid of the "DeploymentScanner Threads" pool
Key: WFCORE-2793
URL: https://issues.jboss.org/browse/WFCORE-2793
Project: WildFly Core
Issue Type: Bug
Components: Deployment Scanner, Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The deployment scanner can use the kernel scheduled executor. I'm a bit reluctant in general to allow use of this pool by subsystems as scheduled executors have a fixed size pool, so arbitrary usage by subsystems can result in tying up all the threads doing long running tasks and undesirable behavior. But deployment-scanner is "kernel-ish enough" that I think it's ok.
This will remove 2 threads.
The server scheduled executor has 4 threads which is actually pretty high given the very limited usage of it. So I'll consider narrowing it down.
The big problem with using the server scheduled executor is tying up its threads long running tasks, which the scanner does do. What i'll probably do is just use the scheduled executor to trigger a task which then submits a task on the main ServerService thread pool (which is unlimited in size.)
Perhaps I'll abstract this kind of usage pattern into a service, and make that service a generally available kernel capability.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1125) WildFly Elytron Tool, Omitting --location for Vault command leads to wrong credential store storage file in tool output and in summary output.
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1125?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev commented on ELY-1125:
------------------------------------
[~hsvabek]
Expected behaviour:
Tool output must show only storage file name.
Note: I think that this is not correct. The "location" option can also contains path + file name, not only file name. When "location" is not provided, the tool creates the file in "enc-dir" which should be displayed.
Summary output must not contain double slash in location
Note: This is a bug.
> WildFly Elytron Tool, Omitting --location for Vault command leads to wrong credential store storage file in tool output and in summary output.
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1125
> URL: https://issues.jboss.org/browse/ELY-1125
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> Omitting --location for Vault command leads to wrong credential store storage file in tool output and in summary output.
> In this case when is omitted --location
> * tool output contains credential store storage file name with "enc-dir" path prefix.
> * summary output contains in location double slash in case of enc-dir value ends by slash
> *Expected behaviour:*
> Tool output must show only storage file name.
> Summary output must not contain double slash in location
> *How to reproduce*
> Download all attachments to same location as wildfly-elytron-tool.jar
> option --location must be omitted, --enc-dir must end by slash.
> {code}
> [hsvabek@dhcp-10-40-5-100 003]$ java -jar wildfly-elytron-tool.jar vault --enc-dir ./ --keystore server.store --keystore-password secretsecret --alias jboss -f
> Vault (enc-dir="./";keystore="server.store") converted to credential store ".//converted-vault.cr-store"
> Vault Conversion summary:
> --------------------------------------
> Vault Conversion Successful
> CLI command to add new credential store:
> /subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location=".//converted-vault.cr-store",implementation-properties={},credential-reference={clear-text="MASK-13KrO2ZNhwNg3UxmIt.02D;12345678;23"})
> {code}
> Now you can see *".//converted-vault.cr-store"* on tool output right value is *"converted-vault.cr-store"*
> and location=*".//converted-vault.cr-store"* in summary output for which is correct value *"./converted-vault.cr-store"*.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months