Aaron Smuts wrote: ... > 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 started using a special purpose object as the key when using jcs within torque. I did not get any casting exceptions, though I am only using the memory cache, so I have not tested the full functionality. Can you point to where the hierarchy is implemented? What happens if the key contains colons that are not meant as separators? > 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. You use the value of general keys in creating GroupAttrName and GroupId. And I am using it in torque. I would like to see the wildcard implementation. But looping over all the keys parsing each one to look for a partial string does not sound efficient. > > Any thought on the value of non String keys? I have a List that I would like to cache. The objects that are in the list depend on a set of other objects. So I make the set of objects the key. Not sure how I can use a String to accomplish this easily and I cannot force the positions of colons. I guess I could make sure to remove any colons from any strings that are generated. What is the overhead of groups that makes all this work attractive? > > > > > 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. > I was assuming CacheException would be the main/general exception thrown by jcs. I'm all for moving it to the top level. For that matter I think the interfaces should be top level with implementations pushed further down. john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
