April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBCACHE-663) Setup system property for Id string separator

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-663?page=all ] Jason T. Greene updated JBCACHE-663: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Setup system property for Id string separator > --------------------------------------------- > > Key: JBCACHE-663 > URL: http://jira.jboss.com/jira/browse/JBCACHE-663 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > In 2.0 release, we will use id String instead the old fqn. We will also use a system property called jbosscache.separator to allow user to use a different character as the separator. -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-893) Create a pluggable PojoCache Collection class implementation

by Ben Wang (JIRA)

Create a pluggable PojoCache Collection class implementation ------------------------------------------------------------ Key: JBCACHE-893 URL: http://jira.jboss.com/jira/browse/JBCACHE-893 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: PojoCache Currently PojoCache only supports a single flavor of Collection classes, e.g., HashMap, HashSet, and ArrayList. To fully support different flavor of Collection implementation, we can either: 1. Enable array interception from Jboss Aop such that we can instrument all Collection implementation classes (including java.util.*). But JBoss Aop currently doesn't support it yet, and issues of instrumenting the Sun system classes also is problematic. 2. Create a pluggable architecture for different flavor of Collection implementation. I think Option #2 is more realistic now. What I propose is this: 1. Will need to implement a specific flavor of collection interceptor and cache impl. E.g., in the case of List, it will be CachedListInterceptor and CachedListImpl. 2. Register the specific impl and the corresponding Collection class name to a registry During runtime, when we encounter Collection classes, we will check the registry first to see which interceptor (and the corresponding cache impl) that we will use for this case. Performance impact should be minimal since this is needed only for attach phase. -- 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

19 years, 3 months

2
1
0 / 0

[JBoss JIRA] Updated: (JBCACHE-527) findObjects return pojos are not necessarily Serializable

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-527?page=all ] Jason T. Greene updated JBCACHE-527: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > findObjects return pojos are not necessarily Serializable > --------------------------------------------------------- > > Key: JBCACHE-527 > URL: http://jira.jboss.com/jira/browse/JBCACHE-527 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Minor > Fix For: PojoCache 2.1.0 > > > Currently, the MBean api, findObjects(fqn) return Map that contains fqn and pojos. However, this can't be used in remote call since pojos are not have to be Serializable. User can however, make it Serializable. Or need to come up another way to make it so. This is desirable for monitoring purposes so we know which pojos are current in store. -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-452) Support @NonPersistent annotation in PojoCache

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-452?page=all ] Jason T. Greene updated JBCACHE-452: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Support @NonPersistent annotation in PojoCache > ---------------------------------------------- > > Key: JBCACHE-452 > URL: http://jira.jboss.com/jira/browse/JBCACHE-452 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache > > > We should support @NonPersistent annotation that if set, that particular field is stored in the cache but is not under persisency even when cache loader is configured. -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-327) Expose PojoCache management attribtues

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-327?page=all ] Jason T. Greene updated JBCACHE-327: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Expose PojoCache management attribtues > -------------------------------------- > > Key: JBCACHE-327 > URL: http://jira.jboss.com/jira/browse/JBCACHE-327 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache 2.2.0 > > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > We need to expose JBossCacheAop management attributes. Here are some thoughts: > - # of pojos > - Pojo references > - pojo lifetime > - pojo evicted > - pojo life cycle listener (field access) -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-750) PojoCache to deal with POJO without no-arg constructor

by Ben Wang (JIRA)

PojoCache to deal with POJO without no-arg constructor ------------------------------------------------------ Key: JBCACHE-750 URL: http://jira.jboss.com/jira/browse/JBCACHE-750 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: PojoCache This came up from a forum post that uses SynchronizedCollection. Here is the problem that Professor Chiba pointed out: ------ Ben, SynchronizedRandomAccessList class has only the following constructors: static class SynchronizedRandomAccessList<E> extends SynchronizedList<E> implements RandomAccess { SynchronizedRandomAccessList(List<E> list) { super(list); } SynchronizedRandomAccessList(List<E> list, Object mutex) { super(list, mutex); } : } I can modify Javassist so that the above constructors (visible only within the pacakge) will be copied to the generated class. But I am not sure that PojoCache can work with that generated class since it does not have a no-arg constructor. Chiba -------- No easy solution to this problem now. Maybe use the exisiting serialization for once during replication? -- 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

