October 2014 - jboss-jira - Jboss List Archives

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

10 years

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)

10 years

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)

10 years

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)

10 years

1
0
0 / 0

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

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3925?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-3925: ------------------------------ Steps to Reproduce: 1. Create this test bean: {code} @Path("/test2") @Stateless public class Test2 { @GET public String hello() { return "hello !"; } @PostConstruct protected void postConstruct() { System.out.println("Test2().postConstruct() " + this); } @PreDestroy protected void preDestroy() { System.out.println("Test2().preDestroy() " + this); } } {code} 2. Hit the URL (ex: http://localhost:8080/TestRest3/rest/test2) and look at the server output, something like this will show: {noformat} 16:21:46,430 INFO [stdout] (default task-41) Test1().postConstruct() test.Test2@890a1e2 16:21:46,432 INFO [stdout] (default task-41) Test1().preDestroy() test.Test2@890a1e2 {noformat} AFAIK SLSB shouldn't be destroyed after service request. was: 1. Create this test bean: @Path("/test2") @Stateless public class Test2 { @GET public String hello() { return "hello !"; } @PostConstruct protected void postConstruct() { System.out.println("Test2().postConstruct() " + this); } @PreDestroy protected void preDestroy() { System.out.println("Test2().preDestroy() " + this); } } 2. Hit the URL (ex: http://localhost:8080/TestRest3/rest/test2) and look at the server output, something like this will show: 16:21:46,430 INFO [stdout] (default task-41) Test1().postConstruct() test.Test2@890a1e2 16:21:46,432 INFO [stdout] (default task-41) Test1().preDestroy() test.Test2@890a1e2 AFAIK SLSB shouldn't be destroyed after service request. > 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-3925) JAX-RS bean implemented as Stateless is destroyed after response

by Sergio Samayoa (JIRA)

[ https://issues.jboss.org/browse/WFLY-3925?page=com.atlassian.jira.plugin.... ] Sergio Samayoa updated WFLY-3925: --------------------------------- Description: A JAX-RS bean implemented as stateless EJB is destroyed after response is sent. Steps to Reproduce: 1. Create this test bean: @Path("/test2") @Stateless public class Test2 { @GET public String hello() { return "hello !"; } @PostConstruct protected void postConstruct() { System.out.println("Test2().postConstruct() " + this); } @PreDestroy protected void preDestroy() { System.out.println("Test2().preDestroy() " + this); } } 2. Hit the URL (ex: http://localhost:8080/TestRest3/rest/test2) and look at the server output, something like this will show: 16:21:46,430 INFO [stdout] (default task-41) Test1().postConstruct() test.Test2@890a1e2 16:21:46,432 INFO [stdout] (default task-41) Test1().preDestroy() test.Test2@890a1e2 AFAIK SLSB shouldn't be destroyed after service request. Affects Version/s: 8.1.0.Final > 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-3925) JAX-RS bean implemented as Stateless is destroyed after response

by Sergio Samayoa (JIRA)

Sergio Samayoa created WFLY-3925: ------------------------------------ Summary: 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 Reporter: Sergio Samayoa Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3924) Facility to suppress interruption on EJB methods

by David Lloyd (JIRA)

David Lloyd created WFLY-3924: --------------------------------- Summary: Facility to suppress interruption on EJB methods Key: WFLY-3924 URL: https://issues.jboss.org/browse/WFLY-3924 Project: WildFly Issue Type: Enhancement Components: EJB Reporter: David Lloyd Assignee: David Lloyd Priority: Optional We should provide an annotation to mark an EJB method as uninterruptible, which prevents interruption from being delivered to the thread during the invocation (via forthcoming mechanism in JBoss Threads). Or, this could be a CDI facility, or both. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3923) Option for suppressing thread interruption during JDBC driver operations

by David Lloyd (JIRA)

David Lloyd created WFLY-3923: --------------------------------- Summary: Option for suppressing thread interruption during JDBC driver operations Key: WFLY-3923 URL: https://issues.jboss.org/browse/WFLY-3923 Project: WildFly Issue Type: Enhancement Components: JCA Reporter: David Lloyd Assignee: Jesper Pedersen Fix For: 9.0.0.CR1 The data source and JCA subsystems should provide a facility to suppress thread interruption during driver operations. The data source attribute should have values "on", "off", and "auto", where "auto" indicates that the subsystem should make a decision based on the driver. A list of drivers which are known to fail in the presence of interruption is forthcoming. A facility in JBoss Threads to suppress interruption for the duration of a task is forthcoming. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3922) Add a CheckedAction to each transaction upon creation/inflow to interrupt the transaction's associated threads

by David Lloyd (JIRA)

David Lloyd created WFLY-3922: --------------------------------- Summary: Add a CheckedAction to each transaction upon creation/inflow to interrupt the transaction's associated threads Key: WFLY-3922 URL: https://issues.jboss.org/browse/WFLY-3922 Project: WildFly Issue Type: Enhancement Components: Transactions Reporter: David Lloyd Assignee: Tom Jenkinson Fix For: 9.0.0.CR1 This will allow the application to receive a notification on transaction timeout or termination. -- 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