December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMICROCONT-123) Better mechanism to determine Array class

by Adrian Brock (JIRA)

Better mechanism to determine Array class ----------------------------------------- Key: JBMICROCONT-123 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-123 Project: JBoss MicroContainer Issue Type: Task Components: BeanInfo Affects Versions: JBossMC_2_0_0 Beta Reporter: Adrian Brock Priority: Minor The current implementation of getArrayClass uses the horrible public static Class getArrayClass(Class clazz, int depth) { return Array.newInstance(clazz, depth).getClass(); } there must be a better way to do this? -- 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

18 years, 11 months

4
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-846) PojoCache 2.0 key features

by Ben Wang (JIRA)

PojoCache 2.0 key features -------------------------- Key: JBCACHE-846 URL: http://jira.jboss.com/jira/browse/JBCACHE-846 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Manik Surtani Priority: Minor Fix For: 2.0.0.GA Manik, FYI, followings are the key features for PojoCache 2.0. When do the announcement later, please include them in. Thanks! -Ben Key PojoCache 2.0 features: 1. Supports replicated POJO field as Enum class (JBCACHE-619) 2. Option to replicate POJO final field (JBCACHE-839) 3. Support JDK5.0 only 4. PojoCache provides MBean interface (JBCACHE-783) 5. Uses a pojocache-aop.xml for configuration (JBCACHE-780) 6. Handle complete rollback of POJO field operation under transaction if needed (JBCACHE-723) 7. PojoCache to throw PojoCacheException only runtime exception (JBCACHE-700) 8. Interceptor based architecture to allow easy customization (JBCACHE-588) 9. PojoCache now uses Cache as a delegate (JBCACHE-673) 10. PojoCache event listener (JBCACHE-85) 11. During passivation, PojoCache now lazily loads the individual POJO. -- 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

18 years, 12 months

3
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-886) Upgrading from JGroups 2.2.9.2 to JGroups 2.4

by Galder Zamarreno (JIRA)

Upgrading from JGroups 2.2.9.2 to JGroups 2.4 --------------------------------------------- Key: JBCACHE-886 URL: http://jira.jboss.com/jira/browse/JBCACHE-886 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 1.4.0.SP1 Reporter: Galder Zamarreno Assigned To: Manik Surtani Fix For: 1.4.1.GA, 2.0.0.GA -- 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

18 years, 12 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-857) Upgrade to JBoss AOP 2.0.ALPHA2

by Ben Wang (JIRA)

Upgrade to JBoss AOP 2.0.ALPHA2 ------------------------------- Key: JBCACHE-857 URL: http://jira.jboss.com/jira/browse/JBCACHE-857 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0.GA Temporarily upgrade to 2.0.ALPHA2 for the alpha release such tat we can continue integration into AS5.0 -- 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

18 years, 12 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-884) Upgrade to JGroups 2.5

by Manik Surtani (JIRA)

Upgrade to JGroups 2.5 ---------------------- Key: JBCACHE-884 URL: http://jira.jboss.com/jira/browse/JBCACHE-884 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Replication Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 1.4.1.GA, 2.0.0.ALPHA2, 2.0.0.GA As a part of this, rely on JGroups ANYCAST (JBCACHE-813) properly, and yank out JBCACHE-813 kludge. -- 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

18 years, 12 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-853) CacheJmxWrapper should implement NotificationBroadcaster

by Brian Stansberry (JIRA)

CacheJmxWrapper should implement NotificationBroadcaster -------------------------------------------------------- Key: JBCACHE-853 URL: http://jira.jboss.com/jira/browse/JBCACHE-853 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.0.0.GA We need to clarify responsibility for this between the top level JMX wrapper beans and CacheMgmtInterceptor. -- 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

18 years, 12 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-696) Look into JDBMCacheLoader details and potentially promote as a 'recommended' cache loader?

by Manik Surtani (JIRA)

Look into JDBMCacheLoader details and potentially promote as a 'recommended' cache loader? ------------------------------------------------------------------------------------------ Key: JBCACHE-696 URL: http://jira.jboss.com/jira/browse/JBCACHE-696 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0, 1.3.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0 -- 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

18 years, 12 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails

by Ben Wang (JIRA)

CacheLoader passivation/activation produces recursive exception when loader.remove fails ---------------------------------------------------------------------------------------- Key: JBCACHE-710 URL: http://jira.jboss.com/jira/browse/JBCACHE-710 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0 Reporter: Ben Wang Assigned To: Manik Surtani Priority: Critical Fix For: 2.0.0 I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened: In ActivationInterceptor.java, we have: if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) { if (n.hasChildren()) { if (allInitialized(n)) { log.debug("children all initialized"); remove(fqn); } } else if (loaderNoChildren(fqn)) { log.debug("no children " + n); remove(fqn); } } } } return retval; } private void remove(Fqn fqn) throws Exception { loader.remove(fqn); cache.notifyNodeActivate(fqn, false); if (cache.getUseInterceptorMbeans()&& statsEnabled) m_activations++; } problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve the node value, e.g., cache.get(fqn, key) to process some logic, then get(fqn, key) will come back to ActivationInterceptor and attempt another .remove() and therefore the recursion. A proposed fix is we should throw exception when removing the node fails in CacheLoader (I am using FileCacheLoader), e.g., DataNotRemovedException. That way, ActivationInterceptor can catch it here and skip event notification (since it won't be valid anyway). -- 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

18 years, 12 months

4
10
0 / 0

[JBoss JIRA] Created: (JBCACHE-839) PojoCache to add an option to replicate final field

by Ben Wang (JIRA)

PojoCache to add an option to replicate final field --------------------------------------------------- Key: JBCACHE-839 URL: http://jira.jboss.com/jira/browse/JBCACHE-839 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0.GA We should add a flag to enable replication of final field in PojoCache. This can be done via pojocache-aop.xml, where:  <interceptor name="Start" class="org.jboss.cache.pojo.interceptors.PojoBeginInterceptor" scope="PER_INSTANCE">  <attribute name="ReplicateFinalField">true</attribute> </interceptor> -- 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

18 years, 12 months

3
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-833) Redundant lock in cache loader

by Ben Wang (JIRA)

Redundant lock in cache loader ------------------------------ Key: JBCACHE-833 URL: http://jira.jboss.com/jira/browse/JBCACHE-833 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0.SP1, 1.4.0.GA Reporter: Ben Wang Assigned To: Manik Surtani Priority: Minor Fix For: 2.0.0.GA Currently in CacheLoader, it calls "lock" from loadIfNeeded method. The "lock" method in turns invokes TreeCache.java public void _lock(Fqn fqn, DataNode.LockType lock_type, boolean recursive) throws TimeoutException, LockingException { log.warn("method _lock() should not be invoked on TreeCache"); } I think the LockInterceptor should take care of the locking properly. So this call should be deprecated. -- 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

18 years, 12 months

2
3
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 December 2006