Mohamed, if I understand correctly, what you really need in order to cache
method calls are proxies around arbitrary services.
First I don't think there's a OOTB solution for your problem description
specifically to do method caching.
Also, OSGi doesn't natively provide a proxy mechanism. In fact, it
generally goes out of it's way to avoid needing that kind of indirection.
However it does provide a few technologies that give you capabilities to
build this. There are also some open source projects that can help with
this.
In order of depth of integration:
*1. framework weaving hooks* [1]
PROS
- TRANSPARENT to service providers & consumers
- you can control any bytecode used anywhere in the framework from here
CONS
- it can be an intense journey into bytecode manipulation.. if you have
the heart for it you can do crazy stuff here, but it won't be trivial
- start ordering will be your biggest foe
*2. framework service hooks* [2]
PROS
- TRANSPARENT service to providers & consumers
- you can intercept and modify the visibility or accessibility of
services before they are gotten by consumers which means you could proxy
here
CONS
- still pretty low level and high degree of awareness of the OSGi
service registry behaviour is required
- start ordering is also a complexity you need to think about
3. *use an injection framework* that supports proxies
PROS
- use existing technology do to the heavy lifting (spring, CDI...
upcoming spec [3] ... try the RI [4] ..., etc.)
CONS
- service to providers need to use the selected framework
- no unobtrusive, transversal configuration
4. *AspecIO* [5]
PROS
- TRANSPARENT to providers & consumers
- unobtrusive and transversal configuration
- no start ordering issues? (I think Simon built a solution for this
???)
CONS
- start ordering issues? (I think Simon built a solution for this ???)
FYI, this is not a pitch for the project because I'm not involved in it at
all. I only know that it covers almost all your requirements (which I've
extrapolated from between the lines).
Hope that helps in some way.
- Ray
[1]
https://osgi.org/specification/osgi.core/7.0.0/framework.weavinghooks.html
[2]
https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html
[3] https://osgi.org/specification/osgi.enterprise/7.0.0/service.cdi.html
[4]
https://repository.apache.org/content/repositories/snapshots/org/apache/aries/cdi/org.apache.aries.cdi.extender/0.0.2-SNAPSHOT/
[5] https://github.com/primeval-io/aspecio
On Thu, Nov 22, 2018 at 10:34 AM Mohamed AFIF via osgi-dev <
osgi-dev@mail.osgi.org> wrote:
> Hi Alain,
>
> Thanks a lot for sharing your experience, but as I've seen on
> documentation , I'm not sure that infinispan handles cache of methods .
>
> Regards.
>
> Mohamed.
>
>
> Le jeu. 22 nov. 2018 à 11:10, Alain Picard <pic...@castortech.com> a
> écrit :
>
>> If it might help, we are in the process of using Infinispan at our end.
>> It is OSGi compliant (almost) and for Karaf users (not us yet), it comes
>> with features for easy deployment.
>>
>> Alain
>>
>>
>> On Thu, Nov 22, 2018 at 5:02 AM Mohamed AFIF via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Hello everybody,
>>>
>>> We need to implement a cache system in our Karaf (Felix) , our need is
>>> especially to cache method results, but It’s hard to find a cache solution
>>> which is OSGI compliant, Spring can do that but it’s cache feature can be
>>> used only over a spring managed beans, so we ‘re using Blueprint than the
>>> Spring solution could not be used, also spring has some problems to run
>>> inside a Kataf, so we’re thanking to use the AOP, with AspectJ, but we
>>> should manage by ourself the data synchronization …., Thus I would like to
>>> know if some users among this mailing list have already been facing this
>>> problem and which solution could be better to implement inside a
>>> Karaf/Felix,
>>>
>>>
>>>
>>> Thank you very much for your help
>>>
>>>
>>>
>>> M.AFIF
>>>
>>> --
>>>
>>> Cdt
>>> Mohamed AFIF
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
