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* > <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 > _______________________________________________ > 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
