Re: [infinispan-dev] cache name in logs
+1 to limiting to named cache components On Apr 29, 2011, at 7:23 PM, Manik Surtani wrote: > I think any log attached to a named cache component (versus a global > component) should present cache name. > > On 29 Apr 2011, at 12:48, Mircea Markus wrote: > >> >> On 29 Apr 2011, at 16:37, Manik Surtani wrote: >> >>> My vote is to go with the MDC approach. >> +1 >> I will create a JIRA for this. Before that just want to ask which other >> components than Distribution manager would benefit from this approach? I'm >> thinking about: >> DsitributionManagerImpl >> TransactionTable (it also reacts to view changes, so multiple caches on the >> same CM would create confusing logs)... >> Other? >> >> Or would it be a good idea to have it for ALL the the logs in we output? >> After it doesn't make a lot of noise... >> >> Cheers, >> Mircea >> >>> >>> On 29 Apr 2011, at 11:33, Mircea Markus wrote: >>> On 29 Apr 2011, at 16:26, Olaf Bergner wrote: > Am 29.04.11 16:55, schrieb Galder Zamarreño: >> On Apr 28, 2011, at 11:47 PM, Manik Surtani wrote: >> >>> We do now support JBoss Logging. >>> >>> https://issues.jboss.org/browse/ISPN-380 >>> >>> @Galder, does JBoss Logging have support for what Mircea mentioned >>> below? >> I've skimmed through the javadoc but didn't see anything in particular >> for this at least around the message loggers which are the ones that >> help with internationalization. >> >> I think it could be fitted but would require a fair amount of changes, >> such as making some static loggers, particularly those for named cache >> components non static in order to take the cache name. Maybe you could >> have a named cache component for a log factory? > A workaround that IMHO feels a little hackish though would be to simply > append the current cache's name to the class name when instantiating a > logger: > > logger = LoggerFactory.getLogger(getClass().getName() + "[cache = " + > cacheName + "]") > > I wouldn't recommend this. That would also require having a logger/class instance, and not make the logger static. For my scenario (DisttributionManagerImpl) that might work as there's a single DisttributionManagerImpl per Cache. Besides not being able to make the logger static. any other reasons for not going with this approach? ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> -- >>> Manik Surtani >>> ma...@jboss.org >>> twitter.com/maniksurtani >>> >>> Lead, Infinispan >>> http://www.infinispan.org >>> >>> >>> >>> >>> ___ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> ___ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > ma...@jboss.org > twitter.com/maniksurtani > > Lead, Infinispan > http://www.infinispan.org > > > > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] recovery documentation
On Apr 29, 2011, at 8:58 PM, Mircea Markus wrote: > Hi, > > I've set up some on documentation around the new transaction functionality: > - recovery, linked from the main documentation page: > http://community.jboss.org/docs/DOC-16646?uniqueTitle=false In Configuring Recovery section I'd add a note that recoveryInfoCacheName is not necessary and indicate that more info can be found in the "Recovery cache" section. I don't understand this sentence: " If default cache is overridden then the recovery cache must use a TransactionManagerLookup that returns a different TM than the one used by the cache itself." - Why a different TM? Btw, I love the screenshots you've produced :) > - Synchronization: > http://community.jboss.org/wiki/InfinispanTransactions#Enlisting_Synchronization > > I also plan to : > - add a doc describing how to set up recovery with JBossTM and Infinispan - > ISPN-1080 > - add some performance numbers on the overhead of a) using tx b) using tx > with sync c) using tx with recovery > - add a blog entry around this stuff. > > Any feedback appreciated. > > Cheers, > Mircea > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
On 1 May 2011, at 13:38, Pete Muir wrote: >>> As in, user API? That's a little intrusive... e.g., put(K, V, cl) ? >> >> Not for put, since you have the class, just get, and I was thinking >> something more like: >> >> Foo foo = getUsing(key, Foo.class) > > This would be a pretty useful addition to the API anyway to avoid user casts. Maybe as an "advanced" API, so as not to pollute the basic API? A bit like: Foo f = cache.getAdvancedCache().asClass(Foo.class).get(key); -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
I like this solution. T From: Manik Surtani To: infinispan -Dev List Sent: Mon, 2 May, 2011 15:10:03 Subject: Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility On 1 May 2011, at 13:38, Pete Muir wrote: >>> As in, user API? That's a little intrusive... e.g., put(K, V, cl) ? >> >> Not for put, since you have the class, just get, and I was thinking >> something more like: >> >> Foo foo = getUsing(key, Foo.class) > > This would be a pretty useful addition to the API anyway to avoid user casts. Maybe as an "advanced" API, so as not to pollute the basic API? A bit like: Foo f = cache.getAdvancedCache().asClass(Foo.class).get(key); -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] [Pull Request] ISPN-961 - Spring Integration
I have a problem with the timing of this: 5.0.0.CR1 has already been released and the focus should be on bugfixing and documentation work. Therefore I believe this should be postponed to 5.1.0. I understand it is just an addition and not modifying anything already there, but it has its impact nonetheless (on the build process at any rate). Tristan On Sun, May 1, 2011 at 17:18, Olaf Bergner wrote: > > This is the first pull request I plan to issue for ISPN-961, the one > targeting the master branch. I will issue another for 4.2.x as soon as > this one is accepted. > ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] [Pull Request] ISPN-961 - Spring Integration
> I have a problem with the timing of this: 5.0.0.CR1 has already been > released and the focus should be on bugfixing and documentation work. > Therefore I believe this should be postponed to 5.1.0. I understand it is > just an addition and not modifying anything already there, but it has its > impact nonetheless (on the build process at any rate). > > Tristan Well, what time frames are we talking about here, anyway? When is 5.0 scheduled to arrive, when 5.1? Olaf > > On Sun, May 1, 2011 at 17:18, Olaf Bergner wrote: > > > > > This is the first pull request I plan to issue for ISPN-961, the one > > targeting the master branch. I will issue another for 4.2.x as soon as > > this one is accepted. > > -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
2011/5/2 Manik Surtani : > > On 1 May 2011, at 13:38, Pete Muir wrote: > As in, user API? That's a little intrusive... e.g., put(K, V, cl) ? >>> >>> Not for put, since you have the class, just get, and I was thinking >>> something more like: >>> >>> Foo foo = getUsing(key, Foo.class) >> >> This would be a pretty useful addition to the API anyway to avoid user casts. > > Maybe as an "advanced" API, so as not to pollute the basic API? A bit like: > > Foo f = cache.getAdvancedCache().asClass(Foo.class).get(key); doesn't look much better than a cast, but is more cryptical :) getting back to the classloader issue, what about: Cache c = cacheManager.getCache( cacheName, classLoader ); or Cache c = cacheManager.getCache( cacheName ).usingClassLoader(classLoader ); BTW if that's an issue on the API, maybe you should propose it to JSR-107 as well ? Sanne ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
How about just using "as" and "using" instead of "asClass" and "usingClassloader"? Consider something like the following which kind of looks like a dsl: Foo f = cache.getAdvancedCache().as (Foo.class).using (classLoader).get (key); T From: Sanne Grinovero To: infinispan -Dev List Sent: Mon, 2 May, 2011 21:08:47 Subject: Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility 2011/5/2 Manik Surtani : > > On 1 May 2011, at 13:38, Pete Muir wrote: > As in, user API? That's a little intrusive... e.g., put(K, V, cl) ? >>> >>> Not for put, since you have the class, just get, and I was thinking >>> something more like: >>> >>> Foo foo = getUsing(key, Foo.class) >> >> This would be a pretty useful addition to the API anyway to avoid user casts. > > Maybe as an "advanced" API, so as not to pollute the basic API? A bit like: > > Foo f = cache.getAdvancedCache().asClass(Foo.class).get(key); doesn't look much better than a cast, but is more cryptical :) getting back to the classloader issue, what about: Cache c = cacheManager.getCache( cacheName, classLoader ); or Cache c = cacheManager.getCache( cacheName ).usingClassLoader(classLoader ); BTW if that's an issue on the API, maybe you should propose it to JSR-107 as well ? Sanne ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
I think Sanne's idea was that you shouldn't have to specify the class or class loader on every get, as it's very likely that all operations on that cache will use the same classloader. Most applications will only use one classloader anyway. I'm not even sure we should allow using more than one classloader, otherwise a get operation might return an object loaded from the wrong classloader. After all, we will only use the provided classloader if we need to get the object from another node or if storeAsBinary is set to true. Dan On Mon, May 2, 2011 at 11:24 PM, Thomas P. Fuller wrote: > How about just using "as" and "using" instead of "asClass" and > "usingClassloader"? > > Consider something like the following which kind of looks like a dsl: > > Foo f = cache.getAdvancedCache().as (Foo.class).using (classLoader).get > (key); > > T > > > From: Sanne Grinovero > To: infinispan -Dev List > Sent: Mon, 2 May, 2011 21:08:47 > Subject: Re: [infinispan-dev] [Pull Request] Modular Classloading > Compatibility > > 2011/5/2 Manik Surtani : >> >> On 1 May 2011, at 13:38, Pete Muir wrote: >> > As in, user API? That's a little intrusive... e.g., put(K, V, cl) ? Not for put, since you have the class, just get, and I was thinking something more like: Foo foo = getUsing(key, Foo.class) >>> >>> This would be a pretty useful addition to the API anyway to avoid user >>> casts. >> >> Maybe as an "advanced" API, so as not to pollute the basic API? A bit >> like: >> >> Foo f = cache.getAdvancedCache().asClass(Foo.class).get(key); > > doesn't look much better than a cast, but is more cryptical :) > > getting back to the classloader issue, what about: > > Cache c = cacheManager.getCache( cacheName, classLoader ); > > or > Cache c = cacheManager.getCache( cacheName ).usingClassLoader(classLoader ); > > BTW if that's an issue on the API, maybe you should propose it to > JSR-107 as well ? > > Sanne > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
