[JBoss JIRA] (WFLY-3791) Error on ModelControllerClient to list sections
by ofbiz brazil (JIRA)
[ https://issues.jboss.org/browse/WFLY-3791?page=com.atlassian.jira.plugin.... ]
ofbiz brazil commented on WFLY-3791:
------------------------------------
Yes, I am really using the last version of Wildfly 8.1.0.Final, as I described in bug ticket. :)
Could you replicate this error in your java code?
> 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, 1 month
[JBoss JIRA] (DROOLS-584) CDIHelper caches JNDI lookup early on, missing on java:comp/BeanManager
by Antoine Toulme (JIRA)
[ https://issues.jboss.org/browse/DROOLS-584?page=com.atlassian.jira.plugin... ]
Antoine Toulme updated DROOLS-584:
----------------------------------
Description:
Looking at CDIHelper, on line 96, it caches a static beanCreator. The beanCreator is created based on JNDI lookups for CDI BeanManager.
The JNDI lookup returns null however, in the situation where the system just started out, especially when the system is modular. For example Wildfly 8.1 will create such a situation.
In the event that the BeanManager is not there, the default implementation of using a reflection approach is used instead, which transparently masks the problem.
However, if the bean created relies on CDI to inject fields, it becomes problematic.
A few recommendations:
-do not cache the beanCreator. Recreate it every time, at the cost of making several JNDI lookups.
-use DeltaSpike, longer term plan to remove this code.
> CDIHelper caches JNDI lookup early on, missing on java:comp/BeanManager
> -----------------------------------------------------------------------
>
> Key: DROOLS-584
> URL: https://issues.jboss.org/browse/DROOLS-584
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Final, 6.2.0.Beta1
> Reporter: Antoine Toulme
> Assignee: Mark Proctor
>
> Looking at CDIHelper, on line 96, it caches a static beanCreator. The beanCreator is created based on JNDI lookups for CDI BeanManager.
> The JNDI lookup returns null however, in the situation where the system just started out, especially when the system is modular. For example Wildfly 8.1 will create such a situation.
> In the event that the BeanManager is not there, the default implementation of using a reflection approach is used instead, which transparently masks the problem.
> However, if the bean created relies on CDI to inject fields, it becomes problematic.
> A few recommendations:
> -do not cache the beanCreator. Recreate it every time, at the cost of making several JNDI lookups.
> -use DeltaSpike, longer term plan to remove this code.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 1 month
[JBoss JIRA] (WFLY-1260) Remove workaround for shutting down the ModelControllerClientOperationHandlers
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1260?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-1260:
--------------------------------------
I don't think this really relates to graceful shutdown, which is focussed on user requests rather than management operations.
> Remove workaround for shutting down the ModelControllerClientOperationHandlers
> ------------------------------------------------------------------------------
>
> Key: WFLY-1260
> URL: https://issues.jboss.org/browse/WFLY-1260
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Emanuel Muckenhuber
>
> Once the graceful shutdown API is in place we need to cleanup the way the ModelControllerClientOperationHandler channels are closed. Currently we are waiting for all current operations to complete, in order that the response for :reload / :shutdown operations are sent.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 1 month
[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, 1 month
[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, 1 month
[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, 1 month
[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, 1 month