[JBoss JIRA] (DROOLS-319) "Unknown boolean operator" RuntimeException
by David Tombs (JIRA)
[ https://issues.jboss.org/browse/DROOLS-319?page=com.atlassian.jira.plugin... ]
David Tombs updated DROOLS-319:
-------------------------------
Description:
Steps to reproduce:
# Create a decision table with something like {{fooString != ""}} in the constraint and {{true}} in the rule cell.
# Execute the rule against a few objects.
Actual Result:
An internal Drools thread will crash with {{java.lang.RuntimeException: Unknown boolean operator}} when trying to compile {{fooString != "" == true}}.
{{
Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
}}
Expected Result:
Even if an Exception is thrown, the currently-thrown exception is too low level and took me lots of investigation and debugging inside the drools code to figure out what I did wrong.
was:
Steps to reproduce:
# Create a decision table with something like {{fooString != ""}} in the constraint and {{true}} in the rule cell.
# Execute the rule against a few objects.
Actual Result:
An internal Drools thread will crash with {{java.lang.RuntimeException: Unknown boolean operator}} when trying to compile {{fooString != "" == true}}.
Expected Result:
Even if an Exception is thrown, the currently-thrown exception is too low level and took me lots of investigation and debugging inside the drools code to figure out what I did wrong.
> "Unknown boolean operator" RuntimeException
> -------------------------------------------
>
> Key: DROOLS-319
> URL: https://issues.jboss.org/browse/DROOLS-319
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: Windows 8, java version "1.7.0_40"
> Reporter: David Tombs
> Assignee: Mark Proctor
>
> Steps to reproduce:
> # Create a decision table with something like {{fooString != ""}} in the constraint and {{true}} in the rule cell.
> # Execute the rule against a few objects.
> Actual Result:
> An internal Drools thread will crash with {{java.lang.RuntimeException: Unknown boolean operator}} when trying to compile {{fooString != "" == true}}.
> {{
> Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
> at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
> at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
> at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
> at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
> at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> }}
> Expected Result:
> Even if an Exception is thrown, the currently-thrown exception is too low level and took me lots of investigation and debugging inside the drools code to figure out what I did wrong.
--
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
12 years, 6 months
[JBoss JIRA] (JGRP-1733) UNICAST3: 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 updated JGRP-1733:
---------------------------
Summary: UNICAST3: OOB messages should be marked as OOB_DELIVERED before adding them to the table (was: UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table)
> UNICAST3: 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
12 years, 6 months
[JBoss JIRA] (DROOLS-319) "Unknown boolean operator" RuntimeException
by David Tombs (JIRA)
[ https://issues.jboss.org/browse/DROOLS-319?page=com.atlassian.jira.plugin... ]
David Tombs updated DROOLS-319:
-------------------------------
Description:
Steps to reproduce:
# Create a decision table with something like {{fooString != ""}} in the constraint and {{true}} in the rule cell.
# Execute the rule against a few objects.
Actual Result:
An internal Drools thread will crash with {{java.lang.RuntimeException: Unknown boolean operator}} when trying to compile {{fooString != "" == true}}.
{noformat}
Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
{noformat}
Expected Result:
Even if an Exception is thrown, the currently-thrown exception is too low level and took me lots of investigation and debugging inside the drools code to figure out what I did wrong.
was:
Steps to reproduce:
# Create a decision table with something like {{fooString != ""}} in the constraint and {{true}} in the rule cell.
# Execute the rule against a few objects.
Actual Result:
An internal Drools thread will crash with {{java.lang.RuntimeException: Unknown boolean operator}} when trying to compile {{fooString != "" == true}}.
{{
Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
}}
Expected Result:
Even if an Exception is thrown, the currently-thrown exception is too low level and took me lots of investigation and debugging inside the drools code to figure out what I did wrong.
> "Unknown boolean operator" RuntimeException
> -------------------------------------------
>
> Key: DROOLS-319
> URL: https://issues.jboss.org/browse/DROOLS-319
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: Windows 8, java version "1.7.0_40"
> Reporter: David Tombs
> Assignee: Mark Proctor
>
> Steps to reproduce:
> # Create a decision table with something like {{fooString != ""}} in the constraint and {{true}} in the rule cell.
> # Execute the rule against a few objects.
> Actual Result:
> An internal Drools thread will crash with {{java.lang.RuntimeException: Unknown boolean operator}} when trying to compile {{fooString != "" == true}}.
> {noformat}
> Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
> at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
> at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
> at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
> at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
> at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> {noformat}
> Expected Result:
> Even if an Exception is thrown, the currently-thrown exception is too low level and took me lots of investigation and debugging inside the drools code to figure out what I did wrong.
--
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
12 years, 6 months
[JBoss JIRA] (DROOLS-326) Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-326?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-326:
------------------------------------------------
Kris Verlaenen <kverlaen(a)redhat.com> changed the Status of [bug 1027765|https://bugzilla.redhat.com/show_bug.cgi?id=1027765] from NEW to MODIFIED
> Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-326
> URL: https://issues.jboss.org/browse/DROOLS-326
> 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: conditional, consequence, eclipse, named, plugin, rete, tree, view
>
> See this project, which is based on the standard Sample.drl of the Drools Eclipse plugin: https://github.com/DuncanDoyle/DroolsConditionalNamedConsequenceIssue
> The 'src/main/resources/rules/Sample.drl' contains a rule which uses a 'Conditional Named Consequence' construct. When clicking the Rete Tree tab in the DRL editor I receive this error:
> Rete Tree Build Error!
> Reason:
> org.drools.core.RuntimeDroolsException:
> java.lang.reflect.InvocationTargetException : [Rete(0)]
> And the Rete Tree is not displayed.
--
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
12 years, 6 months
[JBoss JIRA] (DROOLS-326) Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-326?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-326:
------------------------------------------------
Kris Verlaenen <kverlaen(a)redhat.com> made a comment on [bug 1027765|https://bugzilla.redhat.com/show_bug.cgi?id=1027765]
Already fixed as part of previous commit (see https://bugzilla.redhat.com/show_bug.cgi?id=1027118)
master: https://github.com/droolsjbpm/droolsjbpm-tools/commit/ff822bdc36de07e7071...
6.0.x: https://github.com/droolsjbpm/droolsjbpm-tools/commit/60c768cbad80bedcbd6...
Note this is not in the 6.0.0.Final tag.
> Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-326
> URL: https://issues.jboss.org/browse/DROOLS-326
> 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: conditional, consequence, eclipse, named, plugin, rete, tree, view
>
> See this project, which is based on the standard Sample.drl of the Drools Eclipse plugin: https://github.com/DuncanDoyle/DroolsConditionalNamedConsequenceIssue
> The 'src/main/resources/rules/Sample.drl' contains a rule which uses a 'Conditional Named Consequence' construct. When clicking the Rete Tree tab in the DRL editor I receive this error:
> Rete Tree Build Error!
> Reason:
> org.drools.core.RuntimeDroolsException:
> java.lang.reflect.InvocationTargetException : [Rete(0)]
> And the Rete Tree is not displayed.
--
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
12 years, 6 months
[JBoss JIRA] (WFLY-2462) Too many element definitions in the CLI configuration schema.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-2462:
--------------------------------------
Summary: Too many element definitions in the CLI configuration schema.
Key: WFLY-2462
URL: https://issues.jboss.org/browse/WFLY-2462
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CLI
Affects Versions: 8.0.0.Beta1
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 8.0.0.CR1
The CLI schema contains many element definitions, however the only one supported at the top level is 'jboss-cli' - the remainder need converting to complex type definitions.
--
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
12 years, 6 months
[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
12 years, 6 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
12 years, 6 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
12 years, 6 months