Hi: Sorry I haven't had much time to work on JCS this month. My schedule goes in cycles.
A few comments: > Log: > fixed several places that were assuming keys were Strings, they can be > any Serializable object. This may not (or should not?) be the case. There is a hierarchy functionality that may assume that the keys are strings. The keys are checked to see if they end with the wild card ":". We could add a special remove method that forced string keys? I started forcing the string values for a reason. I can't remember the status of this. I see little value in non string keys. We can get much more functionality with string keys. The partial removal is extremely powerful. It allows you to avoid the overhead of groups and clean up quickly. It cannot be sacrificed. Any thought on the value of non String keys? > > fixed one place that assumed the group name was an Object. It is > currently > always a String. > > made CacheException extend commons NestedException. This gave a > classpath > issue in RMI, that I do not fully understand, but giving the commons- > lang jar > as a classpath attribute allows the build to work. > > fixed a few places where jcs was ignoring exceptions with no explanation > as to > why. There are quite a few more. > Early on, following JCache, I started throwing exceptions for common scenarios like the object was not found or already existed. This made it cumbersome to use and followed a model of excessive exception throwing that I find distasteful, so I removed them. In the process I commented out a few IOExceptions that maybe I shouldn't have. I'm not sure that an exception will ever get pushed up that high though. I'd like for the user to only have to import the root package. They should be able to use the JCS access class. Maybe a root or abstract JCSException class should be put in the same folder to make it easier to use. There is nothing worse then having to figure out a million imports to use third party software. Cheers, Aaron
