March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1441) Threads resource classes should make it easy for users to declare capabilities

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1441: ---------------------------------------- Summary: Threads resource classes should make it easy for users to declare capabilities Key: WFCORE-1441 URL: https://issues.jboss.org/browse/WFCORE-1441 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Brian Stansberry Fix For: 3.0.0.Beta1 The classes in the threads modules are now meant for shared use by subsystems in setting up consistent management of thread related resources. An important aspect of that management is the declaration of capabilities, particularly for use in capability-driven model integrity checking. But the threads module classes do not include any hooks to let the calling code specify the relevant capabilities. Things probably needed: 1) Ability to declare the capability that should be registered when a resource is created. 2) Ability to declare the capability that model reference attributes in a resource refer to. Perhaps others, but those are the ones that come immediately to mind. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1098) Equals behaviour faulty when loading sessions after exception

by Artur Kronenberg (JIRA)

Artur Kronenberg created DROOLS-1098: ---------------------------------------- Summary: Equals behaviour faulty when loading sessions after exception Key: DROOLS-1098 URL: https://issues.jboss.org/browse/DROOLS-1098 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.3.0.Final Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final Reporter: Artur Kronenberg Assignee: Mario Fusco Attachments: test-standalone.zip This is in a series of debugging and I think a few issues boil down to this: https://issues.jboss.org/browse/DROOLS-1093 https://issues.jboss.org/browse/DROOLS-1097 This bug demonstrates how two identical sessions with identical input and rules produce a NPE when loading with equals behaviour vs identity behaviour. I am currently battling that issue and looking for a workaround. Essentially, you can run the unit tests I attached in the test project: (ExceptionTest) testIdentity - passes testIdentityWithReload - passes testEquals - NPE testEqualsWithReload- NPE The tests do the same thing: * Create new persistent session * Load facts into it * Run 20 times either reloading the session (depending on the test cases) or using the old session. Each run, insert one fact and run all the rules. Eventually the equals tests (I believe after iteration 2) NPE when trying to deserialise the session. Identity has no issues and functions correctly. Let me know if you need anything else and please do let me know if there is a workaround. I am currently exploring the workaround avenue myself as well and will come back here with an update should I find one. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1097) Loading Session and running rules re-executes all rules

by Artur Kronenberg (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1097?page=com.atlassian.jira.plugi... ] Artur Kronenberg commented on DROOLS-1097: ------------------------------------------ This seems to directly be related to: equalsBehavior="equality" removing that fixes this. > Loading Session and running rules re-executes all rules > -------------------------------------------------------- > > Key: DROOLS-1097 > URL: https://issues.jboss.org/browse/DROOLS-1097 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final > Reporter: Artur Kronenberg > Assignee: Mario Fusco > Attachments: test-standalone.zip > > > This is possibly directly related to: (or rather that one relates to this one) > https://issues.jboss.org/browse/DROOLS-1093 > The situation: > * Create a session with 2 rules. 1 Rule expires facts that are in the working memory by retracting them. > * Add the ExpiryFact to expire some facts > * Execute all rules -> X facts get expired > * dispose the existing session > * re-load the session > * without adding more facts to the working memory, run all rules > * The session re-executes more rules and retracts things from memory > Now there seem to be 2 problems with this: > 1. The session does not remember what facts it expired. So it will delete more infos, that are still "somewhere". When re-loading the session from the database, we will see an NPE > 2. Surely since it already ran the rules against the Expiry fact, it should not run them again. > I will attach a unit test ExceptionTest#testRulesAreFiredTwice with this bug. > Let me know if this can be worked around please and/or if there are any more questions. > Thanks, > Artur -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-6402: ------------------------------- Attachment: auto-test-reproducer.zip Deploy the client.jar & singleton.jar. The ClientSingleton in client.jar will attempt to invoke the Stateless EJB in singleton.jar, there is a SIngleton inside of singleton.jar also which will sleep for 60 sec in PostConstruct, according to the EJB spec, the container must initialize all Singletons with @Startup before allowing external requests to be made to any of the other EJBs in singleton.jar I have the Singleton set a system property once it finishes and when the Stateless is invoked it will check the system property, if it is not set to true, it will log an error indicating that it was invoked prior to the Singleton PostConstruct finishing. > EJBs accessible too early (spec violation) > ------------------------------------------ > > Key: WFLY-6402 > URL: https://issues.jboss.org/browse/WFLY-6402 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Brad Maxwell > Attachments: auto-test-reproducer.zip > > > {code} > EJB 3.1 spec, section 4.8.1: > "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {code} > Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6403) EJBs accessible too early (spec violation)

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-6403: ---------------------------------- Summary: EJBs accessible too early (spec violation) Key: WFLY-6403 URL: https://issues.jboss.org/browse/WFLY-6403 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 10.0.0.Final Reporter: Brad Maxwell {code} EJB 3.1 spec, section 4.8.1: "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. {code} Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-6402: ---------------------------------- Summary: EJBs accessible too early (spec violation) Key: WFLY-6402 URL: https://issues.jboss.org/browse/WFLY-6402 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 10.0.0.Final Reporter: Brad Maxwell {code} EJB 3.1 spec, section 4.8.1: "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. {code} Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1097) Loading Session and running rules re-executes all rules

