Firstly I would like to thank you all for your responses. @Felix and Simon: Although this solution is viable, my Network component depend on other services from other
bundles, so registering the service "by hand" in the connect method would not be very practical, as Simon mentioned. I would rather use DS, if possible. @Simon: to 1) unfortunatelly the bundles are not in the same bundles (I thought about that too) to 2) I am not sure I understand ur "factory component" suggestion. my network component creates one and only one connection and all other modules interact with the network through one and only one network component (its a P2P network, so each node has an unique ID, based on its IP and port, which is created when the connection to the network is established). Creating several connections would be the equivalent of having several nodes in the same machine, which would break the application. to 3) see above @ Marcel and Simon: as I said im my first post, I have succesfully changed the component properties through the ConfigAdmin, but as I said, using this way the network method is reactivated when its properties change and therefore its previous state is lost (incl the connection state). I am not really familiar with iPojo, but could I use the "requires field" (or sth similiar) to declare another component (Login in the example) depends on a "isConnected" field (from the Network component) whose value MUST be true? if yes, what would happen when the value of the field changes? Would the component that declares it (Network) be reactivated or does it maintain its state? This seems very similar to the properties in OSGi, which when changed using the ConfigAdmin will reactivate the component, thus losing its previous state. I personally also tend to use DS as much as possible and currently the whole project (there are several other modules besides these 2) is DS based, which allows for an easy extendible architecture, even for people w.o. much knowledge of OSGi. I would like to maintain that unified architecture if possible. The Network and Login bundles provide the basic functions to access the network and all other modules depend on then, as it would be expected (the user must be connected and logged in to do virtually anything in the platform). So far it seems Felix's solution would indeed be the only viable solution, even though it would break the unified DS based architectures. Since I plan on using the same mechanism to inform interested bundles about the login state too, this would mean I would have to redesign both the Network and Login bundles using the standard OSGi API, thus breaking the unified POJO architecture. I will think about it a little longer. Any other suggestions are highly appreciated. thank you and regards, Luciana
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
