Hi,
On 28 nov. 2012, at 15:33, Bengt Rodehav <[email protected]> wrote: > Thanks again - it worked fine. > Great ! > Do you think this a bad idea (The "May lead to fun cases" got me a little > worried)? > > What I'm doing is making my filter dynamic. In this case a configuration > property is used to wire my service against the appropriate service > providers. The service providers expose a list of "qualifiers" (as service > properties) that they support. The service consumer specifies a "qualifier" > that is required. By dynamically setting the filter I can change the > service consumers service requirements dynamically in runtime. > There is a couple of things that can happen: - if you touch the dependency in the same thread as the filter update, the provider set won't change for the current thread (others will be updated) - if you change the filter and the instance becomes invalid, you will have issues if you try to access (untouched) dependency within the same thread. I would advise to set the dependency optional to avoid the last issue. Regards, Clement > /Bengt > > > 2012/11/28 Clement Escoffier <[email protected]> > >> Hi, >> >> Are you trying to modify your own filter ? May lead to fun cases :-) >> >> In that case: >> >> InstanceManager me = (InstanceManager) ((Pojo) >> this).getComponentInstance(); >> >> >> Explanations: >> - each iPOJO instance is implementing a org.apache.felix.ipojo.Pojo >> interface >> - so implements the getComponentInstance method returning a >> ComponentInstance >> - you cast the ComponentInstance to InstanceManager and you're back on >> track >> >> Regards, >> >> Clement >> >> >> On 28 nov. 2012, at 14:19, Bengt Rodehav <[email protected]> wrote: >> >>> Sorry for bothering you again.... >>> >>> I use iPOJO annotations like this: >>> >>> * @Component(name = "componentName", propagation = true, immediate = >> true)* >>> * @Provides* >>> * public class MyClass {* >>> >>> >>> I tried the following cast: >>> >>> * InstanceManager im = (InstanceManager) this;* >>> >>> where "this" is an instance of MyClass. The cast doesn't work since >>> MyClass is not a sub class of InstanceManager. How do I get hold of a >>> component instance? >>> >>> /Bengt >>> >>> >>> >>> >>> 2012/11/28 Bengt Rodehav <[email protected]> >>> >>>> Thanks a lot, will try this approach. >>>> >>>> /Bengt >>>> >>>> >>>> 2012/11/28 Clement Escoffier <[email protected]> >>>> >>>>> Hi, >>>>> >>>>> The DependencyModel is the parent class of all the iPOJO's service >>>>> dependencies. So, the easiest way is to access to your service >> dependency: >>>>> >>>>> InstanceManager im = (InstanceManager) componentInstance; >>>>> DependencyHandler handler = >>>>> im.getHandler("org.apache.felix.ipojo:requires"); >>>>> Dependencies[] deps = handler.getDependencies(); >>>>> // Lookup your dependency from deps (by id, by specification…) >>>>> dep.setFilter(filter); >>>>> >>>>> Regards, >>>>> >>>>> Clement >>>>> >>>>> >>>>> >>>>> >>>>> On 28 nov. 2012, at 13:09, Bengt Rodehav <[email protected]> wrote: >>>>> >>>>>> Thanks for you reply Clement, >>>>>> >>>>>> So, the following should work (in principal)? >>>>>> >>>>>> * @Property(name = "myProperty" mandatory = true)* >>>>>> * public void setMyPropertey(String theProperty) {* >>>>>> * // Calculate new filter based on myProperty* >>>>>> * String filter = ....* >>>>>> * >>>>>> * >>>>>> * // How do I get an instance of "DependencyModel"?* >>>>>> * DependencyModel.setFilter(filter);* >>>>>> * }* >>>>>> >>>>>> I've never used the DependencyModel class before. How do I gain access >>>>> to >>>>>> the correct instance? What maven artifact do I need for this? >>>>>> >>>>>> /Bengt >>>>>> >>>>>> >>>>>> 2012/11/28 Clement Escoffier <[email protected]> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Using the iPOJO API you can use 'setFilter' to update the LDAP filter >>>>> of a >>>>>>> dependency (DependencyModel.setFilter). When changed the set of bound >>>>>>> services is recomputed. Be aware that it may lead to an invalidation >>>>> of the >>>>>>> instance if no providers match the new filter. >>>>>>> >>>>>>> What we did in the past is to develop a handler receiving the new >>>>>>> properties, computing the new filter and applying it to the targeted >>>>>>> dependency. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Clement >>>>>>> >>>>>>> On 27 nov. 2012, at 11:41, Bengt Rodehav <[email protected]> wrote: >>>>>>> >>>>>>>> I'm using the latest iPOJO version. I'm trying to use configuration >>>>>>>> properties (via config admin) to make my service wiring dynamic. >>>>>>>> >>>>>>>> I have handler services that expose service properties (that tells >> the >>>>>>>> world what they can handle). The consumer of these services uses >>>>> @Require >>>>>>>> with an LDAP filter to specify what needs to be handled and thus >> limit >>>>>>> what >>>>>>>> handlers can be used. >>>>>>>> >>>>>>>> But, I want the LDAP filter to be dynamic so that I can wire up >>>>> service >>>>>>>> providers with service consumers by configuration properties on the >>>>>>>> consumers and providers. >>>>>>>> >>>>>>>> I've tried to buld the LDAP filter dynamically (using a configurable >>>>>>>> property) but I get the compilation error: >>>>>>>> >>>>>>>> * The value for annotation attribute Requires.filter must be a >>>>> constant >>>>>>>> expression* >>>>>>>> >>>>>>>> I was hoping that if I changed a configuration property, iPOJO would >>>>>>>> refresh its list of provider services to match the changed LDAP >>>>> filter. >>>>>>>> >>>>>>>> How can I accomplish what I want? Is there a best practice? >>>>>>>> >>>>>>>> /Bengt >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
