[jboss-user] [JBossCache] - RC1->RC3 problems
We tried to migrage from RC1 to RC3 and are quite disappointed. IMO, there are a bunch of
things that can happen in alpha or beta state, but really shouldn't happen between
candidate releases.
1) API changes
There's already a thread about this regarding listener notification.
2) Behavior changes
- Cache data is removed when a cache is stopped. This has never been the case before. I
know that it was written somewhere in the documentation since 1.2 or so but it was a
concept that didn't make sense to begin with. Who would have thought that someone is
actually going to implement this... Data can easily be removed manually if indeed
necessary, doing it in stop is pointless: stop() should stop the cache, destroy() should
destroy it. Now stop() partially destroys it and destroy contains some code that is even
redundant. (you can tell me not to rely on undocumented features and you are right, but
missing the point: somthing that has been there for 5 years shouldn't be removed
between two candidate releases)
- Cache restart (stop/start) is broken. When a cache is started in local mode first and
then restarted in async mode, initial state transfer works, but updates at runtime
don't because half the mode-dependent stuff is in create and half in start which
renders a restarted cache unusable. This was not the case in RC1.
I have a feeling that the cache life cycle has never really been thought through. I guess
most people use create/start ... stop/destroy: in fact, start and destroy would be
sufficient for them. But we use create/start ... stop/mode change/start ... stop/mode
change/start ... etc. stop/destroy.
3) New bugs introduced
I admitt, I only ran a couple of our automated tests, but it didn't look pretty. Pojo
cache can't even handle the following anymore:
| _cache.start();
|
| SystemW coreSystem = new SystemW();
| coreSystem.setDo(new SystemS(100, 123, "core system",
"CORE")); // <- @Serializable
|
| _cache.attach("/systems/100", coreSystem);
| _cache.attach("/systems/100", new SystemW()); // <- throws
|
whereas SystemW is advised and has a @org.jboss.cache.pojo.annotation.Serializable field
_do. Something like this:
| public class SystemW {
| @org.jboss.cache.pojo.annotation.Serializable
| private SystemS _do;
|
| public void setDo(SystemS inDo) {
| _do = inDo;
| }
| }
|
Stack trace:
| java.lang.ClassCastException: ch.steria.jbcache.aopobjects.SystemS
| at org.jboss.cache.pojo.impl.InternalHelper.getPojoReference(InternalHelper.java:46)
| at org.jboss.cache.pojo.impl.InternalHelper.getPojo(InternalHelper.java:181)
| at org.jboss.cache.pojo.impl.PojoCacheDelegate.getObject(PojoCacheDelegate.java:81)
| at org.jboss.cache.pojo.impl.PojoCacheImpl.getObject(PojoCacheImpl.java:203)
| at
org.jboss.cache.pojo.impl.PojoCacheImpl.org$jboss$cache$pojo$impl$PojoCacheImpl$detach$aop(PojoCacheImpl.java:150)
| at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java)
| at org.jboss.cache.pojo.impl.AdvisedPojoHandler.remove(AdvisedPojoHandler.java:215)
| at
org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:276)
| at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
| at
org.jboss.cache.pojo.impl.PojoCacheImpl.org$jboss$cache$pojo$impl$PojoCacheImpl$detach$aop(PojoCacheImpl.java:153)
| at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java)
| at
org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
| at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
| at
org.jboss.cache.pojo.impl.PojoCacheImpl.org$jboss$cache$pojo$impl$PojoCacheImpl$attach$aop(PojoCacheImpl.java:101)
| at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java)
| at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
|
This has never been a problem in RC1 or before.
Regards,
Basil
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067832#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...