Yes, that might be true. But it does seem a pity to not be able to use DS since it is so much easier than working with the programmatic APIs. My inclination is to try and find a way to achieve the goal with DS while at the same time enquire about getting this behavior into DS... that was my intention when opening the bug report. But to be honest, I've not had the need to push further on the issue. If you feel that this is important, please express your thoughts in the bug report (assuming you have access).
From: Marcel Offermans <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 09/28/2009 07:31 PM Subject: Re: [osgi-dev] Activate component only after another component's state is set Sent by: [email protected] Thanks for clearing that up, Simon! Sounds to me like this is a use case best not solved with DS. Greetings, Marcel On Sep 29, 2009, at 1:19 , Simon J Archer wrote: 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
