On Thu, Nov 22, 2018, 15:30 Raymond Auge <raymond.a...@liferay.com wrote:
> 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. >> > Oops, I see you did say that! Cool use case. I'll add that to my magic bag of tricks 😉 - Ray 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
