[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] policy="dynamic" in Declarative Services.

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

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the
OSGi Alliance
hargrave@xxxxxxxxxx

office: +1 386 848 1781
mobile: +1 386 848 3788




From: Hal Hildebrand <hal.hildebrand@xxxxxxxxxx>
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date: 2009/05/04 10:24
Subject: Re: [equinox-dev] policy="dynamic" in Declarative Services.
Sent by: equinox-dev-bounces@xxxxxxxxxxx





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