[JBoss JIRA] (WFCORE-488) Failures of undeploy of a partially failed deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-488?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-488:
-----------------------------------------
Answering one of my own questions...
> In what process did the "throw ControllerMessages.MESSAGES.managementResourceNotFound(missing)" occur?
It had to have been on a server, as that is the only place DeploymentUndeployHandler is registered.
> Failures of undeploy of a partially failed deployment
> -----------------------------------------------------
>
> Key: WFCORE-488
> URL: https://issues.jboss.org/browse/WFCORE-488
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
>
> {noformat}
> [domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups
> Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers.
> {noformat}
> There are several issues at play here:
> # Insufficient information is displayed along with JBAS010839
> # No actual failure logged either in DC or in individual host's logs
> # Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler
> I'll start in a reverse order of causation:
> In DeploymentUndeployHandler.execute
> {noformat}
> public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
> ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel();
> ...
> {noformat}
> OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild:
> {noformat}
> private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) {
> if (resource.hasChild(childPath)) {
> return resource.requireChild(childPath);
> } else {
> PathAddress missing = PathAddress.EMPTY_ADDRESS;
> for (PathElement search : fullAddress) {
> missing = missing.append(search);
> if (search.equals(childPath)) {
> break;
> }
> }
> throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);
> }
> }
> {noformat}
> The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}:
> # does not propagate from the host to DC and to CLI
> # is not logged with any level (not even TRACE) either on host or DC
> # should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months
[JBoss JIRA] (WFLY-4081) Do not force that the exploded directory ends with ".war"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4081?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-4081.
------------------------------------
Assignee: Brian Stansberry (was: Jason Greene)
Resolution: Won't Fix
I'm resolving this as "Won't Fix" as we already provide behavior to satisfy the use case, and it appears this is primarily an issue with Intellij. They commented on the Intellij bug tracker that they intend to fix the problem.
> Do not force that the exploded directory ends with ".war"
> ---------------------------------------------------------
>
> Key: WFLY-4081
> URL: https://issues.jboss.org/browse/WFLY-4081
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Geoffrey De Smet
> Assignee: Brian Stansberry
>
> In a standard webapp, maven creates the following directory and file:
> // Exploded directory
> target/mywebapp-1.0/
> // War file
> target/mywebapp-1.0.war
> *Unfortunately, WildFly forces that exploded directories should have the suffix ".war"*. At least the IntelliJ JBoss app server plugin enforces this, if that's no longer the case, they should fix it asap. This has 2 side effects:
> 1) Every noob fails to deploy an exploded dir to WildFly in IntelliJ. By the time they realize that it's because they haven't adjusted the exploded artifact's output path, they're already using Jetty or Tomcat (which "just work" in IntelliJ).
> 2) As a result, maven and IntelliJ are potentially incompatible for WildFly:
> If you just suffix the exploded directory with ".war", the exploded directory clashes with maven's war file.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months
[JBoss JIRA] (WFLY-4081) Do not force that the exploded directory ends with ".war"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4081?page=com.atlassian.jira.plugin.... ]
Brian Stansberry edited comment on WFLY-4081 at 12/23/14 7:15 PM:
------------------------------------------------------------------
Low-level CLI syntax for the above high-level command:
{code}
[standalone@localhost:9990 /] /deployment=hello:add(runtime-name=helloworld.war,enabled=true,content=[{path=/home/me/tmp/hello,archive=false}])
{"outcome" => "success"}
{code}
The CLI echo-dmr command translates that into DMR text format, so a custom client like a plugin that uses a ModelControllerClient would construct an operation ModelNode like this output from the echo-dmr command:
{code}
[standalone@localhost:9990 /] echo-dmr /deployment=hello:add(runtime-name=helloworld.war,enabled=true,content=[{path=/home/me/tmp/hello,archive=false}])
{
"address" => [("deployment" => "hello")],
"operation" => "add",
"content" => [{
"path" => "/home/me/tmp/hello",
"archive" => "false"
}],
"runtime-name" => "helloworld.war",
"enabled" => true
}
{code}
was (Author: brian.stansberry):
Low-level CLI syntax for the above high-level command:
{code}
[standalone@localhost:9990 /] /deployment=hello:add(runtime-name=helloworld.war,enabled=true,content=[{path=/home/me/tmp/hello,archive=false}])
{"outcome" => "success"}
{code}
The CLI echo-dmr command translates that into DMR text format, so a custom client like a plugin that uses a ModelControllerClient would construct an operation ModelNode like this output from the echo-dmr command:
{code}
[standalone@localhost:9990 /] echo-dmr /deployment=hello:add(runtime-name=helloworld.war,enabled=true,content=[{path=/Users/bstansberry/tmp/hello,archive=false}])
{
"address" => [("deployment" => "hello")],
"operation" => "add",
"content" => [{
"path" => "/home/mey/tmp/hello",
"archive" => "false"
}],
"runtime-name" => "helloworld.war",
"enabled" => true
}
{code}
> Do not force that the exploded directory ends with ".war"
> ---------------------------------------------------------
>
> Key: WFLY-4081
> URL: https://issues.jboss.org/browse/WFLY-4081
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Geoffrey De Smet
> Assignee: Jason Greene
>
> In a standard webapp, maven creates the following directory and file:
> // Exploded directory
> target/mywebapp-1.0/
> // War file
> target/mywebapp-1.0.war
> *Unfortunately, WildFly forces that exploded directories should have the suffix ".war"*. At least the IntelliJ JBoss app server plugin enforces this, if that's no longer the case, they should fix it asap. This has 2 side effects:
> 1) Every noob fails to deploy an exploded dir to WildFly in IntelliJ. By the time they realize that it's because they haven't adjusted the exploded artifact's output path, they're already using Jetty or Tomcat (which "just work" in IntelliJ).
> 2) As a result, maven and IntelliJ are potentially incompatible for WildFly:
> If you just suffix the exploded directory with ".war", the exploded directory clashes with maven's war file.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months
[JBoss JIRA] (WFCORE-488) Failures of undeploy of a partially failed deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-488?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-488:
-----------------------------------------
In what process did the "throw ControllerMessages.MESSAGES.managementResourceNotFound(missing)" occur?
Any idea why the deployment resource was not present there?
Re: "1. does not propagate from the host to DC and to CLI"
Are you saying it doesn't propagate to the DC? Or just that it's not propagated to the CLI? Or just that it's not *reported* by the CLI? The CLI has an issue with not providing full details of failures in its output from high level commands.
> Failures of undeploy of a partially failed deployment
> -----------------------------------------------------
>
> Key: WFCORE-488
> URL: https://issues.jboss.org/browse/WFCORE-488
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
>
> {noformat}
> [domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups
> Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers.
> {noformat}
> There are several issues at play here:
> # Insufficient information is displayed along with JBAS010839
> # No actual failure logged either in DC or in individual host's logs
> # Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler
> I'll start in a reverse order of causation:
> In DeploymentUndeployHandler.execute
> {noformat}
> public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
> ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel();
> ...
> {noformat}
> OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild:
> {noformat}
> private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) {
> if (resource.hasChild(childPath)) {
> return resource.requireChild(childPath);
> } else {
> PathAddress missing = PathAddress.EMPTY_ADDRESS;
> for (PathElement search : fullAddress) {
> missing = missing.append(search);
> if (search.equals(childPath)) {
> break;
> }
> }
> throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);
> }
> }
> {noformat}
> The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}:
> # does not propagate from the host to DC and to CLI
> # is not logged with any level (not even TRACE) either on host or DC
> # should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months
[JBoss JIRA] (WFCORE-488) Failures of undeploy of a partially failed deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-488?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-4203 to WFCORE-488:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-488 (was: WFLY-4203)
Affects Version/s: (was: 8.2.0.Final)
Component/s: CLI
Domain Management
(was: CLI)
(was: Domain Management)
> Failures of undeploy of a partially failed deployment
> -----------------------------------------------------
>
> Key: WFCORE-488
> URL: https://issues.jboss.org/browse/WFCORE-488
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
>
> {noformat}
> [domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups
> Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers.
> {noformat}
> There are several issues at play here:
> # Insufficient information is displayed along with JBAS010839
> # No actual failure logged either in DC or in individual host's logs
> # Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler
> I'll start in a reverse order of causation:
> In DeploymentUndeployHandler.execute
> {noformat}
> public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
> ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel();
> ...
> {noformat}
> OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild:
> {noformat}
> private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) {
> if (resource.hasChild(childPath)) {
> return resource.requireChild(childPath);
> } else {
> PathAddress missing = PathAddress.EMPTY_ADDRESS;
> for (PathElement search : fullAddress) {
> missing = missing.append(search);
> if (search.equals(childPath)) {
> break;
> }
> }
> throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);
> }
> }
> {noformat}
> The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}:
> # does not propagate from the host to DC and to CLI
> # is not logged with any level (not even TRACE) either on host or DC
> # should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months
[JBoss JIRA] (WFLY-4203) Failures of undeploy of a partially failed deployment
by Arcadiy Ivanov (JIRA)
Arcadiy Ivanov created WFLY-4203:
------------------------------------
Summary: Failures of undeploy of a partially failed deployment
Key: WFLY-4203
URL: https://issues.jboss.org/browse/WFLY-4203
Project: WildFly
Issue Type: Bug
Components: CLI, Domain Management
Affects Versions: 8.2.0.Final
Reporter: Arcadiy Ivanov
Assignee: Alexey Loubyansky
{noformat}
[domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups
Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers.
{noformat}
There are several issues at play here:
# Insufficient information is displayed along with JBAS010839
# No actual failure logged either in DC or in individual host's logs
# Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler
I'll start in a reverse order of causation:
in DeploymentUndeployHandler.execute
{noformat}
public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel();
...
{noformat}
OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild:
{noformat}
private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) {
if (resource.hasChild(childPath)) {
return resource.requireChild(childPath);
} else {
PathAddress missing = PathAddress.EMPTY_ADDRESS;
for (PathElement search : fullAddress) {
missing = missing.append(search);
if (search.equals(childPath)) {
break;
}
}
throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);
}
}
{noformat}
The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}:
# does not propagate from the host to DC and to CLI
# is not logged with any level (not even TRACE) either on host or DC
# should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months
[JBoss JIRA] (WFLY-4203) Failures of undeploy of a partially failed deployment
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4203?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated WFLY-4203:
---------------------------------
Description:
{noformat}
[domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups
Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers.
{noformat}
There are several issues at play here:
# Insufficient information is displayed along with JBAS010839
# No actual failure logged either in DC or in individual host's logs
# Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler
I'll start in a reverse order of causation:
In DeploymentUndeployHandler.execute
{noformat}
public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel();
...
{noformat}
OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild:
{noformat}
private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) {
if (resource.hasChild(childPath)) {
return resource.requireChild(childPath);
} else {
PathAddress missing = PathAddress.EMPTY_ADDRESS;
for (PathElement search : fullAddress) {
missing = missing.append(search);
if (search.equals(childPath)) {
break;
}
}
throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);
}
}
{noformat}
The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}:
# does not propagate from the host to DC and to CLI
# is not logged with any level (not even TRACE) either on host or DC
# should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies).
was:
{noformat}
[domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups
Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers.
{noformat}
There are several issues at play here:
# Insufficient information is displayed along with JBAS010839
# No actual failure logged either in DC or in individual host's logs
# Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler
I'll start in a reverse order of causation:
in DeploymentUndeployHandler.execute
{noformat}
public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel();
...
{noformat}
OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild:
{noformat}
private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) {
if (resource.hasChild(childPath)) {
return resource.requireChild(childPath);
} else {
PathAddress missing = PathAddress.EMPTY_ADDRESS;
for (PathElement search : fullAddress) {
missing = missing.append(search);
if (search.equals(childPath)) {
break;
}
}
throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);
}
}
{noformat}
The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}:
# does not propagate from the host to DC and to CLI
# is not logged with any level (not even TRACE) either on host or DC
# should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies).
> Failures of undeploy of a partially failed deployment
> -----------------------------------------------------
>
> Key: WFLY-4203
> URL: https://issues.jboss.org/browse/WFLY-4203
> Project: WildFly
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 8.2.0.Final
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
>
> {noformat}
> [domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups
> Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers.
> {noformat}
> There are several issues at play here:
> # Insufficient information is displayed along with JBAS010839
> # No actual failure logged either in DC or in individual host's logs
> # Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler
> I'll start in a reverse order of causation:
> In DeploymentUndeployHandler.execute
> {noformat}
> public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
> ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel();
> ...
> {noformat}
> OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild:
> {noformat}
> private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) {
> if (resource.hasChild(childPath)) {
> return resource.requireChild(childPath);
> } else {
> PathAddress missing = PathAddress.EMPTY_ADDRESS;
> for (PathElement search : fullAddress) {
> missing = missing.append(search);
> if (search.equals(childPath)) {
> break;
> }
> }
> throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);
> }
> }
> {noformat}
> The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}:
> # does not propagate from the host to DC and to CLI
> # is not logged with any level (not even TRACE) either on host or DC
> # should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months