April 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1025) Prefill scheduled too early for new connections

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-1025: -------------------------------------- Summary: Prefill scheduled too early for new connections Key: JBJCA-1025 URL: https://issues.jboss.org/browse/JBJCA-1025 Project: IronJacamar Issue Type: Bug Components: Core Affects Versions: 1.1.0.Beta4, 1.0.16.Final Reporter: Jesper Pedersen Assignee: Jesper Pedersen Priority: Critical Fix For: 1.0.17.Final, 1.1.0.Beta5 -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-67) Improve LogManager formatter capability: System resources, thread ID and minified category

by Jimmy Wilson (JIRA)

Jimmy Wilson created LOGMGR-67: ---------------------------------- Summary: Improve LogManager formatter capability: System resources, thread ID and minified category Key: LOGMGR-67 URL: https://issues.jboss.org/browse/LOGMGR-67 Project: JBoss Log Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: core Affects Versions: 1.3.2.Final Environment: JBoss EAP 6.0.1 Reporter: Jeremy KUHN Assignee: David Lloyd Fix For: 1.3.2.Final Hello, We are currently developing a major JEE application running on multiple JBoss EAP 6.0.1 instances in a service oriented architecture. The current implementation of JBoss-logmanager (1.3.2.Final) shipped with JBoss EAP doesn't provide the functionality we require in term of logging formatting. We are missing: - Thread ID (Thread names are too long and of different length that disturb the reading of logs) - we haven't find a way to get the hostname displayed in the logs, a simple solution would be to be able to include System properties and therefore the jboss.host.name property in the pattern. System properties would also be interesting to identified the log coming from a specific application (we'll have one application deployed per JBoss instance). Ideally, we'd like to have the ability to provide a context name to know which application has logged the event but this seems to have been delivered with logging profiles. - logback has this interesting feature that lets you minify the log category: instead of org.jboss.logmanager.config.ConfigAction you'll get o.j.l.c.ConfigAction which is more readable in the logs. Regards -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-6967) ClassLoader memory leak with JSF

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/AS7-6967?page=com.atlassian.jira.plugin.s... ] jaikiran pai updated AS7-6967: ------------------------------ Assignee: Stan Silvert Component/s: JSF > ClassLoader memory leak with JSF > -------------------------------- > > Key: AS7-6967 > URL: https://issues.jboss.org/browse/AS7-6967 > Project: Application Server 7 > Issue Type: Bug > Components: JSF > Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) > Reporter: Vlad Arkhipov > Assignee: Stan Silvert > Priority: Critical > Attachments: war-leak.tar.gz > > > JSF application's classes are not unloaded properly when undeployed. The test case is in the attachment. Steps to reproduce: > # mvn package > # deploy war-leak.war > # open http://localhost:8080/war-leak > # undeploy war-leak.war > # analyze a heap dump to find unloaded ModuleClassLoader of war-leak.war > References to the WAR classes are hold by java.beans.Introspector caches. It seems to be a known bug (feature?). For example Tomcat automatically invokes java.beans.Introspector.flushCaches() when WAR undeploys. There is also IntrospectorCleanupListener in Spring for the same purpose. > http://wiki.apache.org/commons/Logging/UndeployMemoryLeak > http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/... -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-735) spnego AdvancedLdapLoginModule cannot cope with roles contains a slash

by Darran Lofthouse (JIRA)

Darran Lofthouse created SECURITY-735: ----------------------------------------- Summary: spnego AdvancedLdapLoginModule cannot cope with roles contains a slash Key: SECURITY-735 URL: https://issues.jboss.org/browse/SECURITY-735 Project: PicketBox Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Negotiation Affects Versions: Negotiation_2_2_2 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_2_2_3 -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-735) spnego AdvancedLdapLoginModule cannot cope with roles contains a slash

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-735?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated SECURITY-735: --------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=953513 > spnego AdvancedLdapLoginModule cannot cope with roles contains a slash > ---------------------------------------------------------------------- > > Key: SECURITY-735 > URL: https://issues.jboss.org/browse/SECURITY-735 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_3 > > -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-733) Session replication broken by NegotiationAuthenticator valve

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-733?page=com.atlassian.jira.plug... ] Darran Lofthouse resolved SECURITY-733. --------------------------------------- Resolution: Done JBoss Negotiation makes use of a wrapper to intercept calls through the Valves to ensure the delegation credential is set - this was unfortunately hiding the Lifecycle implementation of the wrapped valve. The code change now introduces an additional valve in the chain rather than completely wrapping the next valve - this makes the Lifecycle implementation visible. > Session replication broken by NegotiationAuthenticator valve > ------------------------------------------------------------ > > Key: SECURITY-733 > URL: https://issues.jboss.org/browse/SECURITY-733 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_3 > > > From an initial review of the code I believe this is because the ClusterSessionValve implements the Listener interface - however the wrapper class does not. -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-6963) EAP 6 Domain Mode Logging for Management is nonexistent.

