August 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-352) Add sufficient TRACE / DEBUG logging to debug security realm configurations.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-352?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-352: ---------------------------------------------- James Livingston <jlivings(a)redhat.com> made a comment on [bug 974324|https://bugzilla.redhat.com/show_bug.cgi?id=974324] Upstream changes are at https://github.com/wildfly/wildfly/commit/3948c15fa6d9a4054aab3b16496be12... > Add sufficient TRACE / DEBUG logging to debug security realm configurations. > ---------------------------------------------------------------------------- > > Key: WFLY-352 > URL: https://issues.jboss.org/browse/WFLY-352 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Eric Rich > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Beta1 > > Attachments: jboss-as-domain-management-7.1.2.Final-redhat-1.jar, log_mgmt_auth_calls.txt > > > When trying to diagnose LDAP or Admin Configuration issue in Domain mode there is currently no logging for any of the authentication information. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of Transaction isn't stable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1070?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1070: ------------------------------------------------ Jesper Pedersen <jpederse(a)redhat.com> changed the Status of [bug 999522|https://bugzilla.redhat.com/show_bug.cgi?id=999522] from NEW to POST > Memory leak if hashCode of Transaction isn't stable > --------------------------------------------------- > > Key: JBJCA-1070 > URL: https://issues.jboss.org/browse/JBJCA-1070 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.19.Final, 1.1.0.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.20.Final, 1.1.1.Final > > > Happens in TransactionSynchronizer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1351) Incorrect exception handling in CoreGroupCommunicationService#handle

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1351?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1351: ----------------------------------------------- Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 963448|https://bugzilla.redhat.com/show_bug.cgi?id=963448] Technically, this issue is still relevant to 6.2 and 6.3, as this class will continue to exist. However, the plan for EAP 6.3 is to drop usage of this object for locking web sessions. > Incorrect exception handling in CoreGroupCommunicationService#handle > -------------------------------------------------------------------- > > Key: WFLY-1351 > URL: https://issues.jboss.org/browse/WFLY-1351 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Dennis Reed > Assignee: Paul Ferraro > Fix For: 8.0.0.Alpha3 > > > org/jboss/as/clustering/impl/CoreGroupCommunicationService#handle catches and hides any internal exceptions, and just returns null instead. > This breaks callers of CoreGroupCommunicationService when they get a null value where it's not expected (after verifying that the response was not flagged as an exception) > java.lang.NullPointerException > at org.jboss.as.clustering.lock.AbstractClusterLockSupport.lock(AbstractClusterLockSupport.java:157) > It also catches an exception from the called method, and returns it as the return value, instead of just throwing it as an exception so it can be properly returned as an exception inside JGroups' RequestCorrelator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of Transaction isn't stable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1070?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1070: ------------------------------------------------ Jesper Pedersen <jpederse(a)redhat.com> made a comment on [bug 999522|https://bugzilla.redhat.com/show_bug.cgi?id=999522] https://github.com/jbossas/jboss-eap/pull/324 > Memory leak if hashCode of Transaction isn't stable > --------------------------------------------------- > > Key: JBJCA-1070 > URL: https://issues.jboss.org/browse/JBJCA-1070 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.19.Final, 1.1.0.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.20.Final, 1.1.1.Final > > > Happens in TransactionSynchronizer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1058) XAResource should have its timeout value resetted

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1058?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1058: ------------------------------------------------ Jesper Pedersen <jpederse(a)redhat.com> made a comment on [bug 999522|https://bugzilla.redhat.com/show_bug.cgi?id=999522] https://github.com/jbossas/jboss-eap/pull/324 > XAResource should have its timeout value resetted > ------------------------------------------------- > > Key: JBJCA-1058 > URL: https://issues.jboss.org/browse/JBJCA-1058 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.19.Final, 1.1.0.CR1 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.20.Final, 1.1.0.CR2 > > > Once the connection is returned to the pool -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-276) Using non-blocking thread pool causes excessive RejectedExecutionExceptions to be logged

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-276?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-276: ----------------------------------------------- James Livingston <jlivings(a)redhat.com> changed the Status of [bug 985191|https://bugzilla.redhat.com/show_bug.cgi?id=985191] from NEW to MODIFIED > Using non-blocking thread pool causes excessive RejectedExecutionExceptions to be logged > ---------------------------------------------------------------------------------------- > > Key: JBWEB-276 > URL: https://issues.jboss.org/browse/JBWEB-276 > Project: JBoss Web > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: JBossWeb-7.2.0.Beta1 > Reporter: James Livingston > Assignee: Remy Maucherat > Attachments: JBWEB-276-1.patch, JBWEB-276-2.patch > > > When a finite-queue thread pool is used to process web requests, the queue being full can either block or drop the request. If you use a pool which drops requests, a RejectedExecutionException is thrown. > Currently JIoEndpoint catches that exception the same as other ones such as being unable to create threads. When using a non-blocking pool, the task being rejected is not a critical error like other exceptions so should not be logged at ERROR level. > Under excessive load, these exception will be continuously generated as requests are dropped, which cases a large amount of logging. Setting it to DEBUG level would stop that, but it would hide the potentially useful messages by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute to size-rotating-file-handler

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1971?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1971: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=999665 > Add rotate-on-boot attribute to size-rotating-file-handler > ---------------------------------------------------------- > > Key: WFLY-1971 > URL: https://issues.jboss.org/browse/WFLY-1971 > Project: WildFly > Issue Type: Feature Request > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-789) HornetQ native library(AIO) are loaded by default - for transaction manager using hornetq object store

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-789?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-789: ---------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 913117|https://bugzilla.redhat.com/show_bug.cgi?id=913117] from ASSIGNED to POST > HornetQ native library(AIO) are loaded by default - for transaction manager using hornetq object store > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-789 > URL: https://issues.jboss.org/browse/WFLY-789 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 8.0.0.Alpha1 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 8.0.0.Beta1 > > > The issue cloned for upstream from an EAP6 bugzilla. > original description: > {quote} > It seems that in case that of using hornetq for implementation of object store (configuration of transaction subsystem via <use-hornetq-store/> tag) the native library (AIO) is used automatically without necessity of user confirmation. > For EAP 6.0.1 was decided that native library can't be used without explicit customer configuration request. Please check discussion on bug #900591. > The NIO should be used until customer defined otherwise. > The configuration option is missing in TM and after the adding it the EAP configuration should reflect fact that the default behaviour should be NIO. > {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1058) XAResource should have its timeout value resetted

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1058?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1058: ------------------------------------------------ Jesper Pedersen <jpederse(a)redhat.com> changed the Status of [bug 999522|https://bugzilla.redhat.com/show_bug.cgi?id=999522] from NEW to POST > XAResource should have its timeout value resetted > ------------------------------------------------- > > Key: JBJCA-1058 > URL: https://issues.jboss.org/browse/JBJCA-1058 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.19.Final, 1.1.0.CR1 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.20.Final, 1.1.0.CR2 > > > Once the connection is returned to the pool -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1972) CLI command should not allow same runtime-name to be used at another deploy

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1972?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1972: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=983980 > CLI command should not allow same runtime-name to be used at another deploy > --------------------------------------------------------------------------- > > Key: WFLY-1972 > URL: https://issues.jboss.org/browse/WFLY-1972 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Emmanuel Hugonnet > Assignee: Brian Stansberry > > Having two deployments with the same runtime-name in the domain content repository, so they can be deployed to different instances, is ok. > Having two deployments with the same runtime name actually deployed to an instance is not (that's the issue here). > Same for standalone. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

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 August 2013