Re: a few things -- RE: cvs commit: jakarta-turbine-stratum/src/java/org/apache/stratum/jcs/engine/control/group GroupAttrName.java

[John McNally <jm...@collab.net>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>