October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3632) @Inject broken for parameterized interfaces

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-3632?page=com.atlassian.jira.plugin.... ] Jozef Hartinger resolved WFLY-3632. ----------------------------------- Fix Version/s: 8.2.0.CR1 9.0.0.Beta1 Resolution: Done > @Inject broken for parameterized interfaces > ------------------------------------------- > > Key: WFLY-3632 > URL: https://issues.jboss.org/browse/WFLY-3632 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Environment: Wildfly 8.1.0Final (tested on MacOS X 10.9.3) > Reporter: Alexander Langer > Assignee: Jozef Hartinger > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > Attachments: CDIMultiModuleTest.zip, CDIMultiModuleTest.zip, server.log > > > @Inject is broken on Wildfly 8.1.0 Final when the interface to be injected is parameterized with a type that extends another type. Example code: > {code} > public interface Foo<T extends Serializable> { } // will fail > public class FooBean implements Foo { } > public interface Bar<T> { } // will work > public class BarBean implements Bar { } > @Singleton > @Startup > public class TestSingleton { > @Inject > private Instance<Foo> foo; > @Inject > private Instance<Bar> bar; > @PostConstruct > public void init() { > System.out.println("##### foo is unsatisfied = " + foo.isUnsatisfied()); > for (Foo f : foo) > System.out.println("foo is: " + f.getClass().getCanonicalName()); > System.out.println("##### bar is unsatisfied = " + bar.isUnsatisfied()); > for (Bar b : bar) > System.out.println("bar is: " + b.getClass().getCanonicalName()); > } > } > {code} > output: > {code} > 22:30:25,904 INFO [stdout] (ServerService Thread Pool -- 50) ##### foo is unsatisfied = true > 22:30:25,905 INFO [stdout] (ServerService Thread Pool -- 50) ##### bar is unsatisfied = false > {code} > The same code works on JBoss AS 7.1.1, so something must have changed for Wildfly. > The attached small example project can be used to reproduce the error. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-623) Rule with NOT causes excessive firing of the rule

by Anantjot Anand (JIRA)

