TreeCacheAop getKeys returns null for filled cache

[gregorypierce]

I've filed a bug on this, but have included this post for any discussions (since there was a space for it on JIRA). I have a stupid rectangle object that I want to put in the cache.

public class Rectangle implements Serializable
{
 public static Logger logger = Logger.getLogger("Rectangle");

 private int x;
 private int y;
 private int width;
 private int height;

 public int getX()
 {
 return x;
 }

 public void setX(int x)
 {
 this.x = x;
 }

 public int getY()
 {
 return y;
 }

 public void setY(int y)
 {
 this.y = y;
 }

 public int getWidth()
 {
 return width;
 }

 public void setWidth(int width)
 {
 this.width = width;
 }

 public int getHeight()
 {
 return height;
 }

 public void setHeight(int height)
 {
 this.height = height;
 }

}

I use the following code to store the object in the cache and get the keys back (as per some of the sample code)

 public static void main( String[] args )
 {
 BasicConfigurator.configure();

 try
 {
 TreeCacheAop cache = new TreeCacheAop();
 cache.startService();

 cache.putObject("foo", new Rectangle());

 Set keys = cache.getKeys("");

 logger.debug( "" + keys.size() );
 }
 catch( Exception e )
 {
 logger.error("Something bad happened", e);
 }
 }

[ben.wang]

You are not using the CacheAop correctly. If you want fine grain replication, you don't need Serializable for your Rectangle object. Instead, use either annotation or declare it in jboss-aop.xml.

Please theck the TreeCacheAop doco for how to.

-Ben

[gregorypierce]

Interesting. I would have expected the API to throw a warning or error in this case as I can actually put things in the cache and remove them from the cache without issue.

Right now all I want to do is put things in it and get the list of things that are in it. I wasn't expecting to have to either annotate or specify things in the XML file since the object is introspectable and serializable. But if that's how it works, I'll give it a shot and see if I get keys back.

The expected behavior would have been that if it couldn't get the keys back due to API use, it shouldn't have inserted the object in the cache at all. No point having everything else work except getKeys(). Somewhat counter-intuitive.

[gregorypierce]

Yeah I just swapped everything over to using regular TreeCache and now I can move my serialized objects around. While being able to move less data by virtue of using AOP to replicate only the values that changed is ideal, having to aspect every object in my framework is definitely not reasonable for me at this time. This is something that needs to be hidden away somehow.

[gregorypierce]

Interestingly enough I was trying to resolve my getKeys() issue with regular old TreeCache and figured I'd swap back to TreeCacheAop again. The following works without returning me null.

 public static void main( String[] args )
 {
 BasicConfigurator.configure();

 try
 {
 TreeCacheAop cache = new TreeCacheAop();
 cache.createService();
 cache.startService();

 cache.put("/foo", "foo", new Rectangle() );
 cache.put("/foo", "bar", "Something Else" );
 cache.put("/foo/bar", "barchild", "Child of bar");


 Set children = cache.getChildrenNames("/");
 Set keys = cache.getKeys("/foo");


 logger.debug("Cache contains ["+ cache.getNumberOfNodes() + "] nodes");
 logger.debug("Children of / are " + children.size() + "[" + children + "]" );
 logger.debug("Cache members are " + cache.getMembers().size() );

 logger.debug("" + keys.size() );
 }
 catch( Exception e )
 {
 logger.error("Something bad happened", e);
 }
 }

The issue turns out to be with what I'm passing to getKeys(). There doesn't seem to be a way to actually get the keys of the entire tree so passing "/" returns back a null (as opposed to an empty set) so unless you actually know what you want to get out of the cache - you will have to rig some way to talk the tree to figure out what is actually in it :)

[ben.wang]

Looking at the code, I would think "/" should work as well. Can you open a Jira issue then (jira.jboss.com under JBossCache)?

It'd be nice if you can turn your code into a JUnit test case and attach there. :-)

Thanks,

-Ben