[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Martin Kouba reassigned WFLY-6173:
----------------------------------
Assignee: Martin Kouba (was: Stuart Douglas)
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Attachments: memory-leak.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBASMP-77) ConcurrentModificationException in deploy-artifact
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/JBASMP-77?page=com.atlassian.jira.plugin.... ]
Tomas Remes commented on JBASMP-77:
-----------------------------------
[~jamezp] any plans to release 7.8.Final?
> ConcurrentModificationException in deploy-artifact
> --------------------------------------------------
>
> Key: JBASMP-77
> URL: https://issues.jboss.org/browse/JBASMP-77
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Components: deploy
> Affects Versions: 7.7.Final
> Reporter: Daniele Gaffuri
> Assignee: Tomas Remes
> Fix For: 7.8.Final
>
>
> In the same situation of JBASMP-57 deploy-artifact throws the following exception:
> {code}
> [ERROR] Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.7.SCE:deploy-artifact (deploy) on project sideup-integration: Could not execute goal deploy-artifact on null. Reason: null: ConcurrentModificationException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.7.SCE:deploy-artifact (deploy) on project sideup-integration: Could not execute goal deploy-artifact on null. Reason: null
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Could not execute goal deploy-artifact on null. Reason: null
> at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:159)
> at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:112)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.util.ConcurrentModificationException
> at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:394)
> at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405)
> at java.util.AbstractCollection.addAll(AbstractCollection.java:341)
> at org.jboss.as.plugin.deployment.DeployArtifact.validate(DeployArtifact.java:84)
> at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
> ... 22 more
> {code}
> This is probably due to changes in related commit [37bc2c1], causing both deploy and undeploy validate methods to add the set of dependencies to itself:
> {code}
> final Set<Artifact> dependencies = project.getDependencyArtifacts();
> // Allows provided dependencies to be seen
> dependencies.addAll(project.getDependencyArtifacts());
> {code}
> {code}
> final Set<Artifact> dependencies = project.getDependencyArtifacts();
> dependencies.addAll(this.project.getDependencyArtifacts());
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1563) Failed CLI batch command with "deploy --force" for replace deployment
by ted won (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1563?page=com.atlassian.jira.plugi... ]
ted won updated WFCORE-1563:
----------------------------
Description:
Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part."
{code:title=Command}
jboss-cli.sh --connect --controller=127.0.0.1:9999 --user=admin --password=xxx --file="deploy.cli"
{code}
{code:title=deploy.cli}
batch
deploy --force ./jboss-ejb-in-ear.ear
run-batch
{code}
{panel:title=Full Error message}
Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part.
or
The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part.
{panel}
{panel:title=Expected message}
The batch executed successfully
{panel}
However, it's working in "WildFly 10 CLI interactive mode" and "JBoss AS 7 CLI batch" without error.
There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below.
Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle()
-------------------------------------------------------------------------------------------
* First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd()
{code}
{
"operation" => "add",
"address" => {"deployment" => "jboss-ejb-in-ear.ear"},
"content" => [{"bytes" => bytes {
...
}}]
}
{code}
-------------------------------------------------------------------------------------------
* After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
{code}
{
"operation" => "full-replace-deployment",
"name" => "jboss-ejb-in-ear.ear",
"enabled" => true,
"content" => [{"bytes" => bytes {
...
}}]
}
{code}
-------------------------------------------------------------------------------------------
* Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
{code}
{
"operation" => "full-replace-deployment",
"name" => "jboss-ejb-in-ear.ear",
"address" => [],
"enabled" => true,
"content" => [{"bytes" => bytes {
...
}}]
}
{code}
-------------------------------------------------------------------------------------------
was:
Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part."
{code}
batch
deploy --force ./jboss-ejb-in-ear.ear
run-batch
{code}
{panel:title=Full Error message}
Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part.
or
The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part.
{panel}
However, it's working in CLI interactive mode without error.
There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below.
Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle()
-------------------------------------------------------------------------------------------
* First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd()
{code}
{
"operation" => "add",
"address" => {"deployment" => "jboss-ejb-in-ear.ear"},
"content" => [{"bytes" => bytes {
...
}}]
}
{code}
-------------------------------------------------------------------------------------------
* After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
{code}
{
"operation" => "full-replace-deployment",
"name" => "jboss-ejb-in-ear.ear",
"enabled" => true,
"content" => [{"bytes" => bytes {
...
}}]
}
{code}
-------------------------------------------------------------------------------------------
* Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
{code}
{
"operation" => "full-replace-deployment",
"name" => "jboss-ejb-in-ear.ear",
"address" => [],
"enabled" => true,
"content" => [{"bytes" => bytes {
...
}}]
}
{code}
-------------------------------------------------------------------------------------------
> Failed CLI batch command with "deploy --force" for replace deployment
> ---------------------------------------------------------------------
>
> Key: WFCORE-1563
> URL: https://issues.jboss.org/browse/WFCORE-1563
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.Final, 3.0.0.Alpha1
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Labels: cli, jboss
> Fix For: 2.2.0.CR2, 3.0.0.Alpha2
>
> Attachments: jboss-ejb-in-ear.ear
>
>
> Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part."
> {code:title=Command}
> jboss-cli.sh --connect --controller=127.0.0.1:9999 --user=admin --password=xxx --file="deploy.cli"
> {code}
> {code:title=deploy.cli}
> batch
> deploy --force ./jboss-ejb-in-ear.ear
> run-batch
> {code}
> {panel:title=Full Error message}
> Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part.
> or
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part.
> {panel}
> {panel:title=Expected message}
> The batch executed successfully
> {panel}
> However, it's working in "WildFly 10 CLI interactive mode" and "JBoss AS 7 CLI batch" without error.
> There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below.
> Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle()
> -------------------------------------------------------------------------------------------
> * First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd()
> {code}
> {
> "operation" => "add",
> "address" => {"deployment" => "jboss-ejb-in-ear.ear"},
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "address" => [],
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
jaikiran pai reassigned WFLY-6173:
----------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Stuart Douglas
> Attachments: memory-leak.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-6173:
-------------------------------
Priority: Major (was: Minor)
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Jason Greene
> Attachments: memory-leak.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-6173:
-------------------------------
Component/s: CDI / Weld
(was: Server)
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Jason Greene
> Attachments: memory-leak.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-6173:
------------------------------------
Just had a quick look. This is reproducible against latest WildFly upstream code too. This appears to be a bug in the weld integration deployment process in the WildFly code. There's the org.jboss.as.weld.WeldModuleResourceLoader to which application classes get added but never get removed from that resource loader. The WeldModuleResourceLoader in itself get held on through some other integration classes like the WeldDeployment which goes all the way to the Weld implementation's service registry.
I think this is something that either [~jharting] or [~swd847] might be able to help with. Building, deploying and accessing the attached application from a browser and then undeploying it, easily reproduces the problem. I then did a jmap dump and used jhat to find the references.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Jason Greene
> Attachments: memory-leak.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1563) Failed CLI batch command with "deploy --force" for replace deployment
by ted won (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1563?page=com.atlassian.jira.plugi... ]
ted won updated WFCORE-1563:
----------------------------
Affects Version/s: 2.1.0.Final
> Failed CLI batch command with "deploy --force" for replace deployment
> ---------------------------------------------------------------------
>
> Key: WFCORE-1563
> URL: https://issues.jboss.org/browse/WFCORE-1563
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.Final, 3.0.0.Alpha1
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Labels: cli, jboss
> Fix For: 2.2.0.CR2, 3.0.0.Alpha2
>
> Attachments: jboss-ejb-in-ear.ear
>
>
> Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part."
> {code}
> batch
> deploy --force ./jboss-ejb-in-ear.ear
> run-batch
> {code}
> {panel:title=Full Error message}
> Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part.
> or
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part.
> {panel}
> However, it's working in CLI interactive mode without error.
> There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below.
> Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle()
> -------------------------------------------------------------------------------------------
> * First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd()
> {code}
> {
> "operation" => "add",
> "address" => {"deployment" => "jboss-ejb-in-ear.ear"},
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "address" => [],
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1563) Failed CLI batch command with "deploy --force" for replace deployment
by ted won (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1563?page=com.atlassian.jira.plugi... ]
ted won updated WFCORE-1563:
----------------------------
Fix Version/s: 2.2.0.CR2
> Failed CLI batch command with "deploy --force" for replace deployment
> ---------------------------------------------------------------------
>
> Key: WFCORE-1563
> URL: https://issues.jboss.org/browse/WFCORE-1563
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.Final, 3.0.0.Alpha1
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Labels: cli, jboss
> Fix For: 2.2.0.CR2, 3.0.0.Alpha2
>
> Attachments: jboss-ejb-in-ear.ear
>
>
> Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part."
> {code}
> batch
> deploy --force ./jboss-ejb-in-ear.ear
> run-batch
> {code}
> {panel:title=Full Error message}
> Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part.
> or
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part.
> {panel}
> However, it's working in CLI interactive mode without error.
> There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below.
> Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle()
> -------------------------------------------------------------------------------------------
> * First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd()
> {code}
> {
> "operation" => "add",
> "address" => {"deployment" => "jboss-ejb-in-ear.ear"},
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "address" => [],
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months