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 <[email protected]>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 > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] > *On Behalf Of *Hal Hildebrand > *Sent:* Montag, 4. Mai 2009 16:53 > *To:* Equinox development mailing list > *Subject:* Re: [equinox-dev] policy="dynamic" in Declarative Services. > > 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. > -- > *BJ Hargrave* > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance <http://www.osgi.org/>* > *[email protected] > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > From: > Hal Hildebrand <[email protected]> > To: > Equinox development mailing list <[email protected]> > Date: > 2009/05/04 10:24 > Subject: > Re: [equinox-dev] policy="dynamic" in Declarative Services. > Sent by: > [email protected] > > > ------------------------------ > > > > 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 > > <[email protected]> wrote: > >> Hi Kai, > >> > >> On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai <[email protected] > >> > > >> 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: [email protected] > >>> [mailto:[email protected]<[email protected]>] > 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 <[email protected]> > >>> 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 <[email protected]>: > >>> > >>>> 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 > >>>> [email protected] > >>>> 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 > >>> [email protected] > >>> 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 > >>> [email protected] > >>> 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 > >> [email protected] > >> https://dev.eclipse.org/mailman/listinfo/equinox-dev > >> > >> > > _______________________________________________ > > equinox-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > _______________________________________________ > equinox-dev mailing list > [email protected] > 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 [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
