Re: [osgi-dev] Circular references with Factory component

[Alain Picard via osgi-dev]

Thanks for the clarification. I already broke the cycle, but I was working
on the wrong impression in regards to factory components.

Alain


On Fri, Nov 23, 2018 at 11:02 AM Tim Ward  wrote:

> The critical part of the spec is available at
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-factorycomponent
>  -
> the key words are
>
> *"SCR must register a Component Factory service on behalf of the component
> as soon as the component factory is satisfied." *
>
>
> The Component Factory can’t be satisfied until its reference Y is
> satisfied, which in turn can’t be registered until its mandatory dependency
> X is satisfied. As we can see X won’t be registered until the
> ComponentFactory reference is satisfied. This prevents the whole thing from
> starting.
>
> You need to break the cycle for this to work. Either you need to change
> the composition of your services, or you need to use Dynamic/Optional for
> one of the references.
>
> I hope this helps,
>
> Tim
>
>
>
> On 23 Nov 2018, at 07:52, Alain Picard via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Been running into an issue with circular references dealing with
> ComponentFactory and I'm a bit confused.
>
> I have:
> @Component
> class A implements X {
> @Reference(target = CoreDeleteEObjects.CONFIG_TARGET)
> private ComponentFactory coreDeleteFactory;
> 
> }
>
> and the factory component matching my target has a reference to Y which
> itself has a reference to X. Granted this fails with "standard" references.
> But here I was under the impression that the referenced service was the
> ComponentFactory and that the service would get resolved at startup.
> Testing indicates that I'm wrong.
>
> What part of the puzzle am I missing?
>
> Thanks
> Alain
> ___
> 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

Re: [osgi-dev] Circular references with Factory component

[Tim Ward via osgi-dev]

The critical part of the spec is available at 
https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-factorycomponent
 

 - the key words are 

"SCR must register a Component Factory service on behalf of the component as 
soon as the component factory is satisfied." 

The Component Factory can’t be satisfied until its reference Y is satisfied, 
which in turn can’t be registered until its mandatory dependency X is 
satisfied. As we can see X won’t be registered until the ComponentFactory 
reference is satisfied. This prevents the whole thing from starting.

You need to break the cycle for this to work. Either you need to change the 
composition of your services, or you need to use Dynamic/Optional for one of 
the references.

I hope this helps,

Tim



> On 23 Nov 2018, at 07:52, Alain Picard via osgi-dev  
> wrote:
> 
> Been running into an issue with circular references dealing with 
> ComponentFactory and I'm a bit confused.
> 
> I have:
> @Component
> class A implements X {
> @Reference(target = CoreDeleteEObjects.CONFIG_TARGET)
> private ComponentFactory coreDeleteFactory;
> 
> }
> 
> and the factory component matching my target has a reference to Y which 
> itself has a reference to X. Granted this fails with "standard" references. 
> But here I was under the impression that the referenced service was the 
> ComponentFactory and that the service would get resolved at startup. Testing 
> indicates that I'm wrong.
> 
> What part of the puzzle am I missing? 
> 
> Thanks
> Alain
> ___
> 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

Re: [osgi-dev] Usinge Cache in Karaf

[Mohamed AFIF via osgi-dev]

Hello Raymond,

Thanks to taking time to answers me. In fact perhaps that an OOTB is not a
solution of my problem, but the feature that I need is the  same as Spring
cache provides,  where we can cache methods. and as it is very hard to
incorporate spring in Karaf, i was looking for an OOTB that imlements the
same behaviour. and I was looking for an OOTB because im So clearly our
need is:
-caching system :
*available and shared with all bundles inside Karaf.
   * We need to cache object in read and write mode
   * We need to cache methods
   * if it is possible (not necessary) distibued cache
which could be shared between many instances of Karaf


The solution that we've choosen to implement  that (if we don't find an
OOTB) is based on Ehcache and AOP using AspectJ , and according to your
response I see that there is  AspecIO  which is karaf compliant, but I
don"t know which better  AspectJ  or  AspecIO.

Regards,

Mohamed


Le jeu. 22 nov. 2018 à 17:19, Raymond Auge  a
écrit :

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