April 2007 - jbosscache-dev - Jboss List Archives

jboss-cache-testsuite-140 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

jboss-cache-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

Re: [javagroups-users] Considering migrating to jboss cache from DistributedTree

by Brian Stansberry

Bill Middleton wrote: > A cursory (and likely naive) inspection of DefaultCacheFactory and > CacheImpl seems to indicate that providing my own channel should be > fairly easy to implement, even if an extension won't quite get the job > done, since channel is private. The intimidating part is the binding > between the "official" multiplexed channel (mbean) and other > functionality which implies a full app-server, such as the > TransactionManager. Not sure what you mean here by "binding". Passing a JChannelFactoryMBean to the RuntimeConfig doesn't carry with it a requirement to pass in a TransactionManager. Think of RuntimeConfig as basically being a placeholder through which the external environment can pass in complex objects the cache may need and through which callers can get access to a few of the cache internals. > If I were to pass in a channel to CacheImpl, > whether multiplexed or not, I don't think I'll mess with > setUsingMultiplexer() and friends in the Configuration. Since I'm going > to manage the muliplexer functionality myself I guess it makes sense to > let Cache think that it's just a simple channel. This seems safe > enough, I hope. > Sure, as long as in reality it's a multiplexed channel, so the cache doesn't get messages it won't understand. If you're writing your own extensions, then presumably you know how the code will be used and can guard against misuse. So, the barrier for what's considered "safe" can be a lot lower. :) > Thanks very much for the reply. Those of us who haven't made the "big > switch" to a full jboss deployment are very glad to be able to use your > products individually in a "mix and match" configuration. :-) > +100; that's why I'm not happy with RuntimeConfig using JChannelFactoryMBean as its property type; it implies more than is necessary. We also need to better document the purpose of the RuntimeConfig (and maybe conceptually tighten it up a bit.) - Brian > > On 4/6/07, *Brian Stansberry* <brian.stansberry(a)redhat.com > <mailto:brian.stansberry@redhat.com>> wrote: > > Hmm. The cache's RuntimeConfig object only allowing injection of > JChannelFactoryMBean isn't good; at least being able to inject a plain > org.jgroups.JChannelFactory seems called for. The ugly bit is the class > and the interface have no direct type relationship, so you'd have to > expose properties of both types. > > I think the reason for not allowing passing a Channel to the > RuntimeConfig is that would imply exposing the Channel as well. The > Channel is not meant to be exposed to outside callers for the same > reason we no longer expose the RpcDispatcher. > > Bill Middleton wrote: > > > > > It does appear that I can get access to the rpcdispatcher > for the > > > jboss cache using getRPCManager(), or via implementing the > > depracated > > > RpcTreeCache, so it may be that my implementation can just > use an > > > standard CacheSPI, and doesn't need to extend CacheImpl > (or some > > other > > > concrete class), right? > > > > I would discourage you from doing that. Exposing the > RpcDispatcher in > > JBossCache was necessary for our internal aspects to invoke > the (public) > > methods on it, but we never intended for users of cache to > use it. So, > > in 2.0 we removed them (or made them available only through > the SPI > > API). > > > > > > Thanks for the advice, Bela. Unfortunately, an mbean is not a viable > > option for us. I can gladly create a multiplexer using the standard > > jgroups api (as seen in MultiplexerStressTest.java, for example), but > > that'd imply an ability to pass in my Channel directly to the Cache > > constructor, I assume, and DefaultCacheFactory doesn't seem to > > interested in letting me do that. > > > > Bill > > > -- > Brian Stansberry > Lead, AS Clustering > JBoss, a division of Red Hat > brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com> > > -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com

17 years, 7 months

3
7
0 / 0

jboss-cache-testsuite-jdk16 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

jboss-cache-testsuite-jdk14 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

jboss-cache build.1027 Build Successful

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

jboss-cache build.1026 Build Successful

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

finishing JBCACHE-964 - refactoring JDBCCacheLoaderOld and any source depending on it to "migration" path

by Galder Zamarreno

Hi, JBCACHE-964 is getting close to completion. I have docu and some refactoring pending which I'd like to get some consensus on: JDBCCacheLoaderOld is a classloader that it's in the main code for legacy purpouses. As part of JBCACHE-964, I have created a migration directory that includes a classloader to transform data from 1.x to 2.x. I was talking to Manik about moving JDBCCacheLoaderOld to this migration directory, removing it from the main source directory. That means that if a customer wants to use it, they need to add jbosscache-cacheloader-migration.jar to their classpath which is fine, making the customer think twice before doing it. As part of this refactoring, AdjListJDBCCacheLoaderCompatibilityTest which relies on JDBCCacheLoaderOld would also be moved to the tests directory of the migration path (quite likely migration/tests/functional) and similar thing would occur to OldImplBenchmark (possibly to migration/tests/perf which does not exist right now) This would require a bit of refactoring but I think it's minimal and removes non trunk source/test code from the main codebase. Thoughts? -- Galder Zamarreño Sr. Software Maintenance Engineer JBoss, a division of Red Hat

17 years, 7 months

2
2
0 / 0

jboss-cache-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

jboss-cache-testsuite-140 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-dev April 2007