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
