January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2716) Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2716?page=com.atlassian.jira.plugin.... ] James Perkins reassigned WFLY-2716: ----------------------------------- Assignee: James Perkins (was: David Lloyd) > Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled > ------------------------------------------------------------------------------- > > Key: WFLY-2716 > URL: https://issues.jboss.org/browse/WFLY-2716 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: EAP 6.1.0 and EAP 6.2.0 as well. > Reporter: Osamu Nagano > Assignee: James Perkins > > Web app's ModuleClassLoader is not released even after its undeployment. It seems {{contextMap}} of {{org.jboss.logmanager.ClassLoaderLogContextSelector}} object is holding the class loader's reference. If no logging-profile is configured, it doesn't leak. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2595) Logging DUP leaking class loaders

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2595?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2595: ----------------------------------------------- James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1049074|https://bugzilla.redhat.com/show_bug.cgi?id=1049074] from ASSIGNED to POST > Logging DUP leaking class loaders > --------------------------------- > > Key: WFLY-2595 > URL: https://issues.jboss.org/browse/WFLY-2595 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Fix For: 8.0.0.CR1 > > > When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL. > The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-90) Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-90?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated LOGMGR-90: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1049138 > Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled > ------------------------------------------------------------------------------- > > Key: LOGMGR-90 > URL: https://issues.jboss.org/browse/LOGMGR-90 > Project: JBoss Log Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.4.0.Final > Environment: EAP 6.1.0 and EAP 6.2.0 as well. > Reporter: Osamu Nagano > Assignee: David Lloyd > > Web app's ModuleClassLoader is not released even after its undeployment. It seems {{contextMap}} of {{org.jboss.logmanager.ClassLoaderLogContextSelector}} object is holding the class loader's reference. If no logging-profile is configured, it doesn't leak. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2595) Logging DUP leaking class loaders

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2595?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2595: ----------------------------------------------- James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1038305|https://bugzilla.redhat.com/show_bug.cgi?id=1038305] from NEW to POST > Logging DUP leaking class loaders > --------------------------------- > > Key: WFLY-2595 > URL: https://issues.jboss.org/browse/WFLY-2595 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Fix For: 8.0.0.CR1 > > > When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL. > The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-90) Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled

by Osamu Nagano (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-90?page=com.atlassian.jira.plugin.... ] Osamu Nagano commented on LOGMGR-90: ------------------------------------ Here is a GC root path from a web app's class loader. I can attach the heapdump if you like. {code} Class Name | Shallow Heap | Retained Heap ---------------------------------------------------------------------------------------------------------------------------------------------- org.jboss.modules.ModuleClassLoader @ 0xf94269b8 | 88 | 104,480 '- key org.jboss.logmanager.FastCopyHashMap$Entry @ 0xf9448fa0 | 24 | 24 '- [67] org.jboss.logmanager.FastCopyHashMap$Entry[128] @ 0xf94e12a0 | 528 | 912 '- table org.jboss.logmanager.FastCopyHashMap @ 0xf94e1268 | 56 | 968 '- map org.jboss.logmanager.CopyOnWriteMap @ 0xf8a1fba8 | 24 | 992 '- contextMap org.jboss.logmanager.ClassLoaderLogContextSelector @ 0xf8a1fb80 | 24 | 1,600 '- delegate org.jboss.logmanager.ThreadLocalLogContextSelector @ 0xf8a1fb68 | 24 | 24 '- logContextSelector class org.jboss.logmanager.LogContext @ 0xf8a1fad8 | 32 | 296 |- <class> org.jboss.logmanager.LogContext @ 0xf89978c8 | 40 | 104 | |- context org.jboss.logmanager.LoggerNode @ 0xf8027970 | 56 | 136 | | '- loggerNode org.jboss.logmanager.Logger @ 0xf802b5f8 | 72 | 160 | | '- MLET_LOGGER class com.sun.jmx.defaults.JmxProperties @ 0xf80282d0 System Class| 112 | 3,272 | |- ... | '- Total: 15 entries | | |- [6] java.lang.Object[160] @ 0xf8a0e408 | 656 | 3,536 | '- elementData java.util.Vector @ 0xf8a0e3e8 | 32 | 3,568 | '- classes org.jboss.modules.ModuleClassLoader @ 0xf8a0ddc8 | 88 | 30,456 | '- <classloader> class org.jboss.logmanager.LogManager @ 0xf8a49ca0 | 0 | 0 | '- <class> org.jboss.logmanager.LogManager @ 0xf899e7b0 | 48 | 1,288 | |- manager class java.util.logging.LogManager @ 0xf899e880 System Class | 24 | 24 | |- manager java.util.logging.Logger @ 0xf899f4f0 | 72 | 160 | | '- global class java.util.logging.Logger @ 0xf899f468 System Class | 24 | 56 ---------------------------------------------------------------------------------------------------------------------------------------------- {code} > Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled > ------------------------------------------------------------------------------- > > Key: LOGMGR-90 > URL: https://issues.jboss.org/browse/LOGMGR-90 > Project: JBoss Log Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.4.0.Final > Environment: EAP 6.1.0 and EAP 6.2.0 as well. > Reporter: Osamu Nagano > Assignee: David Lloyd > > Web app's ModuleClassLoader is not released even after its undeployment. It seems {{contextMap}} of {{org.jboss.logmanager.ClassLoaderLogContextSelector}} object is holding the class loader's reference. If no logging-profile is configured, it doesn't leak. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-90) Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled

