On 9/9/10 3:12 PM, James Abley wrote: > On 9 September 2010 18:42, Gadbury <[email protected]> wrote: > >> >> Hi all, >> >> I have read the CacheManager article on the Jackrabbit Wiki. I have also >> searched around for a solution. >> >> I am using the following code: >> >> Repository repository = >> RepositoryServiceLocator.INSTANCE.getRepository(); >> CacheManager manager = >> ((RepositoryImpl)repository).getCacheManager(); >> >> manager.setMaxMemory (256 * 1024 * 1024); >> // default is 16 * 1024 * >> 1024 >> manager.setMaxMemoryPerCache (64 * 1024 * 1024); // >> default is 4 * 1024 * >> 1024 >> manager.setMinMemoryPerCache (1 * 1024 * 1024); >> // default is 128 * >> 1024] >> >> I am getting the exception: >> >> java.lang.ClassCastException: >> org.apache.jackrabbit.core.jndi.BindableRepository cannot be cast to >> org.apache.jackrabbit.core.RepositoryImpl >> >> How else can I get the CacheManager? >> >> James >> -- >> View this message in context: >> http://jackrabbit.510166.n4.nabble.com/CacheManager-Cannot-Cast-BindableRepository-to-RepositoryImpl-tp2533300p2533300.html >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com. >> > > > We do something similar; we have an MBean that exposes this. But as you say, > the internals aren't exposed so it's a little messy. Basically, we use > reflection and rely on the lack of SecurityManager in the environments in > which we deploy. > > Initially we looked for a Field of a particular name, then called > Field.setAccessible(true) and finally use Field.get(Object). > > This broke when the field was renamed in Jackrabbit 1.4 versus 1.6. Now we > enumerate the Fields looking for a class of RepositoryImpl. That is a little > more robust. But still not using a published API. > > We'd be interested in seeing a more sanctioned way of achieving this, and > also increasing the amount of JMX functionality exposed by Jackrabbit. > > Cheers, > > James > So why not submit patches containing your MBeans?
Justin
