[JBoss JIRA] (WFLY-2266) Deployment Overlay feature is not able to replace the application libraries.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-2266:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1016995
> Deployment Overlay feature is not able to replace the application libraries.
> ----------------------------------------------------------------------------
>
> Key: WFLY-2266
> URL: https://issues.jboss.org/browse/WFLY-2266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Environment: All Operating Systems
> Reporter: Jay Kumar SenSharma
> Assignee: Stuart Douglas
> Labels: deployment
>
> -----------------------
> According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."
> Here it talks about "replacing jar libraries" which is not working as expected and causes the following error.
> [1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> Follow the below sequence of deployment and overlay:
> Steps to Reproduce:
> ------------------
> *Step-1).* Undeploy if any existing application is deployed and then freshly deploy the application.
> {quote}
> [standalone@localhost:9999 /] undeploy DeploymentOverlayDemo.war
> [standalone@localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war
> {quote}
> *Step-2).* Make some changes in java code _"Hello.java"_ . Create a new JAR Hello.jar which we want to replace at _(/WEB-INF/lib/Hello.jar)_ using deployment-overlay feature. In the attached ant based Demo just do _"ant compile"_ to create a new Jar _"${project.dir}/tmp/Hello.jar"_
> *Step-3).* Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:
> {quote}
> [standalone@localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected
> {quote}
>
> Above causes the following Exception:
> {quote}
> 12:09:59,736 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
> 12:09:59,760 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
> 12:09:59,761 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
> 12:09:59,761 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
> 12:09:59,762 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
> 12:09:59,787 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
> 12:09:59,789 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
> 12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 5 more
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
> at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 6 more
> 12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,814 INFO [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2461) refactoring of character escaping in operation parameter values
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFLY-2461:
---------------------------------------
Summary: refactoring of character escaping in operation parameter values
Key: WFLY-2461
URL: https://issues.jboss.org/browse/WFLY-2461
Project: WildFly
Issue Type: Task
Security Level: Public (Everyone can see)
Components: CLI
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Fix For: 8.0.0.CR1
There are potential issues with unescaping operation parameter values and command argument values that will be used as operation request parameter values.
The culprit is that these values are parsed twice: first, with the general command line parser and the second time with the value type parser (which depends on the type of the value: could be list, property list, DMR, etc). Both parsers support and may perform unescaping. Which may lead to confusions and issues like WFLY-161 or WFLY-1791 and then confusing conditions in the code.
The goal of this task is to not unescape parameter/argument values on the first parsing and leave it to the value type parsers. This concerns *only* parameter and argument value parsing, parsing of the other parts of operation requests and commands will remain as it is.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1733) UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1733?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1733 at 11/7/13 7:46 AM:
---------------------------------------------------------
The main advantage is that messages flagged as {{[OOB | DONT_BUNDLE]}} or {{[OOB | INTERNAL | DONT_BUNDLE]}} don't end up getting in a batch, possibly even by a regular thread. These types of messages are often used internally, and cannot get stuck behind other (application) messages in a batch, which delay deliver of the internal message or even block (e.g. RPCs waiting for a response).
was (Author: belaban):
The main advantage is that messages flagged as {{OOB | DONT_BUNDLE}} or {{OOB | INTERNAL | DONT_BUNDLE}} don't end up getting in a batch, possibly even by a regular thread. These types of messages are often used internally, and cannot get stuck behind other (application) messages in a batch, which delay deliver of the internal message or even block (e.g. RPCs waiting for a response).
> UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
> ------------------------------------------------------------------------------------------------
>
> Key: JGRP-1733
> URL: https://issues.jboss.org/browse/JGRP-1733
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up.
> However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery.
> This is the same though if a batch only contains regular messages...
> However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular messages).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (DROOLS-327) PHREAK goes into infinite loop, even with 'no-loop' defined.
by Duncan Doyle (JIRA)
[ https://issues.jboss.org/browse/DROOLS-327?page=com.atlassian.jira.plugin... ]
Duncan Doyle commented on DROOLS-327:
-------------------------------------
Just did some more testing. If you remove the 'Conditional Named Consequence', the 'no-loop' does work as expected, i.e.:
rule "Hello World" dialect "java"
no-loop
when
m : Message( myMessage : message )
// if (m.getStatus() == 0) do [sayHello]
then
System.out.println( myMessage );
m.setMessage( "Goodbye cruel world" );
m.setStatus( Message.GOODBYE );
update( m );
//then[sayHello]
// System.out.println("Hello, I'm here!");
end
> PHREAK goes into infinite loop, even with 'no-loop' defined.
> ------------------------------------------------------------
>
> Key: DROOLS-327
> URL: https://issues.jboss.org/browse/DROOLS-327
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR5
> Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45
> Reporter: Duncan Doyle
> Assignee: Mark Proctor
> Labels: infinite, loop, no-loop, phreak
>
> See this project on my Github: https://github.com/DuncanDoyle/DroolsPhreakConditionalNamedConsequenceInf...
> The 'src/main/resources/rules/Sample.drl' contains an adapted version of the default Drools Eclipse plugin sample rule. As you can see, the rule uses Conditional Named Consequence construct. Although the rule is a bit strange (the issue actuallty popped up while debugging another issue) it does show different behaviour between ReteOO and PHREAK, where in this case PHREAK actually goes into an infinitie-loop, even though 'no-loop' has been defined on the "Hello World" rule.
> To run the sample using ReteOO:
> - mvn -Preteoo exec:java
> The (correct) output is:
> Hello World
> Goodbye cruel world
> To run the sample using PHREAK
> - mvn -Pphreak exec:java
> The incorrect output is:
> Hello, I'm here!
> Hello World
> Goodbye cruel world
> Goodbye cruel world
> Goodbye cruel world
> Goodbye cruel world
> Goodbye cruel world
> {infinite loop}
> Note that the PHREAK run also prints "Hello, I'm here!" and ReteOO doesn't (because the activation of that rule is canceled when the Message is updated with a new message and status).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1733) UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1733?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1733 at 11/7/13 7:46 AM:
---------------------------------------------------------
The main advantage is that messages flagged as {{[OOB | DONT_BUNDLE]}} or {{[OOB | INTERNAL | DONT_BUNDLE]}} don't end up getting processed in a batch, possibly even by a regular thread. These types of messages are often used internally, and cannot get stuck behind other (application) messages in a batch, which delay deliver of the internal message or even block (e.g. RPCs waiting for a response).
was (Author: belaban):
The main advantage is that messages flagged as {{[OOB | DONT_BUNDLE]}} or {{[OOB | INTERNAL | DONT_BUNDLE]}} don't end up getting in a batch, possibly even by a regular thread. These types of messages are often used internally, and cannot get stuck behind other (application) messages in a batch, which delay deliver of the internal message or even block (e.g. RPCs waiting for a response).
> UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
> ------------------------------------------------------------------------------------------------
>
> Key: JGRP-1733
> URL: https://issues.jboss.org/browse/JGRP-1733
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up.
> However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery.
> This is the same though if a batch only contains regular messages...
> However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular messages).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1733) UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1733?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1733 at 11/7/13 7:47 AM:
---------------------------------------------------------
The main advantage is that messages flagged as {{[OOB | DONT_BUNDLE]}} or {{[OOB | INTERNAL | DONT_BUNDLE]}} don't end up getting processed in a batch, possibly even by a regular thread. These types of messages are often used internally, and cannot get stuck behind other (application) messages in a batch, which delay delivery of the internal message or even block (e.g. RPCs waiting for a response).
was (Author: belaban):
The main advantage is that messages flagged as {{[OOB | DONT_BUNDLE]}} or {{[OOB | INTERNAL | DONT_BUNDLE]}} don't end up getting processed in a batch, possibly even by a regular thread. These types of messages are often used internally, and cannot get stuck behind other (application) messages in a batch, which delay deliver of the internal message or even block (e.g. RPCs waiting for a response).
> UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
> ------------------------------------------------------------------------------------------------
>
> Key: JGRP-1733
> URL: https://issues.jboss.org/browse/JGRP-1733
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up.
> However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery.
> This is the same though if a batch only contains regular messages...
> However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular messages).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1733) UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1733?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1733:
--------------------------------
The main advantage is that messages flagged as {{OOB | DONT_BUNDLE}} or {{OOB | INTERNAL | DONT_BUNDLE}} don't end up getting in a batch, possibly even by a regular thread. These types of messages are often used internally, and cannot get stuck behind other (application) messages in a batch, which delay deliver of the internal message or even block (e.g. RPCs waiting for a response).
> UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
> ------------------------------------------------------------------------------------------------
>
> Key: JGRP-1733
> URL: https://issues.jboss.org/browse/JGRP-1733
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up.
> However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery.
> This is the same though if a batch only contains regular messages...
> However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular messages).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months