August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-479) Pseudo Clock doesn't work for 2 not statements

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-479?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-479: ------------------------------------------------ Radovan Synek <rsynek(a)redhat.com> changed the Status of [bug 1122738|https://bugzilla.redhat.com/show_bug.cgi?id=1122738] from ASSIGNED to VERIFIED > Pseudo Clock doesn't work for 2 not statements > ---------------------------------------------- > > Key: DROOLS-479 > URL: https://issues.jboss.org/browse/DROOLS-479 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final, 6.1.0.Beta3 > Environment: linux 14.04 > Reporter: Richard Ambridge > Assignee: Mario Fusco > Labels: pseudoclock > > If a rule (event) has the following: > + "when\n" > + " $s : Cheese(type==\"stinky\")\n" > + " not( Cheese(type==\"a\", this after [0s,3s] $s ) )\n" > + " not( Cheese(type==\"b\", this after [0s,5s] $s ) )\n" //2 * not > and pseudo clock is used, the rule doesn't fire. > If realtime clock is used, the rule works. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (DROOLS-584) CDIHelper caches JNDI lookup early on, missing on java:comp/BeanManager

by Antoine Toulme (JIRA)

Antoine Toulme created DROOLS-584: ------------------------------------- Summary: 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.2.0.Beta1, 6.1.0.Final Reporter: Antoine Toulme Assignee: Mark Proctor -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-3793) Implement transformers for graceful shutdown operations

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-3793: ------------------------------------ Summary: Implement transformers for graceful shutdown operations Key: WFLY-3793 URL: https://issues.jboss.org/browse/WFLY-3793 Project: WildFly Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2014