by Artur Kronenberg (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1097?page=com.atlassian.jira.plugi... ] Artur Kronenberg updated DROOLS-1097: ------------------------------------- Issue Type: Bug (was: Feature Request) > Loading Session and running rules re-executes all rules > -------------------------------------------------------- > > Key: DROOLS-1097 > URL: https://issues.jboss.org/browse/DROOLS-1097 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final > Reporter: Artur Kronenberg > Assignee: Mario Fusco > Attachments: test-standalone.zip > > > This is possibly directly related to: (or rather that one relates to this one) > https://issues.jboss.org/browse/DROOLS-1093 > The situation: > * Create a session with 2 rules. 1 Rule expires facts that are in the working memory by retracting them. > * Add the ExpiryFact to expire some facts > * Execute all rules -> X facts get expired > * dispose the existing session > * re-load the session > * without adding more facts to the working memory, run all rules > * The session re-executes more rules and retracts things from memory > Now there seem to be 2 problems with this: > 1. The session does not remember what facts it expired. So it will delete more infos, that are still "somewhere". When re-loading the session from the database, we will see an NPE > 2. Surely since it already ran the rules against the Expiry fact, it should not run them again. > I will attach a unit test ExceptionTest#testRulesAreFiredTwice with this bug. > Let me know if this can be worked around please and/or if there are any more questions. > Thanks, > Artur -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1097) Loading Session and running rules re-executes all rules

by Artur Kronenberg (JIRA)

Artur Kronenberg created DROOLS-1097: ---------------------------------------- Summary: Loading Session and running rules re-executes all rules Key: DROOLS-1097 URL: https://issues.jboss.org/browse/DROOLS-1097 Project: Drools Issue Type: Feature Request Components: core engine Affects Versions: 6.3.0.Final Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final Reporter: Artur Kronenberg Assignee: Mario Fusco Attachments: test-standalone.zip This is possibly directly related to: (or rather that one relates to this one) https://issues.jboss.org/browse/DROOLS-1093 The situation: * Create a session with 2 rules. 1 Rule expires facts that are in the working memory by retracting them. * Add the ExpiryFact to expire some facts * Execute all rules -> X facts get expired * dispose the existing session * re-load the session * without adding more facts to the working memory, run all rules * The session re-executes more rules and retracts things from memory Now there seem to be 2 problems with this: 1. The session does not remember what facts it expired. So it will delete more infos, that are still "somewhere". When re-loading the session from the database, we will see an NPE 2. Surely since it already ran the rules against the Expiry fact, it should not run them again. I will attach a unit test ExceptionTest#testRulesAreFiredTwice with this bug. Let me know if this can be worked around please and/or if there are any more questions. Thanks, Artur -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1440) Expression resolver breaks return value for empty lists

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-1440: ----------------------------------- Summary: Expression resolver breaks return value for empty lists Key: WFCORE-1440 URL: https://issues.jboss.org/browse/WFCORE-1440 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.1.0.CR1 Reporter: Tomaz Cerar Assignee: Tomaz Cerar ExpressionResolverImpl#resolveExpressionsRecursively does {code} else if (type == ModelType.LIST) { resolved = node.clone(); ModelNode list = new ModelNode(); for (ModelNode current : resolved.asList()) { list.add(resolveExpressionsRecursively(current)); } resolved = list; } {code} for list attributes, but in case that resolved value is empty list it would return list that is undefined instead of empty list. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1439) Allow for testsuite to pass on French OS

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1439?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet updated WFCORE-1439: -------------------------------------- Summary: Allow for testsuite to pass on French OS (was: Allow for testsuite to pass on french OS) > Allow for testsuite to pass on French OS > ---------------------------------------- > > Key: WFCORE-1439 > URL: https://issues.jboss.org/browse/WFCORE-1439 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.1.0.CR1 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Minor > > Some tests are checking failure message or exception message as if the Locale is always English. Fixing those -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2016