by Osamu Nagano (JIRA)

Osamu Nagano created LOGMGR-90: ---------------------------------- Summary: Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled Key: LOGMGR-90 URL: https://issues.jboss.org/browse/LOGMGR-90 Project: JBoss Log Manager Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.0.Final Environment: EAP 6.1.0 and EAP 6.2.0 as well. Reporter: Osamu Nagano Assignee: David Lloyd Web app's ModuleClassLoader is not released even after its undeployment. It seems {{contextMap}} of {{org.jboss.logmanager.ClassLoaderLogContextSelector}} object is holding the class loader's reference. If no logging-profile is configured, it doesn't leak. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-722) SPNEGO-fallback-to-FORM authentication does not work with httpd+JBossEAP6 if SPNEGO not available

by Sean Flanigan (JIRA)

[ https://issues.jboss.org/browse/SECURITY-722?page=com.atlassian.jira.plug... ] Sean Flanigan commented on SECURITY-722: ---------------------------------------- This happened to us too. The problem is three-fold: 1. If httpd.conf has ProxyErrorOverride On, the 401 login form will be replaced with a custom error page. 2. org.jboss.security.negotiation.NegotiationAuthenticator apparently doesn't set a contentType for the 401 Response. 3. Apache httpd sees that the response has no Content-Type, and adds a Content-Type header using the DefaultType, which defaults to "text/plain". See http://httpd.apache.org/docs/2.2/mod/core.html#defaulttype So the workaround is to edit /etc/httpd/conf/httpd.conf, remove "ProxyErrorOverride On" and set "DefaultType none" instead of "DefaultType text/plain". Another option (instead of changing DefaultType) would be to override the method {{org.jboss.security.negotiation.NegotiationAuthenticator.authenticate()}} so that contentType is set to "text/html", and to activate it as a valve in jboss-web.xml: {{<valve><class-name>com.example.CustomNegotiationAuthenticator</class-name></valve>}} But it would be better to change org.jboss.security.negotiation.NegotiationAuthenticator.authenticate() so that it sets contentType on the Response itself. > SPNEGO-fallback-to-FORM authentication does not work with httpd+JBossEAP6 if SPNEGO not available > ------------------------------------------------------------------------------------------------- > > Key: SECURITY-722 > URL: https://issues.jboss.org/browse/SECURITY-722 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_1 > Environment: RHEL6, JBoss EAP 6 > Reporter: flame liu > Assignee: Darran Lofthouse > > I configured SPNEGO in EAP6. It works well both with EAP only and EAP6 + Apache httpd(mod_proxy). Users just run kinit and will be able to be successfully authenticated. > After that, I added the fallback-to-form files/configurations both in the web app and standalone-full.xml. The fallback-to-form works only if httpd stops. If httpd starts, 401 error will always be thrown out. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2061) CLI fails to show app status when runtime-name is different from the deployment name

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2061?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-2061: ---------------------------------------- @karjoe, The WFLY-1521 fix should have fixed the EJB subsystem issue you mentioned. You're correct; it was due to the same basic problem: looking up an MSC service using the deployment name to create the service name instead of using the runtime name. > CLI fails to show app status when runtime-name is different from the deployment name > ------------------------------------------------------------------------------------ > > Key: WFLY-2061 > URL: https://issues.jboss.org/browse/WFLY-2061 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Alpha4 > Environment: All > Reporter: Jay Kumar SenSharma > Assignee: Brian Stansberry > Fix For: 8.0.0.Final > > > If an application is deployed with a different "runtime-name" other than the actual EAR "name" then CLI fails to show the Status of the application. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2715) Upgrade to PicketBox 4.0.20.Beta3

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/WFLY-2715?page=com.atlassian.jira.plugin.... ] Stefan Guilhen updated WFLY-2715: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/5674 > Upgrade to PicketBox 4.0.20.Beta3 > --------------------------------- > > Key: WFLY-2715 > URL: https://issues.jboss.org/browse/WFLY-2715 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.CR1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: 8.0.0.Final > > -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2715) Upgrade to PicketBox 4.0.20.Beta3

by Stefan Guilhen (JIRA)

Stefan Guilhen created WFLY-2715: ------------------------------------ Summary: Upgrade to PicketBox 4.0.20.Beta3 Key: WFLY-2715 URL: https://issues.jboss.org/browse/WFLY-2715 Project: WildFly Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Security Affects Versions: 8.0.0.CR1 Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: 8.0.0.Final -- 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

12 years, 5 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 January 2014