October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3927) Upgrade HAL to 2.4.2.Final

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-3927?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-3927: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6757) > Upgrade HAL to 2.4.2.Final > -------------------------- > > Key: WFLY-3927 > URL: https://issues.jboss.org/browse/WFLY-3927 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3927) Upgrade HAL to 2.4.2.Final

by Harald Pehl (JIRA)

Harald Pehl created WFLY-3927: --------------------------------- Summary: Upgrade HAL to 2.4.2.Final Key: WFLY-3927 URL: https://issues.jboss.org/browse/WFLY-3927 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 8.2.0.CR1 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3926) Upgrade HAL to 2.4.2.Final

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-3926?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-3926: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6756) > Upgrade HAL to 2.4.2.Final > -------------------------- > > Key: WFLY-3926 > URL: https://issues.jboss.org/browse/WFLY-3926 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3926) Upgrade HAL to 2.4.2.Final

by Harald Pehl (JIRA)

Harald Pehl created WFLY-3926: --------------------------------- Summary: Upgrade HAL to 2.4.2.Final Key: WFLY-3926 URL: https://issues.jboss.org/browse/WFLY-3926 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[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)

10 years

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)

10 years

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)

10 years

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)

10 years

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)

10 years

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)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2014