November 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-6128) Change name of default clustered SFSB cache in ejb3-interceptors-aop.xml

by Brian Stansberry (JIRA)

Change name of default clustered SFSB cache in ejb3-interceptors-aop.xml ------------------------------------------------------------------------ Key: JBAS-6128 URL: https://jira.jboss.org/jira/browse/JBAS-6128 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, EJB3 Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.GA Should not be the legacy jboss.cache:service=EJB3SFSBClusteredCache, should be "sfsb-cache", the name of the standard SFSB cache config in deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-configs.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-848) ClusteredStatefulCacheListener should be a singleton

by Brian Stansberry (JIRA)

ClusteredStatefulCacheListener should be a singleton ---------------------------------------------------- Key: EJBTHREE-848 URL: http://jira.jboss.com/jira/browse/EJBTHREE-848 Project: EJB 3.0 Issue Type: Task Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: EJB 3.0 RC11 - FD Currently, each SFSB Container registers an instance of ClusteredStatefulCacheListener with the SFSB cache. This is inefficient if there are many containers, as each gets passivation/activation callbacks and has to filter for the ones it's interested in. The callbacks don't do anything container-specific, so it should be possible to use a quasi-singleton ClusteredStatefulCacheListener and eliminate the filtering. Quasi-singleton, because it's possible to have multiple SFSB caches; need one listener per cache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

3
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-845) Clarify transactional behavior of clustered SFSB cache

by Brian Stansberry (JIRA)

Clarify transactional behavior of clustered SFSB cache ------------------------------------------------------ Key: EJBTHREE-845 URL: http://jira.jboss.com/jira/browse/EJBTHREE-845 Project: EJB 3.0 Issue Type: Task Components: Clustering Affects Versions: EJB 3.0 RC9 - Patch 1, EJB 3.0 RC9 - FD Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: EJB 3.0 RC10 - FD The ejb3-clustered-sfsb-service.xml is not declaring a TransactionManagerLookupClass, so the cache is not transactional. Need to clarify why this is and correct if there is no good reason. If it is valid, work with JBC team to eliminate the WARN JBC logs when no lookup is specified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

3
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1053) State changes in @PrePassivate don't get replicated if passivate before replication is disabled

by Carlo de Wolf (JIRA)

State changes in @PrePassivate don't get replicated if passivate before replication is disabled ----------------------------------------------------------------------------------------------- Key: EJBTHREE-1053 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1053 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: AS 4.2.2.GA Reporter: Carlo de Wolf Passivation doesn't trigger replication, so a bean might get passivated on 1 node and not on another. If the bean provider does state changes in pre-passivate these will not be visible on the other node. By default replication does trigger passivation, so a bean first gets passivated and then replicated. Thus the problem only occurs if passivate before replication is explicitly disabled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1054) Buddy replication can lead to a memory leak

by Carlo de Wolf (JIRA)

Buddy replication can lead to a memory leak ------------------------------------------- Key: EJBTHREE-1054 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1054 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.2.GA Reporter: Carlo de Wolf JBC passivation code is broken with buddy replication enabled. Whenever a bean is replicated it's copied to a backup region. This backup region is never evicted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1492) Embeddable EJB 3

by Carlo de Wolf (JIRA)

Embeddable EJB 3 ---------------- Key: EJBTHREE-1492 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1492 Project: EJB 3.0 Issue Type: Feature Request Reporter: Carlo de Wolf Fix For: 1.1.0-Beta1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1177) dependency on JMSProviderAdapter

by Andy Taylor (JIRA)

dependency on JMSProviderAdapter -------------------------------- Key: JBMESSAGING-1177 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1177 Project: JBoss Messaging Issue Type: Sub-task Components: Messaging Core Affects Versions: 2.0.0 Alpha Reporter: Andy Taylor Assigned To: Andy Taylor Fix For: 2.0.0 Alpha currently we have a dependency on JMSProviderAdapter. This, at the present, is in jbossas core which we shouldnt be dependant on. This either needs moving to the integration project or we need to rethink how it works. This is currently used in The XAMessagingResourceWrapper -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-146) Clustered EJB setting at the application level (EAR)

by Galder Zamarreno (JIRA)

Clustered EJB setting at the application level (EAR) ---------------------------------------------------- Key: JBCLUSTER-146 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-146 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Galder Zamarreno Assigned To: Brian Stansberry We are using clustering for tests. Our application is an ear-archive which has no information about clustering. If we will built up a cluster, we have to change the ejb-jar.xml to set the clustered-tag on True. This is very intricate. Out support team have to unpack the ear - set the clustered-tag for every bean and so on. Is it possible to set the clustered-tag all beans in a ear-Archive? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
8
0 / 0

[JBoss JIRA] Created: (JBAS-5300) ClassLoader leaks in TimedCachePolicy through JAAS Auth Cache

by Arto Huusko (JIRA)

ClassLoader leaks in TimedCachePolicy through JAAS Auth Cache ------------------------------------------------------------- Key: JBAS-5300 URL: http://jira.jboss.com/jira/browse/JBAS-5300 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-4.2.1.GA Environment: JDK 1.6.0_04 Reporter: Arto Huusko Assigned To: Scott M Stark JAAS authentication cache is responsible for two classloader leaks through org.jboss.utils.TimedCachePolicy, causing classes of undeployed applications not be unloaded. The second is not a huge problem, but still real, and is related to JBAS-3986. First problem is the creation of resolutionTimer. If TimedCachePolicy is used for the first time when my web application is accessed, the resolutionTimer object is created in the context of the web app, and the timer thread attached to the timer inherits the current context class loader, that is my web app's class loader. This results in a permanent reference to that class loader, and it can never be unloaded. The second problem is the fact that the expired entries are purged from the cache only when they are accessed. If some credentials are once used, and then never used again, they remain in the cache, and these cached LoginContexts contain references to the web app class loaders. First problem is fixable by temporarily changing current thread context class loader when first creating the resolutionTimer. The second problem could be fixed by JBoss automatically flushing the authentication cache when the web app is undeployed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-5870) JDK logging handler that maps JDK logging to JBoss logging

by Galder Zamarreno (JIRA)

JDK logging handler that maps JDK logging to JBoss logging ---------------------------------------------------------- Key: JBAS-5870 URL: https://jira.jboss.org/jira/browse/JBAS-5870 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: CMP service Reporter: Galder Zamarreno Assignee: Galder Zamarreno Create a JDK logging handle that maps JDK logging to JBoss logging so that 3rd party applications using JDK logging can log to the same place as the application server does. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2008