Thank you for your answer, especially the point about the mutable Condition.
In our case however, permissions are still pretty dynamic: we use them to control which application can use which device and this can be changed while the application is running. Another way of implementing this would be to use a proxy pattern to manage permission: the client bundle would use the proxified services and the permission dynamicity would be managed at this proxy level (which communicates with our permission manager and thus 'knows' when permissions have changed). It clearly needs more thought but could avoid restarting the bundle, at the cost of increased complexity. For the time being I think I'll simply restart the bundles ! :) Regards, Pierre De : [email protected] [mailto:[email protected]] De la part de BJ Hargrave Envoyé : mardi 3 décembre 2013 17:56 À : OSGi Developer Mail List Objet : Re: [osgi-dev] Declarative Services and Conditional permission Admin It is just the way things are. Permissions should not really be that dynamic. As Tom observed, there is no way for an observer to tell that the permissions have changes. Given custom (mutable) Condition classes, a permissions check result can change from implies call to implies call, so a permissions change listener would not provide useful information. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance<http://www.osgi.org/> [email protected]<mailto:[email protected]> office: +1 386 848 1781 mobile: +1 386 848 3788 From: <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 2013/12/03 09:53 Subject: Re: [osgi-dev] Declarative Services and Conditional permission Admin Sent by: [email protected] ________________________________ OK, thanks a lot for your quick answer. I guess I'll have to develop a start / stop functionality into my permission manager bundle then. Do you know if this point is a deliberate choice from the specification or just an unfortunate coincidence ? I'm working with Device Services (from Device Access) and use permissions to restrict access to devices to specific applications ; restarting an application to take into account a new device is feasible yet not really convenient. regards, Pierre ________________________________ De : [email protected] [[email protected]] de la part de Thomas Watson [[email protected]] Envoyé : mardi 3 décembre 2013 15:37 À : OSGi Developer Mail List Objet : Re: [osgi-dev] Declarative Services and Conditional permission Admin There is no permissions listener to be notified when permissions change. A DS runtime is not going to notice that a service is no longer visible when permissions change. Similarly a ServiceTracker is also not going to be notified (with the adding or removed methods) that a service is now visible or not to the BundleContext used by the ServiceTracker. This means that optional non-static service dependencies will not be dynamically injected when security changes. Also, there will be issues when taking away service permissions. A component Y that got injected with service X but then later service permission for X got revoked for the bundle with the component Y will not result in unbinding the service X from component Y. If this is a concern then I think you would have to detect which bundles are using the service X and restart them to make sure they use the new permission policy. Tom [Inactive hide details for ---12/03/2013 08:13:01 AM---Hi all, I'm working with Declarative Service and I've just started to add]---12/03/2013 08:13:01 AM---Hi all, I'm working with Declarative Service and I've just started to add security to our developmen From: <[email protected]> To: "[email protected]" <[email protected]>, Date: 12/03/2013 08:13 AM Subject: [osgi-dev] Declarative Services and Conditional permission Admin Sent by: [email protected] ________________________________ Hi all, I'm working with Declarative Service and I've just started to add security to our development using Conditional Permission Admin. There is a case where I'm not sure what is the expected behavior : I have a component which declares an optional and dynamic reference to a service, for which it's bundle does not have the necessary permissions : the component is activated but the service is not injected in the component (as specified in the security section of Declarative Services specifications). Now, what should happen if the permission are dynamically changed and the bundle can access the service : should the service be injected immediately (as it has the dynamic policy) ? I do not find anything in the specification about this question. This raises another question : is it possible for a bundle (SCR or not) to be notified when permissions have been changed ? Configuration Admin defines a ConfigurationListener to be notified of configuration changes, but I don't find anything similar for permissions. Any ideas about these issues ? regards, Pierre Rust _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
<<inline: image001.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
