March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4457) EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4457?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-4457: ------------------------------ Component/s: EE Web (Undertow) > EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope > ------------------------------------------------------------------------------------ > > Key: WFLY-4457 > URL: https://issues.jboss.org/browse/WFLY-4457 > Project: WildFly > Issue Type: Bug > Components: EE, Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Paul Pogonyshev > Assignee: Tomaz Cerar > Labels: el-expresion, patch > Attachments: lambda-expression-scoping-fix.diff > > > When a lambda expression is exited with an exception, its variables are left on stack and cannot be removed from it without hacks. My usecase is a customly defined function that uses exceptions as means of non-local exit, but the bug triggers even without custom functions, as demonstrated below. > Test case: > {noformat} > ELProcessor processor = new ELProcessor (); > processor.defineBean ("x", null); > try { > processor.eval ("(x -> x.bug ()) ('bug')"); > } > catch (RuntimeException exception) { > // This is expected, there is no method bug() on strings. > } > processor.eval ("x"); // This must evaluate to null, but instead evaluates to "bug". > {noformat} > Proposed fix will be attached as a short patch against 'javax/el/LambdaExpression.java'. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4458) Please backport the log4j2 support fixed in WFLY-4089 to 8.x

by Robert Andersson (JIRA)

Robert Andersson created WFLY-4458: -------------------------------------- Summary: Please backport the log4j2 support fixed in WFLY-4089 to 8.x Key: WFLY-4458 URL: https://issues.jboss.org/browse/WFLY-4458 Project: WildFly Issue Type: Bug Reporter: Robert Andersson Assignee: Jason Greene We need to stay on the 8.2 branch for now, but would like to use log4j2. If/when you relase another version from the 8.x branch, please backport the simple fix needed for log4j2 support. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-605) MORE_JAVA_OPTS for standalone.sh

by Fernando Nasser (JIRA)