19 years, 3 months

2
3
0 / 0

[JBoss JIRA] Updated: (JBCACHE-654) Upgrade to JBoss AOP 2.0 to prevent classloader memory leakage during re-deployment

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-654?page=all ] Jason T. Greene updated JBCACHE-654: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Upgrade to JBoss AOP 2.0 to prevent classloader memory leakage during re-deployment > ----------------------------------------------------------------------------------- > > Key: JBCACHE-654 > URL: http://jira.jboss.com/jira/browse/JBCACHE-654 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: 2.0.0.GA > > > As titled. -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-603) PojoCache perf test error

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-603?page=all ] Jason T. Greene updated JBCACHE-603: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > PojoCache perf test error > ------------------------- > > Key: JBCACHE-603 > URL: http://jira.jboss.com/jira/browse/JBCACHE-603 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache > > > During the perf test for PojoCache, once a while I ran into this error. It seems this error happens initially when there are lots of thread contention. Note that this error is absent when there is just single thread. This may involve Javassit or JBossAop. > Caused by: java.lang.RuntimeException: javassist.NotFoundException: field: address in org.jboss.cache.data.Person > at org.jboss.aop.annotation.AnnotationElement.getVisibleAnnotation(AnnotationElement.java:111) > at org.jboss.aop.Advisor.resolveAnnotation(Advisor.java:292) > at org.jboss.cache.aop.CachedType.hasSerializableAnnotation(CachedType.java:252) > at org.jboss.cache.aop.TreeCacheAopDelegate._regularPutObject(TreeCacheAopDelegate.java:382) > at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:164) > at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:640) > at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:400) > ... 4 more > Caused by: javassist.NotFoundException: field: address in org.jboss.cache.data.Person > at javassist.CtClassType.getField(CtClassType.java:567) > at org.jboss.aop.util.ReflectToJavassist.fieldToJavassist(ReflectToJavassist.java:34) > at org.jboss.aop.annotation.AnnotationElement.getVisibleAnnotation(AnnotationElement.java:102) -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-975) PojoCache Collection proxy is not serializable

by Ben Wang (JIRA)

PojoCache Collection proxy is not serializable ---------------------------------------------- Key: JBCACHE-975 URL: http://jira.jboss.com/jira/browse/JBCACHE-975 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: PojoCache Current PojoCache2.0 uses JBossAop that introduces new dependency on other JBoss system classes. As a result, the CachedListInterceptor (of which belongs to AopProxy) is not serializalbe even by JBoss Serialization. Of course, a straightforward use of serialization with Java one would fail previously. So now, in order to replicate the list in plain Cache, a user will need to perform detach first, e.g., list = pcache.detach("pojo"); cache.put("key", list); -- 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

19 years, 3 months

2
1
0 / 0

[JBoss JIRA] Updated: (JBCACHE-168) Querying for POJO object under PojoCache

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-168?page=all ] Jason T. Greene updated JBCACHE-168: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Querying for POJO object under PojoCache > ---------------------------------------- > > Key: JBCACHE-168 > URL: http://jira.jboss.com/jira/browse/JBCACHE-168 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Minor > Fix For: PojoCache 2.2.0 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Need to provide an API in TreeCacheAop that can query the current pojos. Currently, it is user's responsibility to track the pojo based on the fqn. > We can provide an extension based on findObjects that is can query all fqn with additional class argument, e.g., > findObjects(fqn, myPojo.class) -- 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

19 years, 3 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 April 2007