Hi, Having looked at this forum post thread (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235313#...), I wanted to check, specially with Brian, what's the preferred method in AS5 to get access to a local cache.

First of all, anything bound to JNDI needs to be Serializable. http://www.jboss.org/community/wiki/JMXMBeanRemoteProxy wiki explains how to bind a proxy to an MBean into JNDI and retrieve it remotely. Don't think this is what the user wants though. It looks as if he only wants to access it from diff apps.

Traditionally, there was always the JMX method to retrieve a local Cache instance (see http://is.gd/WOmk) but this section has dissapeared from the latest JBC 3.1 documentation in http://is.gd/WOsH. I know that CacheJmxWrapperMBean and CacheJmxWrapper have been deprecated and instead org.jboss.cache.jmx.JmxRegistrationManager is now in place but it's unclear from the code what's the alternative. One that I can think of is MC bean injection but that assumes your app is build around MC beans which could or not happen. Finally, one thing to note to everyone, if you simply name your MC bean with -beans.xml, it won't deploy it!! Thanks to Emanuel who helped me figure out why a cache instance wouldn't deploy. Instead, it should be named -jboss-beans.xml. I'll create a JIRA to fix this.

Cheers,

Brian Stansberry wrote: > Galder Zamarreno wrote: >> Hi, >> >> Having looked at this forum post thread >> (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235313#...), >> I wanted to check, specially with Brian, what's the preferred method >> in AS5 to get access to a local cache. >> > > Couple methods, discussed in more detail at http://tinyurl.com/lq688t > section 11.2 > > 1) Use the CacheManager to create your cache; the CacheManager is > available in JNDI at java:/CacheManager. See Section 11.2.1. > > 2) Use CacheJmxWrapperMBean and it's "cache" mbean attribute. Simplest > way is to deploy it via a -service.xml. Section 5.4.2 of JBC 3.1 docs > at http://tinyurl.com/m49qen has other methods.

Agreed that maintaining AS integration docs in the JBC docs will lead to errors. Not that the AS docs aren't woefully out of date. :( But that will be fixed by end of month and thereafter <determination>they won't be badly out of date again as long as I'm involved.</determination> I think AS integration notes in JBC/Infinispan should largely limit themselves to notes on any config changes that JBC/Infinispan made since the last AS release; i.e. stuff the AS docs couldn't cover. Galder Zamarreno wrote: > Brian, > > Thanks very much for providing such detailed information and the > revised version of the AS Clustering Guide. I'll make sure I have a > read to the entire guide asap since it contains very important > information that I was not aware of. > > Also, this makes me think that the whole 5.2 and 5.3 sections in the > JBC docu (http://is.gd/13oVC) should go away or simply refer/link to > AS Clustering Guide, since AS Clustering knows how to do this best and > the JBC docu, unless kept tightly in check, will always be outdated. > Thoughts? > > Cheers, > > Brian Stansberry wrote: >> Galder Zamarreno wrote: >>> Hi, >>> >>> Having looked at this forum post thread >>> (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235313#...), >>> I wanted to check, specially with Brian, what's the preferred method >>> in AS5 to get access to a local cache. >>> >> >> Couple methods, discussed in more detail at http://tinyurl.com/lq688t >> section 11.2 >> >> 1) Use the CacheManager to create your cache; the CacheManager is >> available in JNDI at java:/CacheManager. See Section 11.2.1. >> >> 2) Use CacheJmxWrapperMBean and it's "cache" mbean attribute. >> Simplest way is to deploy it via a -service.xml. Section 5.4.2 of JBC >> 3.1 docs at http://tinyurl.com/m49qen has other methods. >> >>> First of all, anything bound to JNDI needs to be Serializable. >>> http://www.jboss.org/community/wiki/JMXMBeanRemoteProxy wiki >>> explains how to bind a proxy to an MBean into JNDI and retrieve it >>> remotely. Don't think this is what the user wants though. It looks >>> as if he only wants to access it from diff apps. >>> >> >> Remoting proxies to pojos can also be created. JBAS-4456. See forum >> discussion at http://tinyurl.com/n3zbgr and a test case example >> deployment config at http://tinyurl.com/lyta4y. But, as discussed on >> that forum thread, the JNDI-registration part got separated out into >> a separate concern, meant to be handled via the @JndiBinding >> annotation. Sometime after that discussion, support for @JndiBinding >> got removed from the default/all configs. It can be added back by >> including >> >> >> <lifecycle-configure xmlns="urn:jboss:aop-beans:1.0" >> name="JndiBindingAdvice" >> >> class="org.jboss.aop.microcontainer.aspects.jndi.JndiLifecycleCallback" >> classes=&quot;(a)org.jboss.aop.microcontainer.aspects.jndi.JndiBinding&quot; >> manager-bean="AspectManager" >> manager-property="aspectManager"/> >> >> in a -jboss-beans.xml, but, well, that whole process is just too much >> to advise as some sort of standard way of accessing JBC. Particularly >> since a remote proxy to org.jboss.cache.Cache isn't really valid; it >> doesn't cover the Node interface. >> >>> Traditionally, there was always the JMX method to retrieve a local >>> Cache instance (see http://is.gd/WOmk) but this section has >>> dissapeared from the latest JBC 3.1 documentation in http://is.gd/WOsH. >>> >>> I know that CacheJmxWrapperMBean and CacheJmxWrapper have been >>> deprecated and instead org.jboss.cache.jmx.JmxRegistrationManager is >>> now in place but it's unclear from the code what's the alternative. >>> One that I can think of is MC bean injection but that assumes your >>> app is build around MC beans which could or not happen. >>> >>> Finally, one thing to note to everyone, if you simply name your MC >>> bean with -beans.xml, it won't deploy it!! Thanks to Emanuel who >>> helped me figure out why a cache instance wouldn't deploy. Instead, >>> it should be named -jboss-beans.xml. I'll create a JIRA to fix this. >>> >> >> Thanks for fixing that! >> >>> Cheers, >> >> >