[JBoss JIRA] (WFCORE-76) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-76?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFCORE-76:
--------------------------------------
#138 is not correct - IT test changed location and it had changes in logic as well, which PR #139 correctly mirrors.
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFCORE-76
> URL: https://issues.jboss.org/browse/WFCORE-76
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> 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
> Fix For: 1.0.0.Alpha6
>
>
> 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.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFCORE-76) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-76?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFCORE-76:
--------------------------------------
I added PR #139. Sorry, we apparently, bumped into each other.
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFCORE-76
> URL: https://issues.jboss.org/browse/WFCORE-76
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> 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
> Fix For: 1.0.0.Alpha6
>
>
> 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.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3791) Error on ModelControllerClient to list sections
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3791?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-3791:
----------------------------------------
Actually first please try your client against a clean Wildfly 8.1.0.Final install, that will be the easiest way to eliminate something from your settings / environment.
> Error on ModelControllerClient to list sections
> -----------------------------------------------
>
> Key: WFLY-3791
> URL: https://issues.jboss.org/browse/WFLY-3791
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Java 7
> Reporter: ofbiz brazil
> Assignee: Darran Lofthouse
>
> Hello,
> When there's a client trying to list a node for a security section, Wildfly says it does not exist but on Jboss 7.1.1 it works fine.
> Java Code:
> --------------
> final ModelNode request = new ModelNode();
> request.get(ClientConstants.OP).set("read-resource");
> request.get("recursive").set(true);
> request.get(ClientConstants.OP_ADDR).add("subsystem", "security");
> final ModelControllerClient client = ModelControllerClient.Factory.create(InetAddress.getByName("127.0.0.1"), 9999);
> final ModelNode response = client.execute(new OperationBuilder(request).build());
> final String section = response.get(ClientConstants.RESULT).get("security-domain")
> .get("pw_MSSQL_CAS_DS")
> Result:
> ---------
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014807: Management resource '[(\"subsystem\" => \"security\")]' not found",
> "rolled-back" => true
> }
> Cheers,
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-2770) CDI Decorator should be enable on Websocket enpoint
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2770?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2770:
--------------------------------------
Good point. I will add a check that the bean is actually of the correct type, and if not just pass in null.
> CDI Decorator should be enable on Websocket enpoint
> ----------------------------------------------------
>
> Key: WFLY-2770
> URL: https://issues.jboss.org/browse/WFLY-2770
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Reporter: Antoine Sabot-Durand
> Assignee: Stuart Douglas
> Attachments: websocket-decorator.zip
>
>
> Defining a CDI decorator on Websocket Endpoint doesn't work. I know it's not strictly required by websocket spec (it only mentions interceptors) but as it's working in Glassfish 4, it could be nice and less confusing to add this feature to Wildfly
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFCORE-76) read-resource recursive-depth has no effect when recursive=true
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-76?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-76:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/138
I'll gladly drop PR #138 if you have already have one.
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFCORE-76
> URL: https://issues.jboss.org/browse/WFCORE-76
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> 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
> Fix For: 1.0.0.Alpha6
>
>
> 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.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3724) Batch jobs don't receive partition-specific parameters
by Ari Silvan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3724?page=com.atlassian.jira.plugin.... ]
Ari Silvan reopened WFLY-3724:
------------------------------
My example is based on the Phonebilling example application on the Java EE 7 tutorial, but is simplified as much as possible. Why the exactly same code is behaving differently on GlassFish and Wildfly?
On GlassFish:
TestReader class: code line System.out.println("Partition params is not null."); is called and batch is started as two partitions. Partition params are available.
On WildFly:
TestReader class: code line System.out.println("Partition params is null, should not be."); is called and batch work cannot be started because partition params are not available.
Can you please examine the issue a little bit more. I don't think that Java EE 7 tutorial gives an example that is against the specification.
> Batch jobs don't receive partition-specific parameters
> ------------------------------------------------------
>
> Key: WFLY-3724
> URL: https://issues.jboss.org/browse/WFLY-3724
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Batch
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 Home Premium Service Pack 1 64-bit + JDK8u11 + WildFly 8.1.0 Final
> Reporter: Ari Silvan
> Assignee: Enrique González Martínez
>
> When defining a batch job chunk step to run as partitions, ItemReader doesn't receive the partition-specific parameters specified by an implementation of the PartitionPlan interface. Parameters are null. See steps to reproduce for further details.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFCORE-76) read-resource recursive-depth has no effect when recursive=true
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-76?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-76:
----------------------------------------
I'm forward-porting the WildFly 8.x PR, unless you have one already for wildfly-core/master.
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFCORE-76
> URL: https://issues.jboss.org/browse/WFCORE-76
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> 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
> Fix For: 1.0.0.Alpha6
>
>
> 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.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3149) Windows service on 64 bit systems cannot be stopped
by Claudio Illanes (JIRA)
[ https://issues.jboss.org/browse/WFLY-3149?page=com.atlassian.jira.plugin.... ]
Claudio Illanes edited comment on WFLY-3149 at 8/28/14 4:08 PM:
----------------------------------------------------------------
Is the fix just to remove the credentials variables from the 2 lines?
(Restricted to jira-users group)
was (Author: claudioillanes):
I found that manually running ""jboss-cli.bat --controller=localhost:9990 --connect --command=:shutdown" did not shut the service down.
To fix this install issue:
1. I went to the command line and ran "wildfly-mgr.exe //ES//Wildfly"
2. Visited the shutdown tab and realized that my wildfly install doesn't respond to localhost:9990. I changed "localhost" to my server IP, saved the change, and I was then able to stop the service from the command line.
I guess my Wildfly setup is not permitting localhost:9990 to be reached.
> Windows service on 64 bit systems cannot be stopped
> ---------------------------------------------------
>
> Key: WFLY-3149
> URL: https://issues.jboss.org/browse/WFLY-3149
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Final
> Environment: Windows 2008 Server, Windows 7 professional - both 64 bit systems using JDK 1.7.0_09
> Reporter: Mohan Potturi
> Assignee: Mladen Turk
>
> The Windows service cannot be stopped. It says 'stopping' in the windows service user interface window. The only way to stop it is ti actually kill the java process. It works flawlessly on 32 bit systems though.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFCORE-76) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-76?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFCORE-76:
--------------------------------------
Oops, sorry, linked wrong pull request.
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFCORE-76
> URL: https://issues.jboss.org/browse/WFCORE-76
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> 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
> Fix For: 1.0.0.Alpha6
>
>
> 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.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFCORE-76) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-76?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated WFCORE-76:
---------------------------------
Git Pull Request: (was: https://github.com/wildfly/wildfly-core/pull/110)
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFCORE-76
> URL: https://issues.jboss.org/browse/WFCORE-76
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> 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
> Fix For: 1.0.0.Alpha6
>
>
> 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.3.1#6329)
11 years, 8 months