Scott, is that usable in-process, as in no remoting? - Ray
On Thu, Nov 22, 2018, 14:55 Scott Lewis via osgi-dev <osgi-dev@mail.osgi.org wrote: > On 11/22/2018 8:19 AM, Raymond Auge via osgi-dev wrote: > > 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. > > Forgive me if I'm misinterpreting the needs as I haven't read entire > thread, but OSGi Remote Service Admin does have a specified service proxing > [A]. ECF's implementation of RSA [B] allows one to create/use custom > distribution providers that could do method-level caching [B]. > Distribution providers are typically for across-process proxies, but can be > in-process as well. > > Scott > > [A] > https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html#i1742961 > > [B] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project > > > 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 > listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > 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