by Tom Fonteyne (JIRA)

[ https://issues.jboss.org/browse/AS7-6963?page=com.atlassian.jira.plugin.s... ] Tom Fonteyne commented on AS7-6963: ----------------------------------- @Brian: the debug jar I did was only adding some System.out.println showing the variables passed into the LDAP searches + what (if any) things returned in it's resultset. This RFE is really just to get diagnostic logging added to the management security classes, NOT just LDAP, but in general. @Darran: cheers! > EAP 6 Domain Mode Logging for Management is nonexistent. > --------------------------------------------------------- > > Key: AS7-6963 > URL: https://issues.jboss.org/browse/AS7-6963 > Project: Application Server 7 > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final) > Reporter: Eric Rich > Assignee: Darran Lofthouse > Fix For: 8.0.0.Alpha1 > > 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-6967) ClassLoader memory leak with JSF

by Vlad Arkhipov (JIRA)

[ https://issues.jboss.org/browse/AS7-6967?page=com.atlassian.jira.plugin.s... ] Vlad Arkhipov updated AS7-6967: ------------------------------- Attachment: war-leak.tar.gz > ClassLoader memory leak with JSF > -------------------------------- > > Key: AS7-6967 > URL: https://issues.jboss.org/browse/AS7-6967 > Project: Application Server 7 > Issue Type: Bug > Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) > Reporter: Vlad Arkhipov > Priority: Critical > Attachments: war-leak.tar.gz > > > JSF application's classes are not unloaded properly when undeployed. The test case is in the attachment. Steps to reproduce: > # mvn package > # deploy war-leak.war > # open http://localhost:8080/war-leak > # undeploy war-leak.war > # analyze a heap dump to find unloaded ModuleClassLoader of war-leak.war > References to the WAR classes are hold by java.beans.Introspector caches. It seems to be a known bug (feature?). For example Tomcat automatically invokes java.beans.Introspector.flushCaches() when WAR undeploys. There is also IntrospectorCleanupListener in Spring for the same purpose. > http://wiki.apache.org/commons/Logging/UndeployMemoryLeak > http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/... -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-6967) ClassLoader memory leak with JSF

by Vlad Arkhipov (JIRA)

Vlad Arkhipov created AS7-6967: ---------------------------------- Summary: ClassLoader memory leak with JSF Key: AS7-6967 URL: https://issues.jboss.org/browse/AS7-6967 Project: Application Server 7 Issue Type: Bug Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) Reporter: Vlad Arkhipov Priority: Critical JSF application's classes are not unloaded properly when undeployed. The test case is in the attachment. Steps to reproduce: # mvn package # deploy war-leak.war # open http://localhost:8080/war-leak # undeploy war-leak.war # analyze a heap dump to find unloaded ModuleClassLoader of war-leak.war References to the WAR classes are hold by java.beans.Introspector caches. It seems to be a known bug (feature?). For example Tomcat automatically invokes java.beans.Introspector.flushCaches() when WAR undeploys. There is also IntrospectorCleanupListener in Spring for the same purpose. http://wiki.apache.org/commons/Logging/UndeployMemoryLeak http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/... -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-365) Java EE 7 Related Metadata

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/JBMETA-365?page=com.atlassian.jira.plugin... ] Eduardo Martins updated JBMETA-365: ----------------------------------- Git Pull Request: https://github.com/jboss/metadata/pull/46 > Java EE 7 Related Metadata > -------------------------- > > Key: JBMETA-365 > URL: https://issues.jboss.org/browse/JBMETA-365 > Project: JBoss Metadata > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: client, common, ear, ejb, web > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > Provide support for Java EE 7: > - support new namespaces > - add new metadata + parsers/mergers for app client, ear, ejb and web > - add module for permissions.xml with metadata and parsers > - add unit tests for all the new stuff -- 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

11 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2013