commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: Please? WAS: Re: [JCS] Asking for advice: separate CacheAccess and GroupCacheAccess?
Date Thu, 10 Oct 2013 16:43:19 GMT
Sorry Thomas!!! I intended to have a look at this but then we started a lot
of discussions here. I just forgot it. I'll try to have a look!

Benedikt


2013/10/10 Thomas Vandahl <tv@apache.org>

> On 03.10.13 13:30, Thomas Vandahl wrote:
> > Hi folks,
> >
> > I'd like to ask for suggestions for a problem solution regarding the
> > typesafe handling of cache keys in JCS.
> >
> > Previously, JCS was not aware of key and value types. So it was possible
> > to mix cache elements having different key types within the same cache
> > instance. This "feature" was abused to implement the cache groups, so
> > that keys of e.g. type String were combined with keys of type
> GroupAttrName.
> >
> > The current implementation implements this functionality by hacking
> > around the generics type definitions (in all cache implementations)
> > which is definitely not desirable. It also may cause ClassCastExceptions.
> >
> > As I see it, it would be better to use some kind of decorator pattern
> > for the GroupCacheAccess functions that wraps around a regular
> > CacheAccess object. This would mean type-safety at the cost of major API
> > changes. Also it would have the advantage that the cache implementations
> > do not have to know about cache groups at all.
> >
> > Are there better solutions? Other ideas how to resolve this?
> > Your thoughts are very much appreciated.
>
> No ideas? Really? Please help, I need a second opinion.
>
> Bye, Thomas.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message