[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, 1 month
[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, 1 month