[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] policy="dynamic" in Declarative Services.
|
Thanks guys for your feedback. I really understands the problem here now.
Thanks
Sameera
On Mon, May 4, 2009 at 8:28 PM, Hal Hildebrand
<hal.hildebrand@xxxxxxxxxx> wrote:
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@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
--
Sameera Jayasoma
Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/blog:
http://tech.jayasoma.org
