An extension sounds doable. However, I found something weird: https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/ExtensionManager.java#L505-L507
Is that expected that the framework is using the classloader loading the framework instead of the classloader from the extension bundle ? 2016-10-03 18:14 GMT+02:00 Richard S. Hall <[email protected]>: > On 10/3/16 12:02 , Guillaume Nodet wrote: > >> I have a use case where the wiring is a bit complicated. >> Karaf uses the felix resolver to compute the full wiring and then applies >> it. >> At this point, all the bundles are resolved and started correctly. >> If Karaf is restarted, the framework restarts and resolves the bundles on >> its own, using a bad solution (because the resolver is not greedy) which >> leaves some bundles in a non resolvable state (i.e. without refreshing >> some >> bundles). >> At this point, I've tried to have Karaf stores the computed wiring so that >> it can be re-applied when restarting. Unfortunately, in my very case, the >> wiring is done in such a way that nearly all bundles needs to be >> refreshed, >> even the one containing the bundle hook, so that's bound to deadlocks and >> various problems. >> >> I'm left with two solutions : >> * implement a framework extension to minimize the chances to have to >> refresh the bundle containing the resolver hook >> * implement a persistent resolution in felix >> >> I don't mind either way, but I wonder if instead of implementing it in >> Karaf, it could be done in the framework in a slightly more robust way >> (i.e. not contained in a bundle which itself is bound to refreshes, >> etc...) >> and may be reused by others. >> >> Thoughts ? >> > > I don't have a strong opinion, but we had always tried to avoid caching > too much run-time state in the framework cache because this increases the > opportunity for the framework cache to become corrupt and then subsequently > fail to restart. In a perfect world, it seems like it would be nice if this > could be a resolver hook implemented externally (and generically) to > provide a management agent service where an agent could attempt to save > resolution state and the resolver hook would be responsible for trying to > recreate the saved state upon subsequent startups. Then the framework's > cache stays out of the whole scenario. Perhaps that is wishful thinking. > > I believe Equinox' resolves are persisted across executions, so it is not > unheard of and does have benefits if implemented well of reducing startup > time on subsequent executions by avoid re-resolving complex systems. > > -> richard > > >> Guillaume >> >> > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
