You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Thomas Vandahl <tv...@apache.org> on 2013/10/10 18:32:01 UTC
Please? WAS: Re: [JCS] Asking for advice: separate CacheAccess and
GroupCacheAccess?
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
Re: Please? WAS: Re: [JCS] Asking for advice: separate CacheAccess
and GroupCacheAccess?
Posted by Thomas Vandahl <tv...@apache.org>.
Hi Benedikt,
On 28.10.13 12:53, Benedikt Ritter wrote:
> Trunk already contains 2.0-SNAPSHOT so it looks like someone intended to
> roll out a new major release.
Yep, that was me. And yes, this is my intention. The said issue must be
fixed first, however. And I'm planning to add some JMX monitoring
facilities.
> Your explainations sound like we're currently hacking around the Java type
> system and your proposed solution sounds reasonable (as far as I can
> judge).
> So I'd say: go for it. It may be easier to discuss design changes for
> others when they actually see the changes in the code.
Ok, I'll see what I can do.
Thanks, anyway, for responding.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Please? WAS: Re: [JCS] Asking for advice: separate CacheAccess
and GroupCacheAccess?
Posted by Benedikt Ritter <br...@apache.org>.
Hi Thomas,
I just can't find the time to have a deep look at JCS - sorry about that.
JCS 1.3 targeted Java 1.3 and it was released in 2007.
Trunk already contains 2.0-SNAPSHOT so it looks like someone intended to
roll out a new major release.
Your explainations sound like we're currently hacking around the Java type
system and your proposed solution sounds reasonable (as far as I can
judge).
So I'd say: go for it. It may be easier to discuss design changes for
others when they actually see the changes in the code.
Benedikt
2013/10/10 Benedikt Ritter <br...@apache.org>
> 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
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: Please? WAS: Re: [JCS] Asking for advice: separate CacheAccess
and GroupCacheAccess?
Posted by Benedikt Ritter <br...@apache.org>.
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