I'm unsure how you are going to use a bundle listener to unresolve bundles. It will be pretty awkward I think. The listener is going to get some event for a particular bundle (STARTING, RESOLVING etc.). Then you check if the license has expired, then you do an unresolve operation (a refresh operation) that is an asynchronous operation. Now that bundle completes its lifecycle operation in flight (e.g. STARTING), after the framework has given up the state change lock for the bundle, now the async refresh operation continues which will stop and unresolve the bundle.
This is awkward and will cause some strange churn in the system that you will have to cope with. It would seem like you would instead keep track of license expiration at framework startup for the existing bundles installed with a system bundle extension activator. That way you can verify the licenses ahead of start-level 1. Then you can put things in place to refresh and prevent existing bundles from resolving before anything really starts. Also you would keep track of license expiration at bundle install/update time for new bundles. Then you would have something like a future that runs when the first license has expired and at that time you refresh the bundles that have expired. I don't think you would want to refresh bundles as bundle events are being fired for lifecycle operations. Tom From: Raymond Auge <raymond.a...@liferay.com> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Date: 11/13/2015 07:55 AM Subject: Re: [osgi-dev] resolver hook for license checks Sent by: osgi-dev-boun...@mail.osgi.org I think any attempt to uninstall is way too over the top behaviour particularly on expiration. We don't want to really alter the state of the system that much e just want to at most stop the bundle from being resolved. As for the resolver hook, I think this is the correct mechanism because it's literally a failed requirement plus it won't matter which agent is used to install bundles. However, that does not address "expiration" of previously resolved bundles, which I think IS ideally addressed by a synchronous bundle listener which only unresolves the bundles having expired licenses. So yeah, thanks for the ideas. I think a combination is ideal. - Ray On Nov 13, 2015 8:39 AM, "Thomas Watson" <tjwat...@us.ibm.com> wrote: Not sure if that was a usecase of SynchronousBundleListener or not. But I don't think that approach is any better than the resolver hook. Except you could uninstall the bundle right on the INSTALLED event, but that would seem to just throw errors back to the provisioning agent. The Bundle object they get back from install will now be uninstalled. That undoubtedly will cause errors when they try to start the bundle, but with no indication on why the bundle is now in the UNINSTALLED state. If the agent is able to cope with this kind of behavior then it seems they would be far better off checking the license themselves either before or after bundle installation instead of with a listener or resolver hook. Tom From: Peter Kriens <peter.kri...@aqute.biz> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Date: 11/13/2015 02:29 AM Subject: Re: [osgi-dev] resolver hook for license checks Sent by: osgi-dev-boun...@mail.osgi.org I agree, I think SynchronousBundleListener is better. (Wasn’t license management one of the primary reasons for this class?) This can prevent a bundle being installed and uninstall it when it attempts to get resolved and its license is expired. I’ve also once experimented with encrypting the class files and using the weaving hook. But I agree that creates awkward error reporting. And it might be expensive. Of course, just as the hooks, the Synchronous Bundle Listener does have an ordering issue. (One of the few good reasons for start levels.) Kind regards, Peter Kriens On 11 nov. 2015, at 14:43, Thomas Watson <tjwat...@us.ibm.com> wrote: A resolver hook seems like a good option for doing this but there are drawbacks. One drawback of this approach is that the resolver error from the framework is going to give not indication for why the bundle is not allowed to resolve, only that a hook prevented it from resolving. It would seem a better approach would be for the management agent to check licenses when installing bundles and to not even let the bundles into the framework if they are not appropriate. Tom From: Raymond Auge <raymond.a...@liferay.com> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Date: 11/10/2015 07:39 PM Subject: [osgi-dev] resolver hook for license checks Sent by: osgi-dev-boun...@mail.osgi.org Hey All, We're using a resolver hook for application license checking. I like this since it's nice clean and stops bundles early and efficiently. However I'm wondering how other people may have done this! -- Raymond Augé (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance) _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