[ https://issues.jboss.org/browse/WFCORE-605?page=com.atlassian.jira.plugin... ] Fernando Nasser commented on WFCORE-605: ---------------------------------------- It should remain WILDFLY. It is still WILDFLY no matter in which product or larger project it is included. As an example, until Java EE 6 we had several hibernate_ switches in the persistence.xml file (as the JPA implementation came from Hibernate and there was no equivalent JPA switches). I expect to see "Wildly" in many places actually. > MORE_JAVA_OPTS for standalone.sh > -------------------------------- > > Key: WFCORE-605 > URL: https://issues.jboss.org/browse/WFCORE-605 > Project: WildFly Core > Issue Type: Feature Request > Components: Scripts > Reporter: Arun Gupta > > Extend standalone.sh such that it takes an additional environment variable that is then added to JAVA_OPTS during startup. > This can be used for passing additional Java options from WildFly > Docker image. Cursory look at the script does not reveal anything like > that exist. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1254) Tracer improvements

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1254?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1254. ------------------------------------ Resolution: Done > Tracer improvements > ------------------- > > Key: JBJCA-1254 > URL: https://issues.jboss.org/browse/JBJCA-1254 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.2.3.Final > > > Add the following events: > * CREATE_CONNECTION_LISTENER_GET > * CREATE_CONNECTION_LISTENER_PREFILL > * CREATE_CONNECTION_LISTENER_INCREMENTER > * DESTROY_CONNECTION_LISTENER_RETURN > * DESTROY_CONNECTION_LISTENER_IDLE > * DESTROY_CONNECTION_LISTENER_INVALID > * DESTROY_CONNECTION_LISTENER_FLUSH > * DESTROY_CONNECTION_LISTENER_ERROR > * MANAGED_CONNECTION_POOL_CREATE > * MANAGED_CONNECTION_POOL_DESTROY > Also add the ManagedConnectionPool instance information to each event, and use this for a lifecycle report. > Switch timestamps to nano. > Add the raw events to raw.txt -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1252) MCPs can become detached

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1252?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1252. ------------------------------------ Resolution: Done > MCPs can become detached > ------------------------ > > Key: JBJCA-1252 > URL: https://issues.jboss.org/browse/JBJCA-1252 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.31.Final, 1.1.9.Final, 1.2.2.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: 1.0.32.Final, 1.1.10.Final, 1.2.3.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4457) EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope

by Paul Pogonyshev (JIRA)

[ https://issues.jboss.org/browse/WFLY-4457?page=com.atlassian.jira.plugin.... ] Paul Pogonyshev updated WFLY-4457: ---------------------------------- Description: When a lambda expression is exited with an exception, its variables are left on stack and cannot be removed from it without hacks. My usecase is a customly defined function that uses exceptions as means of non-local exit, but the bug triggers even without custom functions, as demonstrated below. Test case: {noformat} ELProcessor processor = new ELProcessor (); processor.defineBean ("x", null); try { processor.eval ("(x -> x.bug ()) ('bug')"); } catch (RuntimeException exception) { // This is expected, there is no method bug() on strings. } processor.eval ("x"); // This must evaluate to null, but instead evaluates to "bug". {noformat} Proposed fix will be attached as a short patch against 'javax/el/LambdaExpression.java'. was: When a lambda expression is exited with an exception, its variables are left on stack and cannot be removed from it without hacks. My usecase is a customly defined function that uses exceptions as means of non-local exit, but the bug triggers even without custom functions, as demonstrated below. Test case: ELProcessor processor = new ELProcessor (); processor.defineBean ("x", null); try { processor.eval ("(x -> x.bug ()) ('bug')"); } catch (RuntimeException exception) { // This is expected, there is no method bug() on strings. } processor.eval ("x"); // This must evaluate to null, but instead evaluates to "bug". Proposed fix will be attached as a short patch against 'javax/el/LambdaExpression.java'. > EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope > ------------------------------------------------------------------------------------ > > Key: WFLY-4457 > URL: https://issues.jboss.org/browse/WFLY-4457 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.2.0.Final > Reporter: Paul Pogonyshev > Assignee: Jason Greene > Labels: el-expresion, patch > Attachments: lambda-expression-scoping-fix.diff > > > When a lambda expression is exited with an exception, its variables are left on stack and cannot be removed from it without hacks. My usecase is a customly defined function that uses exceptions as means of non-local exit, but the bug triggers even without custom functions, as demonstrated below. > Test case: > {noformat} > ELProcessor processor = new ELProcessor (); > processor.defineBean ("x", null); > try { > processor.eval ("(x -> x.bug ()) ('bug')"); > } > catch (RuntimeException exception) { > // This is expected, there is no method bug() on strings. > } > processor.eval ("x"); // This must evaluate to null, but instead evaluates to "bug". > {noformat} > Proposed fix will be attached as a short patch against 'javax/el/LambdaExpression.java'. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4457) EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope

by Paul Pogonyshev (JIRA)

[ https://issues.jboss.org/browse/WFLY-4457?page=com.atlassian.jira.plugin.... ] Paul Pogonyshev updated WFLY-4457: ---------------------------------- Attachment: lambda-expression-scoping-fix.diff Simple patch to ensure that exitLambdaScope() is executed after lambda expression invocation even when it is exited with an exception. > EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope > ------------------------------------------------------------------------------------ > > Key: WFLY-4457 > URL: https://issues.jboss.org/browse/WFLY-4457 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.2.0.Final > Reporter: Paul Pogonyshev > Assignee: Jason Greene > Labels: el-expresion, patch > Attachments: lambda-expression-scoping-fix.diff > > > When a lambda expression is exited with an exception, its variables are left on stack and cannot be removed from it without hacks. My usecase is a customly defined function that uses exceptions as means of non-local exit, but the bug triggers even without custom functions, as demonstrated below. > Test case: > ELProcessor processor = new ELProcessor (); > processor.defineBean ("x", null); > try { > processor.eval ("(x -> x.bug ()) ('bug')"); > } > catch (RuntimeException exception) { > // This is expected, there is no method bug() on strings. > } > processor.eval ("x"); // This must evaluate to null, but instead evaluates to "bug". > Proposed fix will be attached as a short patch against 'javax/el/LambdaExpression.java'. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4457) EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope

by Paul Pogonyshev (JIRA)

Paul Pogonyshev created WFLY-4457: ------------------------------------- Summary: EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope Key: WFLY-4457 URL: https://issues.jboss.org/browse/WFLY-4457 Project: WildFly Issue Type: Bug Affects Versions: 8.2.0.Final Reporter: Paul Pogonyshev Assignee: Jason Greene When a lambda expression is exited with an exception, its variables are left on stack and cannot be removed from it without hacks. My usecase is a customly defined function that uses exceptions as means of non-local exit, but the bug triggers even without custom functions, as demonstrated below. Test case: ELProcessor processor = new ELProcessor (); processor.defineBean ("x", null); try { processor.eval ("(x -> x.bug ()) ('bug')"); } catch (RuntimeException exception) { // This is expected, there is no method bug() on strings. } processor.eval ("x"); // This must evaluate to null, but instead evaluates to "bug". Proposed fix will be attached as a short patch against 'javax/el/LambdaExpression.java'. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-748) MultithreadTest.testSlidingTimeWindows() uses unreliable Thread.sleep(1).

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-748?page=com.atlassian.jira.plugin... ] Tibor Zimányi updated DROOLS-748: --------------------------------- Git Pull Request: https://github.com/droolsjbpm/drools/pull/422 > MultithreadTest.testSlidingTimeWindows() uses unreliable Thread.sleep(1). > ------------------------------------------------------------------------- > > Key: DROOLS-748 > URL: https://issues.jboss.org/browse/DROOLS-748 > Project: Drools > Issue Type: Bug > Reporter: Tibor Zimányi > Assignee: Mark Proctor > Priority: Minor > > In MultithreadTest classes (there are two of them) method testSlidingTimeWindows() uses unreliable Thread.sleep(1) call for waiting for fact insertion. Thread.sleep(1) doesn't wait for exactly 1 millisecond, because there is overhead from thread scheduler. This overhead can be pretty large in contrast to expected 1ms sleep. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-748) MultithreadTest.testSlidingTimeWindows() uses unreliable Thread.sleep(1).

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-748: ------------------------------------ Summary: MultithreadTest.testSlidingTimeWindows() uses unreliable Thread.sleep(1). Key: DROOLS-748 URL: https://issues.jboss.org/browse/DROOLS-748 Project: Drools Issue Type: Bug Reporter: Tibor Zimányi Assignee: Mark Proctor Priority: Minor In MultithreadTest classes (there are two of them) method testSlidingTimeWindows() uses unreliable Thread.sleep(1) call for waiting for fact insertion. Thread.sleep(1) doesn't wait for exactly 1 millisecond, because there is overhead from thread scheduler. This overhead can be pretty large in contrast to expected 1ms sleep. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 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 March 2015