Yes, it is. The challenge is that the provider of the Network service needs to then use ConfigurationAdmin to change its own isConnected component property as the connection state changes, which while possible is more complicated than you'd hope it to be. In the days before DS where we used the programmatic service APIs to register services and their properties it was actually easier to do this by simply using the ServiceRegistration's setProperties(Dictionary) API.
From: Felix Meschberger <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 09/29/2009 02:24 AM Subject: Re: [osgi-dev] Activate component only after another component's state is set Sent by: [email protected] Hi, Isn't Marcel's proposal possible with the reference target property ? Something like: <scr:reference name="xyz" interface="Network" target="(isConnected=true)" /> My understanding of the target property is to be able to define the service reference filter (in addition the target property is supported to be configurable through Configuration Admin. Regards Felix Simon J Archer schrieb: > > Marcel > > While DS supports component properties that are registered with every > provided service, changing the value of such a property programmatically > is not supported directly, as it would be via a ServiceRegistration. In > fact, I don't think there's a way to get to the ServiceRegistration that > DS creates for registering a component's provided services. The only way > I know to change a property of a DS component is using > ConfigurationAdmin, but that's likely more complicated than anyone needs. > > Also see: > [ds] Add support for changing a service's registered properties > _https://www.osgi.org/members/bugzilla/show_bug.cgi?id=596_ > > It appears that there might be some support for this feature request, > despite it being RESOLVED/WONTFIX. > > Regards > > Simon > > > From: Marcel Offermans <[email protected]> > To: OSGi Developer Mail List <[email protected]> > Date: 09/28/2009 05:28 PM > Subject: Re: [osgi-dev] Activate component only after another > component's state is set > Sent by: [email protected] > > > ------------------------------------------------------------------------ > > > > I would add a service property "isConnected" to the Network service > and make a dependency from your Login service to a Network service > with a property isConnected = true. > > I'm not sure if DS allows this. If not, either manually track it using > a ServiceTracker or use (for example) the Apache Felix Dependency > Manager. Probably iPOJO (also part of Apache Felix) would work too. > > Greetings, Marcel > > > On Sep 25, 2009, at 21:30 , Luciana Alvite wrote: > >> Hello dear fellow OSGi devs, >> >> I have the following simplified scenario in my Declarative Services >> based project: >> >> 2 Components: Network and Login >> Login depends on 1..1 Network component. Network takes care of >> connecting and disconnecting from a given network. >> >> I would like to make the Login component dependency on Network >> satisfied only when the Network is actually connected, meaning the >> component would only be activated after the "network.connect()" >> method is successfully executed. >> >> Approaches I have tried: >> - ConfigAdmin > Setting a property "isConnected" for the Network >> component using the ConfigAdmin when the "connect" method is >> successfully executed >> Result: Does not work, since changing the properties will require a >> reactivation of the Network component, therefore recreating the >> component and losing the connection. >> >> - Events > Make login implement EventHandler and listen to Network >> events. When event is "connected", react accordingly. the problem >> here is that the component must be enabled to be able to actually >> receive events. and this goes against the goal of only activating >> the component AFTER the network is connected.. >> >> I have tried google, read the specs several times but could not yet >> think of any suitable implementation , any ideas of how I could >> solve this? >> >> Thanks in advance for any help or pointers! >> >> -- >> Best Regards >> >> Luciana Alvite _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
