November 2006 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Clustering tests and hsqldb

by scott.stark＠jboss.org

"ovidiu.feodorov(a)jboss.com" wrote : | We can do that, but I have one question and one observation related to this. | | The question is why JBoss AS doesn't use derby or javadb instead of hsqldb? | We most likely will since that is what we are certifying with. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982865#3982865 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982865

18 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Design of a Content Based Routing Service

by kurt.stam＠jboss.com

Thanks Dave I'll give that a try. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982862#3982862 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982862

18 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: Incorrect serialization of PojoCache collection class pr

by ben.wang＠jboss.com

OK, when I try to code the proxy class, I had the entity model in mind. I.e., when tyring to do remote call, you should always detach from it entity manager first and then re-attach again later. I can see your use case here as well for user accidentally to pass in the reference (that's what I said of not transparent). And what you proposed make good sense. But on the same token, this can be user's expectation that serilization and POJO relationship are still intact on the remote node! Again, this is unintentional but they have no way of knowing it, unless of course we explictly throw an exception. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982860#3982860 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982860

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover

by clebert.suconic＠jboss.com

"ovidiu.feodorov(a)jboss.com" wrote : ummmmm, Clebert .... this is a public forum, everybody can read it :) | | Never mind, you go ahead, I am sure you'll figure out a way to overcome those invading Bindings, nodeIDs and routers :) Eh eh... a little bit of humor... BTW... I already committed some changes regarding these changes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982855#3982855 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982855

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging and Remoting

by ovidiu.feodorov＠jboss.com

I wouldn't spend to much time with this, we gave up guaranteeing compatibilty until 1.2. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982852#3982852 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982852

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover

by ovidiu.feodorov＠jboss.com

Tim wrote : Any objections? Not until today ... :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982850#3982850 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982850

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover

by ovidiu.feodorov＠jboss.com

ummmmm, Clebert .... this is a public forum, everybody can read it :) Never mind, you go ahead, I am sure you'll figure out a way to overcome those invading Bindings, nodeIDs and routers :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982848#3982848 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982848

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Clustering tests and hsqldb

by ovidiu.feodorov＠jboss.com

Tim wrote : For now though, could everyone ensure they run the clustering-tests target before committing after they run the normal test suite? Thanks Why don't you add the clustering-tests target to "tests"? Also, you can configure the default database on a test-by-test basis, by overriding the value of < property name="functional.tests.database" value="hsqldb" />. Override it when you call < antcall target="clustering-tests"/> Scott wrote : | What about just switching to another embedded database such as derby or javadb? | We can do that, but I have one question and one observation related to this. The question is why JBoss AS doesn't use derby or javadb instead of hsqldb? The observation is that the value of the database a certain tests runs in top of can be changed on a test-by-test basis, so by just having an MySQL instance in stand by and configuring the tests to run with "mysql" would be sufficient. We already need MySQL for stress tests, so this would be the simplest way to get address the problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982847#3982847 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982847

18 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: Incorrect serialization of PojoCache collection class pr

by bstansberry＠jboss.com

This can easily happen -- a pojo with a collection field gets put in the cache, and then some user code hands a ref to the collection to some other object, that object gets serialized (say as part of a response to a remote call); boom! The case on the other forum post is a bit odd, as the serialization there is occuring due to cache replication itself. That's kind of a bad practice; they should aspectize all their classes. But I think we need to support the generic case where a Collection gotten from the cache gets serialized. But, I don't think there's any need at all to try to maintain any object relationship or anything when the object is deserialized. So, this kind of thing should work fine: Example is CachedListImpl: | private Object writeReplace() throws ObjectStreamException { | ArrayList toSerialize = new ArrayList(); | toSerialize.addAll(this); | return toSerialize; | } | toSerialize is what gets serialized. When deserialized, it's a List, as expected. If the user thought the deserialized list would somehow be the same object as something stored in a PojoCache somewhere (where???), they're not thinking right. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982846#3982846 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982846

18 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Incorrect serialization of PojoCache collection class proxy

by ben.wang＠jboss.com

This is originally reported from http://www.jboss.com/index.html?module=bb&op=viewtopic&t=93750 where an accidental serialization of CachedMapImpl has occurred. Brian has also created http://jira.jboss.com/jira/browse/JBCACHE-830. I have raised it here for further discussion. I need to document it more clearly. However, the Collection proxy are not meant for serialization since the proxy won't come out properly once it is serialized (the interceptor reference is local only). The proper way to serialize a Collection (outside of the PojoCache) is to use the detach call first, e.g., List list = new ArrayList(); ... cache.attach("list", list); list = cache.find("list"); // This is a proxy ... list = cache.detach("list"); // now this returns a normal List and can be serialized properly. So looks like we have two choices: 1. Throw an exception when VM tries to serialize it? 2. Make all the fields transient if there is really a use case for that. Of course, if you make every POJO "aspectized" then this won't be an issue since replication won't involved the proxy itself (rather just the fields). This occurs when a POJO contains a object graph that has this reference. Like I said, I will document this further. But do we really see a use case that inenvitably we need to serialize the proxy? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982840#3982840 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982840

18 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2006