[ https://issues.jboss.org/browse/DROOLS-623?page=com.atlassian.jira.plugin... ] Anantjot Anand updated DROOLS-623: ---------------------------------- Description: Debugging of the issue points to De-Activation not able to happen due to RuleExecutor not set dirty upon the call made to BetaNode [line: 369] - doDeleteRightTuple(RightTuple, InternalWorkingMemory, BetaMemory) during reEvaluateNetwork after first time fire of the rule. Further drilling into doDeleteRightTuple indicates memory.unlinkNode(wm) call fails in PathMemory.unlinkedSegment as it finds the isRuleLinked() to be false. if (linkedRule && !isRuleLinked()) { doUnlinkRule(wm); } Please see the attached junit test case reproducing the issue. There are two rules R1 and R2. R1 sets up criteria needed by R2. There are two changes that make this issue not appear. 1) Setting the value required by (inside the NOT clause) rule before calling fireAllRules. 2) Removing the NOT clause from R2. was: Debugging of the issue points to De-Activation not able to happen due to RuleExecutor not set dirty upon the call made to BetaNode [line: 369] - doDeleteRightTuple(RightTuple, InternalWorkingMemory, BetaMemory) during reEvaluateNetwork after first time fire of the rule. Further drilling into doDeleteRightTuple indicates Please see the attached junit test case reproducing the issue. There are two rules R1 and R2. R1 sets up criteria needed by R2. There are two changes that make this issue not appear. 1) Setting the value required by (inside the NOT clause) rule before calling fireAllRules. 2)Removing the NOT clause from R2. > Rule with NOT causes excessive firing of the rule > ------------------------------------------------- > > Key: DROOLS-623 > URL: https://issues.jboss.org/browse/DROOLS-623 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.Beta1 > Reporter: Anantjot Anand > Assignee: Mark Proctor > Attachments: TestNotSubnetworkIssue.java > > > Debugging of the issue points to De-Activation not able to happen due to RuleExecutor not set dirty upon the call made to BetaNode [line: 369] - doDeleteRightTuple(RightTuple, InternalWorkingMemory, BetaMemory) during reEvaluateNetwork after first time fire of the rule. Further drilling into doDeleteRightTuple indicates memory.unlinkNode(wm) call fails in > PathMemory.unlinkedSegment as it finds the isRuleLinked() to be false. > if (linkedRule && !isRuleLinked()) { > doUnlinkRule(wm); > } > Please see the attached junit test case reproducing the issue. There are two rules R1 and R2. R1 sets up criteria needed by R2. > There are two changes that make this issue not appear. > 1) Setting the value required by (inside the NOT clause) rule before calling fireAllRules. > 2) Removing the NOT clause from R2. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-623) Rule with NOT causes excessive firing of the rule

by Anantjot Anand (JIRA)

[ https://issues.jboss.org/browse/DROOLS-623?page=com.atlassian.jira.plugin... ] Anantjot Anand updated DROOLS-623: ---------------------------------- Attachment: TestNotSubnetworkIssue.java > Rule with NOT causes excessive firing of the rule > ------------------------------------------------- > > Key: DROOLS-623 > URL: https://issues.jboss.org/browse/DROOLS-623 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.Beta1 > Reporter: Anantjot Anand > Assignee: Mark Proctor > Attachments: TestNotSubnetworkIssue.java > > > Debugging of the issue points to De-Activation not able to happen due to RuleExecutor not set dirty upon the call made to BetaNode [line: 369] - doDeleteRightTuple(RightTuple, InternalWorkingMemory, BetaMemory) during reEvaluateNetwork after first time fire of the rule. Further drilling into doDeleteRightTuple indicates > Please see the attached junit test case reproducing the issue. There are two rules R1 and R2. R1 sets up criteria needed by R2. > There are two changes that make this issue not appear. > 1) Setting the value required by (inside the NOT clause) rule before calling fireAllRules. > 2)Removing the NOT clause from R2. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-623) Rule with NOT causes excessive firing of the rule

by Anantjot Anand (JIRA)

Anantjot Anand created DROOLS-623: ------------------------------------- Summary: Rule with NOT causes excessive firing of the rule Key: DROOLS-623 URL: https://issues.jboss.org/browse/DROOLS-623 Project: Drools Issue Type: Bug Affects Versions: 6.2.0.Beta1, 6.1.0.Final Reporter: Anantjot Anand Assignee: Mark Proctor Debugging of the issue points to De-Activation not able to happen due to RuleExecutor not set dirty upon the call made to BetaNode [line: 369] - doDeleteRightTuple(RightTuple, InternalWorkingMemory, BetaMemory) during reEvaluateNetwork after first time fire of the rule. Further drilling into doDeleteRightTuple indicates Please see the attached junit test case reproducing the issue. There are two rules R1 and R2. R1 sets up criteria needed by R2. There are two changes that make this issue not appear. 1) Setting the value required by (inside the NOT clause) rule before calling fireAllRules. 2)Removing the NOT clause from R2. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3925) JAX-RS bean implemented as Stateless is destroyed after response

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3925?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-3925. ---------------------------------- Resolution: Rejected 8.1 no longer pools stateless beans by default. If you want pooling behaviour configure a pool in the ejb subsystem. > JAX-RS bean implemented as Stateless is destroyed after response > ---------------------------------------------------------------- > > Key: WFLY-3925 > URL: https://issues.jboss.org/browse/WFLY-3925 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Sergio Samayoa > Assignee: Jason Greene > > A JAX-RS bean implemented as stateless EJB is destroyed after response is sent. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3901) Please add the "relative-to" attribute to access-log in undertow

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3901?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-3901: ------------------------------------ Assignee: Tomaz Cerar (was: Stuart Douglas) > Please add the "relative-to" attribute to access-log in undertow > ---------------------------------------------------------------- > > Key: WFLY-3901 > URL: https://issues.jboss.org/browse/WFLY-3901 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Carlton Zachary > Assignee: Tomaz Cerar > > I have been trying to point the "directory" attribute value to a var ${custom.jboss.server.log.dir} to write the access.log to a non-default location, but this diesn't work in undertow. It does work in EAP 6.2 JBoss-web. The custom.jboss.server.log.dir is defined in the "<paths>" in the servers section of the host-slave.xml file. > In JBoss EAP 6.2 with jboss-web the access-log has the "relative-to" attribute, but this is not the case with access-log for undertow in WFLY 8.1. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-95) Log4j Logger.getParent() inconsistent

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on LOGMGR-95: ----------------------------------------------- James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1079106|https://bugzilla.redhat.com/show_bug.cgi?id=1079106] from NEW to POST > Log4j Logger.getParent() inconsistent > ------------------------------------- > > Key: LOGMGR-95 > URL: https://issues.jboss.org/browse/LOGMGR-95 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Livingston > Assignee: James Perkins > > Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in. > Consider: > Logger.getLogger("a"); > Logger.getLogger("a.b.c"); > Logger.getLogger("a.b"); > When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-138) Upgrade log4j-jboss-logmanager from 1.1.0.Final to 1.1.1.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-138?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-138: ------------------------------------------------ James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1148632|https://bugzilla.redhat.com/show_bug.cgi?id=1148632] from ASSIGNED to POST > Upgrade log4j-jboss-logmanager from 1.1.0.Final to 1.1.1.Final > -------------------------------------------------------------- > > Key: WFCORE-138 > URL: https://issues.jboss.org/browse/WFCORE-138 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha9 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-138) Upgrade log4j-jboss-logmanager from 1.1.0.Final to 1.1.1.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-138?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-138: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1148632 > Upgrade log4j-jboss-logmanager from 1.1.0.Final to 1.1.1.Final > -------------------------------------------------------------- > > Key: WFCORE-138 > URL: https://issues.jboss.org/browse/WFCORE-138 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha9 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2187) Make module and class writable attributes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2187?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2187: ----------------------------------------------- James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1013830|https://bugzilla.redhat.com/show_bug.cgi?id=1013830] from NEW to CLOSED > Make module and class writable attributes > ----------------------------------------- > > Key: WFLY-2187 > URL: https://issues.jboss.org/browse/WFLY-2187 > Project: WildFly > Issue Type: Feature Request > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 8.1.0.CR1, 8.1.0.Final > > > The {{class}} and {{module}} attributes on a {{custom-handler}} should be made writable. If changed the logmanager config API will just need to remove the original handler and add a new one. This may also need to check whether the handler is attached to a logger or other handlers. > If the add/remove won't work from the logmanager, then a {{reload}} should be required. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

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 October 2014