JCS has low activity, but there is a fairly low bar to committership @ Commons for existing Apache committers. One problem with JCS, IIRC, is that it is documented as being fundamentally incompatible with JSR-107. I personally have thought it would be a good thing to surmount whatever obstacles there may be to create a JCS-backed Java cache implementation, but I have no practical idea what that would entail.
Matt On Thu, Dec 20, 2012 at 10:00 AM, Arne Limburg < [email protected]> wrote: > Maybe we should integrate with http://commons.apache.org/jcs/index.html? > Don't know how active it is, though > > > Am 16.12.12 13:36 schrieb "Mark Struberg" unter <[email protected]>: > > >I found a bit time to quickly look over the JSR-107 spec. Indeed the > >@CacheResult, @CachePut, @CacheMethod, etc look fairly similar to what > >Harald implemented. I can definitely see a need for a simple > >implementation of JSR-107, but this would by far exceed the goals of this > >project. Haralds code seems to implement most parts already (just missing > >the Transaction stuff?), so might serve as base for a new 'Simple JCache' > >or 'Local JCache' implementation ;) > > > > > >Otoh a basic JCache CDI integration is nothing else than a ProducerMethod > >which wraps CacheManager and CacheManagerFactory. It would be easy (and > >preferable) to add those to the JSR-107 spec itself imo... > > > >LieGrue, > >strub > > > > > > > > > >----- Original Message ----- > >> From: Pete Muir <[email protected]> > >> To: [email protected] > >> Cc: > >> Sent: Monday, December 10, 2012 11:58 AM > >> Subject: Re: Cache module > >> > >> JSR-107 doesn't specify how you can inject a cache, just how the > >>caching > >> annotations work. Injecting a cache would be something DeltaSpike could > >>do IMO > >> (or we should ask JSR-107 to specify it really ;-). > >> > >> Note the annotations can basically be implemented using just JSR-107 > >>API, you > >> don't need a vendor API to impl. So the RI also includes a portable > >>impl of > >> the annotations AIUI. > >> > >> On 8 Dec 2012, at 22:42, Gerhard Petracek wrote: > >> > >>> hi @ all, > >>> > >>> that isn't an easy topic. if we add more or less a jsr-107 > >> implementation, > >>> we also have to think about e.g. jsr-352 and many others. > >>> -> imo ds shouldn't implement any jsr. > >>> > >>> only if a jsr is way too complex and we need a very simple/small > >>> alternative or it doesn't include a (full) cdi integration or there > >>>are > >>> missing parts like some cdi scopes, we should think about adding such > >> parts. > >>> > >>> regards, > >>> gerhard > >>> > >>> > >>> > >>> 2012/12/8 Mark Struberg <[email protected]> > >>> > >>>> well, the javax.* namespace is not a problem. We do all those > >> centralized > >>>> over in the geronimo specs project [1][2]. There you find all EE > >>>>specs > >> with > >>>> ALv2 licenses. This is perfectly fine and there is also no legal > >>>>issue > >>>> involved. We need the jcache-api jar anyway, so this would be a good > >> chance > >>>> to hack it down. > >>>> > >>>> The implementation itself is another story. We can of course use the > >>>> JSR-107 annotations and should at least 'loosely' follow the > >> specification. > >>>> But as long as we do not claim we are a compliant JCache > >>>>implementation > >> we > >>>> do not need to implement all the functionality and pass the TCK. > >>>> I quickly did read through the spec license and it's full of the > >> usual > >>>> nonsense which doesn't hold in front of any court and is only there > >> to shy > >>>> away small kids ;) > >>>> > >>>> The TCK is available for Open Source projects free of charge it > >>>>seems. > >>>> Well we are drifting away it seems. Imo we should only do a minimal > >>>> implementation which might use some JSR-107 annotations if they area > >>>>of > >> any > >>>> help - but if we aim to do a full implementation then this should be > >>>>a > >>>> project completely on it's own. > >>>> > >>>> LieGrue, > >>>> strub > >>>> > >>>> > >>>> > >>>> [1] https://svn.apache.org/repos/asf/geronimo/specs/trunk/ > >>>> [2] http://repo1.maven.org/maven2/org/apache/geronimo/specs/ > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: Harald Wellmann <[email protected]> > >>>>> To: "[email protected]" < > >>>> [email protected]> > >>>>> Cc: > >>>>> Sent: Saturday, December 8, 2012 7:25 PM > >>>>> Subject: Re: Cache module > >>>>> > >>>>> Hi all, > >>>>> > >>>>> thanks for your feedback. > >>>>> > >>>>> This module draft is just a spin-off of migrating an application > >> from > >>>>> Spring 3.1 to Java EE 6 and I didn't really have JSR-107 on > >> radar at > >>>>> that time. > >>>>> > >>>>> On the one hand, I'm all for being standard-compatible, on the > >> other > >>>>> hand, I'd rather have a working solution soon than a JSR-107 > >> compliant > >>>>> implementation some time in 2014... > >>>>> > >>>>> Then there's the issue about the javax.* namespace. As long as > >> the JSR > >>>>> isn't finalized, I'm not sure if its a good idea or even > >> legally > >>>>> possible to publish implementations containing API classes in this > >>>>> namespace. There is a javax.cache 0.2 artifact on Maven Central but > >>>>> that's not in sync with the sources at > >>>>> https://github.com/jsr107/jsr107spec (0.6-SNAPSHOT). > >>>>> > >>>>> To have the best of both worlds, org.apache.deltaspike.cache.api > >> could > >>>>> be made syntactically equivalent to a current javax.cache version > >> to > >>>>> minimize the impact on users. Ideally, they'd only have to > >> rename > >>>>> packages in their own sources once javax.cache is released. > >>>>> > >>>>> What do you think? > >>>>> > >>>>> Best regards, > >>>>> Harald > >>>>> > >>>>> Am 08.12.2012 17:03, schrieb Adrian Gonzalez: > >>>>>> Hello, > >>>>>> > >>>>>> Looks interesting, but why don't you use JCache CDI > >> annotations as > >>>>> mentioned in [1] ? > >>>>>> > >>>>>> I know that JCache isn't finished yet, but I think it's > >> already > >>>>> usable. > >>>>>> I'm using them in a sample app and it works great with > >> ehcache impl > >>>>> (using 0.4 version). > >>>>>> > >>>>>> Perhaps I've missed something though. > >>>>>> If not, aren't we going to duplicate standard > >>>>> javax.cache.interceptor.CacheResult annotation with > >>>>> org.apache.deltaspike.cache.api.Cacheable ? > >>>>>> > >>>>>> [1] http://java.dzone.com/articles/using-cdi-access-infinispan > >>>>>> > >>>>>> Extract from [1] : > >>>>>> @CacheResult(cacheName="user-cache") public User > >> findUser(long > >>>>> id) { User user = Š; // retrieve the user with the given id return > >> user; > >>>> } > >>>>>> > >>>>>> ________________________________ > >>>>>> De : Harald Wellmann <[email protected]> > >>>>>> À : [email protected] > >>>>>> Envoyé le : Samedi 8 décembre 2012 15h57 > >>>>>> Objet : Cache module > >>>>>> > >>>>>> I've started working on what might become a new DeltaSpike > >> module for > >>>>> caching, see https://issues.apache.org/jira/browse/DELTASPIKE-282. > >>>>>> > >>>>>> The sources are at > >>>>>> > >>>>> > >>>> > >> > >> > https://github.com/hwellmann/incubator-deltaspike/tree/hwellmann/deltaspi > >>ke/modules/cache > >>>>>> > >>>>>> If you think this is useful, please let me know what it takes > >> to get > >>>> this > >>>>> stuff into DeltaSpike. > >>>>>> > >>>>>> Best regards, > >>>>>> Harald > >>>>>> > >>>>> > >>>> > >> > >
