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/deltaspike/modules/cache >>>>> >>>>> If you think this is useful, please let me know what it takes > to get >>> this >>>> stuff into DeltaSpike. >>>>> >>>>> Best regards, >>>>> Harald >>>>> >>>> >>> >
