[
https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597834#action_12597834
]
Henning Schmiedehausen commented on SHINDIG-279:
------------------------------------------------
Uhm, as a "default, this is how a cache should look like" implementation, this
is likely to be overkill. And it drags in another dependency which in turn
might drag in others. I'd say that the shindig core itself should be as lean as
possible. An ehcache based, production-ready cache is nice but is it needed to
get started? Does it add complexity that is not needed to get the sample
container running?
An Apache project need not to have an preference towards fellow Apache
projects. EHCache is fine, as long as the license is compatible (which I
believe it is). We should never sacrifice technical advantages just for the
sake of "using another Apache project" but judge all projects based on
technical merit and then decide.
> Configurable and clusterable cache for Gadgets server
> -----------------------------------------------------
>
> Key: SHINDIG-279
> URL: https://issues.apache.org/jira/browse/SHINDIG-279
> Project: Shindig
> Issue Type: Improvement
> Components: Gadget Rendering Server (Java)
> Reporter: Ian Boston
> Attachments: SHINDIG-279.patch
>
>
> If the the Gadgets server is going to perform caching, then a configurable
> cache that has all the features that you might expect in production. Attached
> is a patch to put ehcache behind the Cache interface and introduce a
> ShindigCacheManager, that registers with JMX for statistics and management.
> The patch is fully integrated into the gadgets server guice config, with
> tests for each class. It also appears to startup Ok.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
