Good point! I effectively just need some logic that will trigger early on all resolved bundles having license details and just force them to unresolve if they have expirted licenses. I'll figure out the safest place to do that.
- Ray On Fri, Nov 13, 2015 at 9:27 AM, Thomas Watson <tjwat...@us.ibm.com> wrote: > 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* > <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* > <peter.kri...@aqute.biz>> > To: OSGi Developer Mail List <*osgi-dev@mail.osgi.org* > <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* > <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* > <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* > <raymond.a...@liferay.com>> > To: OSGi Developer Mail List <*osgi-dev@mail.osgi.org* > <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* > <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é* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> > (@Liferay) > Board Member & EEG Co-Chair, *OSGi Alliance* <http://osgi.org/> > (@OSGiAlliance)_______________________________________________ > OSGi Developer Mail List > *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > _______________________________________________ > OSGi Developer Mail List > *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > _______________________________________________ > OSGi Developer Mail List > *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > _______________________________________________ > OSGi Developer Mail List > *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <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 > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
