[JBoss JIRA] (WFLY-3726) Filesystem deployment scanner deployment failure removes unrelated deployments
by Jess Holle (JIRA)
[ https://issues.jboss.org/browse/WFLY-3726?page=com.atlassian.jira.plugin.... ]
Jess Holle commented on WFLY-3726:
----------------------------------
Actually the filesystem contents were very nearly appropriate as an ear. Further analysis showed that the only issues was a single .rar file that was present but should not be actually deployed/activated. We can rename/zip/remove/whatever this. Doing so allows deployment via deployment scanner of the parent directory as an ear and the child directory as a war.
All that said, explicit deployment of the exploded war directory should also work -- and does up until a deployment scanner fails to deploy an application, at which point the <deployments> element is removed from standalone-full.xml, which is patently incorrect and the subject of this bug.
In short, for my use case I now have another workaround, but this bug is still quite valid.
> Filesystem deployment scanner deployment failure removes unrelated deployments
> ------------------------------------------------------------------------------
>
> Key: WFLY-3726
> URL: https://issues.jboss.org/browse/WFLY-3726
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: WIndows and Linux platforms both exhibit the issue
> Reporter: Jess Holle
> Assignee: Emmanuel Hugonnet
>
> If one's standalone-full.xml configuration contains something like:
> <deployments>
> <deployment name="MyWebApp.war" runtime-name="MyWebApp.war" enabled="true">
> <fs-exploded path="../../SomeDir/MyWebApp.war" relative-to="jboss.home.dir"/>
> </deployment>
> </deployments>
> whether manually inserted (while the server is not running) or installed via the CLI via
> /deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}])
> and a deployment scanner like:
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <deployment-scanner name="1" path="../../../Applications" relative-to="jboss.server.base.dir" scan-interval="5000" auto-deploy-exploded="true"/>
> </subsystem>
> a failure by a deployment-scanner to deploy an application (exploded in my case, though I'm not sure this makes a difference) will cause the explicitly listed <deployments> to be removed from the configuration!
> This occurs irrespective of the value used for auto-deploy-exploded and to <deployment> elements that had already successfully been deployed and started.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov edited comment on WFLY-3705 at 8/11/14 3:17 PM:
---------------------------------------------------------------
Works for me.
Revised behavioral table:
{noformat}
Recursive | Recursive Depth | Behavior
T | U | Max depth recursion
F | U | No recursion
T | 0 | Max depth recursion
F | 0 | No recursion
T | N, N > 0 | N-deep recursion
F | N, N > 0 | No recursion
U | U | No recursion
U | 0 | No recursion
U | N, N > 0 | N-deep recursion
{noformat}
I do have a concern that the following combo seems counter-intuitive though:
{noformat}
Recursive | Recursive Depth | Behavior
T | 0 | Max depth recursion
T | N, N > 0 | N-deep recursion
{noformat}
was (Author: arcivanov):
Works for me.
Revised behavioral table:
{noformat}
Recursive | Recursive Depth | Behavior
T | U | Max depth recursion
F | U | No recursion
T | 0 | Max depth recursion
F | 0 | No recursion
T | N, N > 0 | N-deep recursion
F | N, N > 0 | No recursion
U | U | No recursion
U | 0 | No recursion
U | N, N > 0 | N-deep recursion
{noformat}
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation, Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-3705:
--------------------------------------
Works for me.
Revised behavioral table:
{noformat}
Recursive | Recursive Depth | Behavior
T | U | Max depth recursion
F | U | No recursion
T | 0 | Max depth recursion
F | 0 | No recursion
T | N, N > 0 | N-deep recursion
F | N, N > 0 | No recursion
U | U | No recursion
U | 0 | No recursion
U | N, N > 0 | N-deep recursion
{noformat}
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation, Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3705:
----------------------------------------
For this case:
{code}
T | N, N > 0 | Max depth recursion
{code}
I think N-deep recursion is better, and is OK. It's a behavior change, but it's much less likely to have a negative impact on an actual user than requiring recursive=true to get recursion would have. I doubt many, if any users are using recursive=true,recursive-depth=N and then are actually trying to navigate past N levels.
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation, Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (JGRP-1871) NPEs due to non-volatile Protocol variables
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1871?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1871:
--------------------------------
Oops, didn't see you closed it. What workaround did you come up with ?
> NPEs due to non-volatile Protocol variables
> -------------------------------------------
>
> Key: JGRP-1871
> URL: https://issues.jboss.org/browse/JGRP-1871
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.5, 3.5
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> In WildFly a given channel is created in one thread, but is potentially started in a different thread. Unfortunately, many of the protocol variables that are set during Protocol.init() are non-volatile. This can cause unexpected behavior as seen in WFLY-3727.
> To ensure clean initialization for multi-threaded environments like WF, all non-final variables within every JGroups' Protocol should be volatile.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-3705:
--------------------------------------
Is there some instability/non-determinism in the build farm? I amended my pull with a functionally-neutral commit in response to code review feedback, my test count rose 10 times, failure count dropped from 11 to 2 and those two are actually environmental EJB client exceptions.
Can these results be trusted?
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation, Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov edited comment on WFLY-3705 at 8/11/14 3:02 PM:
---------------------------------------------------------------
I think the proposed compromise solution would be acceptable wrt backwards compatibility:
So the behavioral table is:
{noformat}
Recursive | Recursive Depth | Behavior
T | U | Max depth recursion
F | U | No recursion
T | 0 | Max depth recursion
F | 0 | No recursion
T | N, N > 0 | Max depth recursion
F | N, N > 0 | No recursion
U | U | No recursion
U | 0 | No recursion
U | N, N > 0 | N-deep recursion
{noformat}
Did I miss anything?
was (Author: arcivanov):
I think the proposed compromise solution would be acceptable wrt backwards compatibility:
So the behavioral table is:
{noformat}
Recursive | Recursive Depth | Behavior
T | U | Max depth recursion
F | U | No recursion
T | 0 | Max depth recursion
F | 0 | No recursion
T | N, N > 0 | Max depth recursion
F | N, N > 0 | No recursion
U | U | No recursion
U | 0 | No recursion
U | N, N > 0 | N-deep recursion
{noformat}
Did I miss anything?
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation, Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (JGRP-1871) NPEs due to non-volatile Protocol variables
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1871?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1871:
--------------------------------
Have Infinispan and WildFly/JBoss always used different threads and - if so - why hasn't this occurred before ?
> NPEs due to non-volatile Protocol variables
> -------------------------------------------
>
> Key: JGRP-1871
> URL: https://issues.jboss.org/browse/JGRP-1871
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.5, 3.5
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> In WildFly a given channel is created in one thread, but is potentially started in a different thread. Unfortunately, many of the protocol variables that are set during Protocol.init() are non-volatile. This can cause unexpected behavior as seen in WFLY-3727.
> To ensure clean initialization for multi-threaded environments like WF, all non-final variables within every JGroups' Protocol should be volatile.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-3705:
--------------------------------------
I think the proposed compromise solution would be acceptable wrt backwards compatibility:
So the behavioral table is:
{noformat}
Recursive | Recursive Depth | Behavior
T | U | Max depth recursion
F | U | No recursion
T | 0 | Max depth recursion
F | 0 | No recursion
T | N, N > 0 | Max depth recursion
F | N, N > 0 | No recursion
U | U | No recursion
U | 0 | No recursion
U | N, N > 0 | N-deep recursion
{noformat}
Did I miss anything?
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation, Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (JGRP-1871) NPEs due to non-volatile Protocol variables
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1871?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed JGRP-1871.
------------------------------
Assignee: Paul Ferraro (was: Bela Ban)
Resolution: Rejected
Closing for now - I think I found a workaround.
> NPEs due to non-volatile Protocol variables
> -------------------------------------------
>
> Key: JGRP-1871
> URL: https://issues.jboss.org/browse/JGRP-1871
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.5, 3.5
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> In WildFly a given channel is created in one thread, but is potentially started in a different thread. Unfortunately, many of the protocol variables that are set during Protocol.init() are non-volatile. This can cause unexpected behavior as seen in WFLY-3727.
> To ensure clean initialization for multi-threaded environments like WF, all non-final variables within every JGroups' Protocol should be volatile.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months