Yes, I see the point. He wants the service to become available before the dependency arrives.
Sry for the confusion. On May 4, 2009, at 7:55 AM, Toedter, Kai wrote: @Hal, but DM will always create the service component eagerly since it does not support lazy instantiation, right? Kai Well, Spring/DM will still work. The issue will be when he tries to actually send a message to the service, in which case it will throw a runtime exception. On May 4, 2009, at 7:31 AM, BJ Hargrave wrote:
This does not sound like a "flicker" problem. DS can handle that also for a dynamic 1..1 reference. The new service would be passed to bind before the old service is passed to unbind. So the component is never without a dependent service.
I think the issue here is that there is no replacement service available and, with a 1..1 cardinality, the component is deactivated. -- | office: +1 386 848 1781 mobile: +1 386 848 3788
|
From: | | To: | | Date: | 2009/05/04 10:24 | Subject: | Re: [equinox-dev] policy="dynamic" in Declarative Services. | Sent by: | |
There's also Spring/DM, which does I think what you want - i.e. 1..1 cardinality, but not dropping the service is its dependencies momentarily flicker.
On May 4, 2009, at 6:53 AM, Neil Bartlett wrote:
> You cannot directly do this, because mandatory reference is mandatory > at all times. However, you could make the reference optional and > perform some kind of internal activation/deactivation in the > bind/unbind methods. > > However, if that still doesn't work for you then you're trying to do > something outside the scope of use-cases supported by DS, so you > should drop down to the ServiceTracker API. > > Regards, > Neil > > > On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma > <sameera.madushan@xxxxxxxxx> wrote: >> Hi Kai, >> >> On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai <kai.toedter@xxxxxxxxxxx >> > >> wrote: >>> >>> HI Sameera, >>> >>> >>> >>> I think Equinox’ behavior is correct here. If you have a mandatory >>> service >>> reference that is not valid anymore, the referring component has >>> to be >>> deactivated even if the policy is dynamic. >> >> I agree with your point. Now say that the service is mandatory >> when the >> component is activated. Once the component is activated, the >> service is a >> optional one. That mean I don't want my component to be de- >> activated when >> the service is unregistered. How can I handle this situation with >> declarative services? >> >> Thanks >> Sameera >>> >>> >>> >>>> But my requirement is that the service should be registered >>>> before the >>>> component is activated. >>> >>>> in that case I have to put cardinality as "1..1" right? >>> >>> I guess your question is related to the lazy activation of >>> components. >>> This is the default unless you declare the component itself >>> “immediate”. The >>> meaning is: Unless no one wants to use your service, the component >>> (the >>> implementing Java class) will not be instantiated. >>> >>> >>> >>> Best regards, >>> >>> >>> >>> Kai >>> >>> >>> >>> From: equinox-dev-bounces@xxxxxxxxxxx >>> [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Sameera >>> Jayasoma >>> Sent: Montag, 4. Mai 2009 04:59 >>> To: Equinox development mailing list >>> Subject: Re: [equinox-dev] policy="dynamic" in Declarative Services. >>> >>> >>> >>> Hi, >>> >>> On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin <bluedavy@xxxxxxxxx> >>> wrote: >>> >>> if u want to the component isn't deactivated,u should set the bound >>> service cardinality to "0..1" >>> >>> >>> Thanks for the quick reply. But my requirement is that the service >>> should >>> be registered before the component is activated. in that case I >>> have to put >>> cardinality as "1..1" right? >>> >>> Thanks >>> Sameera >>> >>> 2009/5/4 Sameera Jayasoma <sameera.madushan@xxxxxxxxx>: >>> >>>> Hi devs, >>>> >>>> Even though I have used the value "dynamic" for the "policy" >>>> attribute >>>> in >>>> the "reference" element, the component is deactivated once the >>>> bound >>>> service >>>> is unregistered. Here is the component.xml I am using. >>>> >>>> <components xmlns:scr="http://www.osgi.org/xmlns/scr/v1.0.0"> >>>> <scr:component enabled="true" name="carbon.core.dscomponent"> >>>> <implementation >>>> class="org.wso2.carbon.core.internal.CarbonCoreDSComponent"/> >>>> <property name="service.pid" >>>> value="carbon.core.dscomponent"/> >>>> <reference name="registry.service" >>>> interface="org.wso2.carbon.registry.core.service.RegistryService" >>>> cardinality="1..1" policy="dynamic" bind="setRegistryService" >>>> unbind="unsetRegistryService"/> >>>> </scr:component> >>>> </components> >>>> >>>> Here is the component implementation class. >>>> >>>> public class CarbonCoreDSComponent{ >>>> >>>> private static Log log = >>>> LogFactory.getLog(CarbonCoreDSComponent.class); >>>> private BundleContext bundleContext; >>>> >>>> protected void activate(ComponentContext ctxt) { >>>> log.info("******* Carbon Core bundle is activated ******* >>>> "); >>>> } >>>> >>>> protected void deactivate(ComponentContext ctxt) { >>>> log.info("******* Carbon Core bundle is deactivated >>>> ******* "); >>>> } >>>> >>>> protected void setRegistryService(RegistryService >>>> registryService) { >>>> System.out.println("--------------------Set Registry >>>> Service"); >>>> } >>>> >>>> protected void unsetRegistryService(RegistryService >>>> registryService) >>>> { >>>> System.out.println("--------------------Unset Registry >>>> Service"); >>>> } >>>> } >>>> >>>> When I stop the bundle which registers the >>>> "org.wso2.carbon.registry.core.service.RegistryService", >>>> following out >>>> put >>>> is generated. >>>> >>>> ******* Carbon Core bundle is deactivated ******* >>>> {org.wso2.carbon.core.internal.CarbonCoreDSComponent} >>>> --------------------Unset Registry Service >>>> >>>> This mean carbon.core bundle is deactivated right? >>>> >>>> Expected behavior: When the RegisterService is unregisterd, only >>>> the >>>> unbind >>>> method should be called. But here first the bundle is deactivated >>>> and >>>> then >>>> the unbind method is called. >>>> >>>> Any solution would be greatly appreciated. >>>> >>>> Thanks >>>> -- >>>> Sameera Jayasoma >>>> WSO2 Inc. >>>> Oxygenating the Web Service Platform. >>>> http://wso2.org/ >>>> >>>> blog: http://tech.jayasoma.org >>>> >>> >>>> _______________________________________________ >>>> equinox-dev mailing list >>>> equinox-dev@xxxxxxxxxxx >>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev >>>> >>>> >>> >>> >>> >>> -- >>> ============================= >>> | BlueDavy | >>> | OSGi China User Group Director | >>> | http://china.osgiusers.org | >>> | http://blog.bluedavy.cn | >>> ============================= >>> _______________________________________________ >>> equinox-dev mailing list >>> equinox-dev@xxxxxxxxxxx >>> https://dev.eclipse.org/mailman/listinfo/equinox-dev >>> >>> >>> -- >>> Sameera Jayasoma >>> Software Engineer >>> WSO2 Inc. >>> Oxygenating the Web Service Platform. >>> http://wso2.org/ >>> >>> blog: http://tech.jayasoma.org >>> >>> _______________________________________________ >>> equinox-dev mailing list >>> equinox-dev@xxxxxxxxxxx >>> https://dev.eclipse.org/mailman/listinfo/equinox-dev >>> >> >> >> >> -- >> Sameera Jayasoma >> Software Engineer >> WSO2 Inc. >> Oxygenating the Web Service Platform. >> http://wso2.org/ >> >> blog: http://tech.jayasoma.org >> >> _______________________________________________ >> equinox-dev mailing list >> equinox-dev@xxxxxxxxxxx >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> > _______________________________________________ > equinox-dev mailing list > equinox-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/equinox-dev
|