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.
--
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
