February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-733) Fine-grained JDOM replication effort

by Ben Wang (JIRA)

Fine-grained JDOM replication effort ------------------------------------ Key: JBCACHE-733 URL: http://jira.jboss.com/jira/browse/JBCACHE-733 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 is efforts made to "apectizing" JDOM library under branch JBossCache_1_4_JDOM: 1. Check in additional jdom library: saxpath.jar, jdom.jar, and jaxen-*.jar 2. Re-factored to introduce NonTransient tag. 3. Unit test for jdom -- 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] Created: (JBCACHE-741) Create a jdom replication GUI example

by Ben Wang (JIRA)

Create a jdom replication GUI example ------------------------------------- Key: JBCACHE-741 URL: http://jira.jboss.com/jira/browse/JBCACHE-741 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 We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library. -- 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
10
0 / 0

[JBoss JIRA] Created: (JBCACHE-977) PojoCache annotated50 run.loadtime.example failed

by Ben Wang (JIRA)

PojoCache annotated50 run.loadtime.example failed ------------------------------------------------- Key: JBCACHE-977 URL: http://jira.jboss.com/jira/browse/JBCACHE-977 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: 1.4.1.SP1 Reporter: Ben Wang Assigned To: Ben Wang Fix For: PojoCache Reported by a user. The root cause seems to be in jboss aop since it fails when a subclass (in this Student from Person) is put into PojoCache and instrumented during loadtime (note that compile mode works correctly). I have checked PojoCache2.0. It works fine there with jboss aop 2.0. I ahve checked in an example in NewReplicatedAopTest. Will have Kabir take a look. -- 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
2
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] 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] 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] Created: (JBCACHE-947) Optimization in attach and detach; reduce calls to getPojo()

by Elias Ross (JIRA)

Optimization in attach and detach; reduce calls to getPojo() ------------------------------------------------------------ Key: JBCACHE-947 URL: http://jira.jboss.com/jira/browse/JBCACHE-947 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: PojoCache Reporter: Elias Ross Assigned To: Ben Wang PojoCache.attach() calls getPojo() at least three times. Once in putObjectI() to determine if the existing object is the same as the attaching object (fairly rare condition), then once again in putObjectII() (which might be redundant.) Then, it calls detach() which calls getPojo() -- see below. I believe that simply calling pCache.detach() and returning the old value might be sufficient. Also, detach() likewise locates the object before removal, though the removal method itself returns the original object. This is because notification includes the original object before removal. In some cases, notification may not be required. It may also be better to refactor the notification listener so that every removal doesn't require two calls to "getPojo". I discovered this following the number of calls made in a profiler tool. -- 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] Created: (JBCACHE-736) PojoCache passivation failure

by Ben Wang (JIRA)

PojoCache passivation failure ----------------------------- Key: JBCACHE-736 URL: http://jira.jboss.com/jira/browse/JBCACHE-736 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: 1.4.0 Reporter: Ben Wang Assigned To: Ben Wang In release 1.4 of PojoCache, passivation won't work becuase the new AopEvictionInterceptor and that we override the evict method such that we issue recursiveEvict that in turn is doing _remove(). Becuase of this, it bypasses the passivation interceptor. However, the fix is not so obvious. As it also involves the eviction paradigm for POJo as well. In 2.0 instead, I have opted for not to over-ride evict such that we would only support passivation on a node basis (instead of POJO). This way, passivation is transparent to the POJO level. I have a passivation package to test out these cases. -- 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

3
4
0 / 0

[JBoss JIRA] Created: (JBPM-837) Doesn't support eastern character because the wrong specified font

by David Chan (JIRA)

Doesn't support eastern character because the wrong specified font ------------------------------------------------------------------ Key: JBPM-837 URL: http://jira.jboss.com/jira/browse/JBPM-837 Project: JBoss jBPM Issue Type: Bug Components: Web Interface Affects Versions: jBPM 3.1 beta 2 Environment: Windows XP(en) jBPM 3.2 beta-1 JDK 1.5.10 Reporter: David Chan Assigned To: Tom Baeyens The client application(console) written with JSF drawn button image with AWT using a western font 'Arial', this font doesn't support eastern character like Chinese. After I reviewed the source code, found this line in file ButtonRendererprivate.java laid in package org.jbpm.webapp.tag.jbpm.renderer private Font font = new Font("Arial", Font.PLAIN, 12); as you see, change the font with system's default is more better, but may lose some beauty. private Font font = new Font(null, Font.PLAIN, 12); -- 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

3
10
0 / 0

[JBoss JIRA] Created: (JBPM-804) Move a token

by David Lloyd (JIRA)

Move a token ------------ Key: JBPM-804 URL: http://jira.jboss.com/jira/browse/JBPM-804 Project: JBoss jBPM Issue Type: Sub-task Reporter: David Lloyd Assigned To: David Lloyd -- 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2007