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