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 >>>>>> >>>>> >>>> >>
